How to Set Up a Local Development Environment for Web Development

How to Set Up a Local Development Environment for Web Development

A well-configured local development environment is the foundation of productive web development work. Setting it up correctly at the start — with the right tools, the right configuration, and the right workflow — eliminates the constant friction of environment issues that slow development and distract from the actual work of building. This guide covers the complete local development setup for modern web development in 2026, from the terminal and text editor to Git, Node.js, Docker, and the browser tooling that makes debugging efficient.

The Core Tools: What Every Web Developer Needs

Tool Category	Recommended Options	Why It Matters
Code editor / IDE	VS Code (most popular), WebStorm, Neovim	Where you spend 8 hours a day — worth investing in setup
Terminal	macOS: iTerm2 + Zsh; Windows: Windows Terminal + WSL2; Linux: native	Fast terminal access is essential for modern web development
Package manager (macOS/Linux)	Homebrew (macOS), apt/yum (Linux)	Installs and manages development tools consistently
Version control	Git (universal) + GitHub/GitLab/Bitbucket	Required for all professional development
Node.js version manager	nvm (Node Version Manager) or fnm	Manage multiple Node.js versions for different projects
Browser DevTools	Chrome DevTools (primary) + Firefox DevTools	Inspect, debug, profile — indispensable for web work
API testing	Postman, Insomnia, or Bruno (open source)	Test and explore APIs without writing code
Database GUI	TablePlus, DBeaver, or Prisma Studio	Visual database exploration and management

Step 1: Terminal Setup

macOS

Install Homebrew (the macOS package manager) first — almost everything else installs through it:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Install iTerm2 for a better terminal experience: brew install --cask iterm2

Install Zsh with Oh My Zsh for a powerful shell configuration:

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Key Oh My Zsh plugins to enable in ~/.zshrc: git (helpful git aliases), z (smart directory jumping), zsh-autosuggestions (command suggestions from history), and zsh-syntax-highlighting (valid commands highlighted in green).

Windows

Install WSL2 (Windows Subsystem for Linux) — this runs a real Linux environment inside Windows and is essential for modern web development on Windows. Enable it through: wsl --install in an elevated PowerShell. Choose Ubuntu as your Linux distribution. Once WSL2 is running, install Windows Terminal from the Microsoft Store and configure it to use Ubuntu as the default profile. From this point, follow the Linux setup instructions inside your WSL2 Ubuntu environment — all development tools should be installed in WSL2, not in Windows natively.

Step 2: Git Configuration

Configure Git with your identity before making any commits:

git config --global user.name "Your Name"

git config --global user.email "your.email@example.com"

Set up SSH keys for GitHub/GitLab authentication (more secure than HTTPS passwords):

ssh-keygen -t ed25519 -C "your.email@example.com"

Then add the public key (~/.ssh/id_ed25519.pub) to your GitHub account under Settings → SSH Keys. Test with: ssh -T git@github.com

Essential Git global configuration: git config --global init.defaultBranch main (uses "main" instead of "master" for new repos), git config --global pull.rebase true (cleaner pull behavior), and git config --global core.editor "code --wait" (uses VS Code for commit messages).

Step 3: Node.js via nvm

Never install Node.js directly from nodejs.org for development work — instead use nvm (Node Version Manager), which lets you install and switch between multiple Node.js versions for different projects:

Install nvm: curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

Install the latest LTS version of Node.js: nvm install --lts

Set it as default: nvm alias default lts/*

Install global tools you'll use across all projects: npm install -g typescript ts-node eslint prettier

Use a .nvmrc file in each project directory to specify the required Node.js version for that project — this ensures the whole team uses the same version automatically: echo "20.11.0" > .nvmrc

Step 4: VS Code Setup

VS Code is the dominant code editor for web development, and its effectiveness depends heavily on extension configuration. Essential extensions for modern web development:

Extension	Purpose	Why Essential
ESLint	JavaScript/TypeScript linting	Catches errors and enforces code style as you type
Prettier - Code Formatter	Automatic code formatting	Consistent formatting without thinking about it
TypeScript and JavaScript Language Features	IntelliSense and type checking	Built-in but must be configured correctly
Tailwind CSS IntelliSense	Tailwind class autocomplete	Essential for Tailwind development — 10M+ installs
GitLens	Git history inline, blame annotations	Makes understanding code history visual and immediate
GitHub Copilot	AI code completion	Significant productivity improvement for repetitive patterns
Error Lens	Inline error display	Shows errors directly in code rather than hover-required
Auto Rename Tag	Syncs HTML opening/closing tags	Eliminates a common HTML editing annoyance
REST Client	Test HTTP requests from .http files	Lightweight Postman alternative inside VS Code

Step 5: Docker for Local Services

Docker is the standard way to run databases and other services locally without installing them directly on your machine. Docker Desktop (macOS and Windows) or Docker Engine (Linux) lets you run PostgreSQL, MySQL, MongoDB, Redis, and any other service in isolated containers that can be started, stopped, and reset without affecting your local system.

A typical Docker Compose setup for a web project needing PostgreSQL and Redis:

Create docker-compose.yml in the project root:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: myapp_dev
      POSTGRES_USER: developer
      POSTGRES_PASSWORD: localpassword
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
  redis:
    image: redis:7
    ports:
      - "6379:6379"
volumes:
  postgres_data:

Start services with: docker compose up -d. Stop with: docker compose down. This approach means every developer on the team runs identical local services without manual database installation, and resetting the local database is as simple as docker compose down -v && docker compose up -d.

Step 6: Environment Variables and .env Files

Managing environment variables correctly is one of the most important local development hygiene habits. Every project should use .env files to store environment-specific configuration (database URLs, API keys, feature flags) — and the .env file should never be committed to version control.

The standard pattern: create a .env.example file in the repository with placeholder values documenting all required environment variables, add .env to .gitignore, and require new team members to copy .env.example to .env and fill in their values on first setup. Use dotenv (automatically loaded by most frameworks) to load these variables into the process environment. Never hardcode API keys, database passwords, or other secrets directly in code — even for local development. The habit of proper secret management must be built during local development to prevent accidental commits of real credentials.

Step 7: Project Startup Scripts

A well-configured package.json with consistent npm scripts is the final piece of a frictionless local development setup. Standard scripts every web project should define:

Script	Command Example	Purpose
dev	next dev / vite / nodemon src/index.ts	Start development server with hot reload
build	next build / tsc && vite build	Production build
test	jest / vitest	Run test suite
test:watch	jest --watch / vitest --watch	Run tests in watch mode during development
lint	eslint src --ext .ts,.tsx	Check for linting errors
format	prettier --write src	Auto-format all source files
db:migrate	prisma migrate dev / drizzle-kit migrate	Run database migrations
db:seed	ts-node prisma/seed.ts	Seed local database with development data

Common Local Environment Problems and Solutions

Problem	Likely Cause	Solution
Port already in use (EADDRINUSE)	Previous dev server still running	kill -9 $(lsof -t -i:3000) to kill process on port 3000
npm install fails with permission errors	Global npm packages owned by root	Fix npm global prefix: npm config set prefix ~/.npm-global
Node.js version mismatch errors	Wrong Node version for the project	nvm use (in project root with .nvmrc) or nvm install from package.json engines field
Database connection refused	Docker container not running	docker compose up -d to start containers
Environment variables undefined	.env file missing or not loaded	Copy .env.example to .env; ensure dotenv is configured
Git commits failing (pre-commit hooks)	Husky + lint-staged failing	Fix linting errors or run npm run format to auto-fix

The Bottom Line

A well-configured local development environment reduces daily friction, ensures consistency across team members, and prevents the environment issues that interrupt flow and frustrate developers. The investment in proper setup — terminal configuration, Git SSH keys, nvm for Node version management, VS Code with the right extensions, Docker for local services, and consistent .env practices — pays for itself in the first week and compounds throughout a developer's career. Set it up right once, version control the configuration files that can be shared, and spend your development time on the actual problems rather than the environment.

At Scalify, our development process is built on well-configured environments and consistent tooling — enabling us to deliver professional websites in 10 business days without environment friction slowing delivery.

Top 5 Sources

• GitHub — Connecting with SSH
• nvm — Node Version Manager Documentation
• Docker — Docker Compose Documentation
• VS Code — Extension Marketplace Guide
• Oh My Zsh — Terminal Configuration Framework

Code Quality Tooling: ESLint, Prettier, and Husky

A professional local development environment includes automated code quality tools that enforce standards without requiring manual effort. The three-tool combination used by most serious web development teams:

ESLint analyzes code for errors and style issues while you type, catching undefined variables, unreachable code, and violations of team coding standards before they're committed. Configure ESLint with a shareable config (eslint-config-airbnb, eslint-config-standard) or build a custom config that reflects your team's standards. TypeScript projects add @typescript-eslint/parser and @typescript-eslint/eslint-plugin for TypeScript-specific rules.

Prettier handles code formatting automatically — indentation, line length, quote style, trailing commas — so developers never need to think about formatting. Configure Prettier as the VS Code default formatter with format-on-save enabled: every file is automatically formatted when saved. Add prettier as a devDependency and run it in CI to ensure committed code is always formatted correctly.

Husky + lint-staged runs ESLint and Prettier automatically on every Git commit, preventing unformatted or error-containing code from being committed. Install with: npx husky-init && npm install. Configure lint-staged in package.json to run ESLint and Prettier on staged files only — checking the entire codebase on every commit is too slow, but checking only the files being committed is fast and effective. This automation ensures code quality standards are enforced consistently across every team member without relying on individual discipline to run linting manually before committing.

Debugging: The Skills That Save Hours

Most developers spend far more time with console.log debugging than necessary, when VS Code's built-in debugger and Chrome DevTools provide tools that make complex debugging problems significantly faster to resolve.

VS Code debugger configuration for Node.js and Next.js: add a .vscode/launch.json with the appropriate configuration for your stack. For Next.js, the official launch configuration allows setting breakpoints directly in your TypeScript source code and stepping through server-side rendering and API route execution. For pure Node.js back-end code, the Node.js debugger attaches to a process and provides full variable inspection, call stack display, and conditional breakpoints. Developers who invest one afternoon in learning their editor's debugger consistently report significant improvements in debugging efficiency that compound throughout their career.

Chrome DevTools Network tab is essential for debugging API requests, checking request and response headers, identifying slow requests, and verifying that authentication tokens are being sent correctly. The Application tab shows local storage, session storage, and cookies — critical for debugging auth issues. The Performance tab profiles JavaScript execution and identifies rendering bottlenecks. Learning to use these tools beyond the Elements and Console tabs — which most developers rely on exclusively — unlocks debugging capabilities that make complex front-end issues significantly faster to diagnose.

Team Environment Consistency: Devcontainers and dotfiles

The most professional local development setups ensure that every developer on a team has an identical environment — eliminating the "works on my machine" problems that waste hours in collaborative teams. Two approaches:

Devcontainers (VS Code + Docker) define the complete development environment as code — including the OS, installed tools, VS Code extensions, and environment variables — in a .devcontainer directory. Any developer who opens the project in VS Code with Docker running gets an identical development environment automatically, regardless of their host operating system or personal configuration. This approach is particularly valuable for projects with complex dependency requirements or for onboarding new team members who can be productive from day one without a multi-hour environment setup process.

dotfiles repositories are personal repository of shell configuration files (~/.zshrc, ~/.gitconfig, ~/.vimrc, VS Code settings.json) that can be cloned to any new machine to instantly replicate a developer's personal environment. A well-maintained dotfiles repository means that setting up a new laptop takes 30 minutes rather than a day — and the configuration that was refined over years of daily use is immediately available on any new machine.