How to Set Up a Local Web Development Environment

A local web development environment is the set of tools and project files you use on your own computer to edit and run a website before deploying it. The minimum setup depends on the project: a static HTML page may need an editor and local preview server; a Node.js app needs the project’s Node.js version and dependencies; a Django app needs compatible Python and project-scoped Python packages.

For an existing project, start with its README and version files. Install only what that project requires, run its documented start command, then open the local address printed in the terminal. The steps below use VS Code as one editor example; it is not mandatory.

1. Identify the project’s stack

Before installing software, identify what you are building or joining:

Static HTML, CSS, and JavaScript: You can edit the files directly. A local server is useful for browser features and a live-reload workflow.
Node.js application: Install the Node.js runtime version the project expects. npm is included with the Node.js distribution and is commonly used to install dependencies and run project scripts.
Python framework such as Django: Install a compatible Python version and isolate the project’s packages in a virtual environment.

If the project already exists, inspect its README, package.json, Python requirements or project configuration, and any version files before choosing versions. Framework and runtime compatibility changes over time, so follow the documentation for the project’s chosen release. Django’s quick install guide explains the Python prerequisite and distinguishes stable documentation from development documentation: Django quick install guide.

2. Install an editor and open the project folder

Choose an editor with support for the languages and tools you use. VS Code is one option; its base installation provides editor and language features, while additional components can be added for a particular workflow. Other editors can work just as well.

Open the whole project folder rather than an individual file. This keeps the editor, integrated terminal, source control, and debugger pointed at the same project. VS Code’s setup documentation describes opening folders and adding workflow-specific components: VS Code setup overview.

For a static page, an editor extension such as VS Code Live Preview can serve files locally. You can also use another local server that fits your tools.

3. Install the runtime and keep dependencies with the project

Node.js projects

Install Node.js using the official instructions for your operating system, selecting the version required by the project. Avoid copying a version number from an old tutorial because release channels change. Open a new terminal after installation and check that both commands are available:

node --version
npm --version

The VS Code Node.js tutorial describes Node.js as the runtime and npm as its package manager, included with the Node.js distribution: VS Code Node.js tutorial. From the project folder, install the dependencies declared by the project. If it has a lockfile and its instructions specify a clean reproducible install, use the corresponding lockfile-aware command, for example:

npm ci

If there is no lockfile, follow the README; a common install command is:

npm install

Check the project’s scripts in package.json. A typical start command might be npm run dev or npm start, but the project’s own instructions determine the right one.

Django projects

Install a Python version compatible with the Django release used by the project. Create a virtual environment in the project directory, activate it, and install Django or the project’s declared dependencies inside it. This avoids mixing one project’s packages with unrelated Python work. Use the activation command for your shell and operating system.

# Create the environment
python -m venv .venv

# Activate in macOS or Linux (bash/zsh)
source .venv/bin/activate

# Activate in Windows PowerShell
.venv\Scripts\Activate.ps1

# Install the project's dependencies if it has a requirements file
python -m pip install -r requirements.txt

If you are starting a small Django experiment without an existing dependency file, install Django in the active environment with python -m pip install Django. For a project that specifies a version or dependency manager, follow that configuration instead. The Django documentation demonstrates virtual environments and advises using the documentation for the installed release: Django installation guide and Django installation FAQ.

For a beginner Django experiment, a separate database server is not required: Django uses SQLite by default, and its built-in development server is available. This is Django-specific; other stacks may require other services or databases.

4. Start the app and open its local address

Run the start command documented by the project from its root directory, with the required virtual environment active when applicable. Keep that terminal open while using the app; it runs the development server and shows startup errors and requests.

Example: Django

python manage.py runserver

Open the address printed by Django, typically http://127.0.0.1:8000/. The official tutorial demonstrates this command and explicitly warns that the built-in server is for development, not production: Django tutorial, part 1.

Example: Node.js

Use the script declared in package.json. For example, if the project defines a dev script:

npm run dev

Open the local URL the command prints. Do not assume every app uses the same port or even the same script name.

Example: static files

Start the local preview server through your editor extension or chosen static server, then open the address it reports. Serving files over a local HTTP address is more representative of a website than opening an HTML file directly, especially when the page uses browser features that expect HTTP.

5. Check that the environment is ready

Confirm the terminal is in the project root, where its README or main project configuration lives.
Confirm the correct runtime is active: run node --version and npm --version for Node.js, or python --version and check the active virtual environment for Python.
Install the project’s declared dependencies using its documented package manager and lockfile.
Start the app with the project’s command and wait for the server’s ready message.
Visit the exact host and port printed by the server. Keep the process running while you browse.
Make a small source change and refresh or use live reload to confirm you are viewing the local project.

6. Choose local installation or containers

Installing the required runtime directly on your computer is usually the simplest first setup for a small project. Containers can help when a team needs a repeatable environment or needs development dependencies to more closely match a deployment environment. They add configuration and can make debugging more involved, so use them when the project benefits from that consistency rather than treating them as a prerequisite.

Docker documents development workflows for Django and Node.js, including Compose Watch and synchronized code: Docker development guides. VS Code also discusses the tradeoffs of local and container-based environments: VS Code development containers.

Setup	Useful when	Tradeoff
Install tools locally	You are learning, prototyping, or working on a straightforward project.	Projects may need different runtime versions on the same computer.
Use a container	The project needs a repeatable toolchain or specific supporting services.	There is more configuration, and container debugging adds complexity.

7. Troubleshooting

Symptom	Likely cause	What to do
`node`, `npm`, or `python` is not found	The runtime is missing, the terminal predates installation, or its executable is not on PATH.	Open a new terminal, rerun the version command, and check the runtime’s official installation instructions for your OS and shell.
Dependency import or module errors	Dependencies were not installed, the wrong project folder is open, or the Python virtual environment is inactive.	Check the project root and its dependency file. Activate the project environment, then use its documented install command.
Browser cannot connect	The server stopped, startup failed, or the browser is using the wrong host or port.	Read the terminal output, resolve any startup error, restart the server, and open the exact address it reports.
Address already in use	Another process is using the requested port.	Stop the other development server if appropriate, or use the port option documented by your framework. Then visit the new address printed in the terminal.
Framework rejects the installed runtime version	The runtime and framework versions are incompatible.	Check the compatibility documentation for the exact framework release and install a supported runtime version.
Changes do not appear	The browser may be showing a different project or a stale page, or the server may not reload files automatically.	Confirm the local URL and project directory, refresh, and check whether the chosen development server supports reload or needs a restart.
Django shows a warning about its development server	The built-in server is intended for local development.	Use it for local work only. Deploy with a production WSGI or ASGI server configured for the project, as Django’s tutorial advises.

For version-specific framework errors, use documentation for the release actually installed. Troubleshooting steps here are workflow guidance based on the setup process, not claims of hands-on testing.

8. Preview the page in a clean browser capture

When you need to inspect a page as an image or PDF, you can capture it yourself from a browser or use a screenshot API. A local development environment gets the app running; a screenshot service is a separate tool for capturing a page URL. For locally hosted pages, make sure the capture service can reach the address you provide.

DIY browser capture

Use your browser’s built-in screenshot or print-to-PDF workflow for a one-off check. For repeatable captures, use a browser automation tool configured with the project’s URL, viewport, wait condition, and output format. Capture after the page has loaded its important content, and check whether lazy-loaded images need scrolling or full-page capture. The exact automation setup depends on the project and chosen browser tooling.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status.

For example, this cURL request saves a WebP capture. Replace the URL with a page the API can access and provide your API key:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

The same request in Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

And Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

See the ScreenshotNeo API documentation for parameters and response details. It also offers full-page and selector captures, device presets and custom viewports, dark mode, image and PDF options, custom CSS or JavaScript, wait conditions, request blocking, headers and cookies, caching, async jobs, bulk capture, signed links, usage reporting, and an MCP server with take_screenshot, get_page_info, and capture_pdf tools for AI agents.

ScreenshotNeo’s free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan. Create a free account and get 1,000 screenshots a month with no card.

Performance, reliability, and cost

Keep installs project-scoped. Project dependency files and lockfiles help make the setup repeatable and avoid relying on packages installed globally by accident.
Use the smallest useful stack. A static preview, a project runtime, or a framework’s built-in development server may be enough; add databases and containers only when the app needs them.
Keep server output visible. The terminal is where startup failures and application errors appear. A browser connection alone does not confirm the app is running correctly.
Do not treat development servers as production infrastructure. Django specifically warns that its built-in server is not for production. Follow the chosen framework’s deployment guidance.
Budget for captures separately from local setup. Running the app locally does not require a screenshot API. If you use ScreenshotNeo, clean captures are billed and the response indicates billing status; its free tier is 1,000 per month, with paid plans starting at $5 for 3,000.

FAQ

Do I need Docker to develop a website?

No. Install the project’s required tools locally for a simple first project. Consider containers when repeatable environments or supporting services justify the extra setup.

Can I use any code editor?

Usually. Choose one that supports your language and preferred terminal, source control, and debugging workflow. VS Code is an example, not a requirement.

Do I need a database server to try Django?

Not for a basic experiment. Django uses SQLite by default. A project may require a different database based on its own configuration.

Is localhost visible to other people?

A local development address is meant for access from your computer unless you deliberately configure network access or a tunnel. Check the framework and network setup before expecting an external service to reach it.

Is the local development server safe to deploy?

No. Django’s tutorial explicitly identifies its built-in server as a development server and says not to use it in production. Use the production server approach documented by your framework.