Setting Up a Local WordPress Development Environment

A solid local WordPress dev environment is the difference between "I tried to fix the bug but every iteration takes two minutes" and "I tried five things in ten minutes." In 2026 the local-WP landscape is finally mature: a handful of tools that all work well, each with a clear sweet spot. This is how to pick.

What you actually need from a local environment

• Fast spin-up. A new site in under 60 seconds. Anything slower and you stop spinning up scratch sites for testing.
• PHP version control. The ability to switch between PHP 8.1, 8.2, 8.3, 8.4 per site. Clients run different versions and you need to match.
• HTTPS by default. Modern WP features (REST API, block editor, third-party integrations) increasingly assume HTTPS. Self-signed certs trusted at the OS level are the right default.
• Xdebug integration. One-toggle on/off, no wrestling with PHP config files. See Debugging WordPress Plugins Like a Pro.
• Database access. A GUI or CLI to inspect and modify the DB without leaving the workflow.
• Multisite support. If you build for clients who run multisite, you need this for compatibility testing.
• Per-project config in version control. The team should be able to git clone the repo and spin up an identical environment.

The contenders in 2026

Local by Flywheel (formerly Local by Flywheel)

The friendliest on-ramp. Native macOS / Windows / Linux app, no Docker or terminal required to start a site. Click "new site," pick PHP version, done. Built-in HTTPS, one-click Xdebug, free site sharing tunnels.

Best for: solo developers, teams new to WordPress development, designers who edit code occasionally. The strength is the UI; the weakness is that it's less version-controllable than DDEV or Docker.

Sweet spot: the typical agency dev who runs 10-30 client sites locally, switches between them daily, and doesn't want to think about Docker.

DDEV

The current best-in-class for teams. Docker-based but with a WordPress-shaped CLI on top. Per-project YAML config that goes in the repo, so anyone who clones gets the same environment. Excellent PHP version handling, built-in xdebug, mailhog, phpmyadmin, redis. Cross-platform (Mac, Windows via WSL2, Linux).

# Spin up a new WP site in ~60 seconds
mkdir my-client-site && cd my-client-site
ddev config --project-type=wordpress
ddev start
ddev wp core download
ddev wp core install --url=https://my-client-site.ddev.site \
    --title="Test" --admin_user=admin --admin_password=password \
    --admin_email=test@example.com

The .ddev/config.yaml file checked into the repo captures PHP version, database type, additional services, hooks, mounts. Onboarding a new dev becomes: git clone && ddev start.

Best for: agency teams, plugin/theme product development, clients with strict environment-parity requirements. The slight learning curve pays off the moment you onboard a second person.

Docker / docker-compose

The lowest-level option. Maximum flexibility, maximum config burden. You write a docker-compose.yml with the services you need (mariadb, php-fpm, nginx, redis, mailhog), mount the WP installation as a volume, and orchestrate.

Best for: developers comfortable with Docker who want environment-level control beyond what DDEV exposes. Or for headless WP setups where the WP backend is one of several services.

Sample minimal compose for WP:

services:
  db:
    image: mariadb:11
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wordpress
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:php8.3-apache
    depends_on: [db]
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: root
    volumes:
      - ./wp-content:/var/www/html/wp-content

volumes:
  db_data:

Sweet spot: the developer who's already deep into Docker and doesn't need DDEV's WP-specific helpers.

Lando

DDEV's older cousin. Docker-based, YAML config, similar model. Lando has been around longer and has a larger plugin ecosystem; DDEV has a more active core team and faster release cadence in 2026.

Best for: teams already invested in Lando, or running Drupal+WordPress on the same toolchain (Lando supports both natively).

For new WordPress-only setups in 2026, DDEV is the more actively-developed choice.

wp-now

The newest and most surprising entrant. Built by the WordPress Playground team — a Node-based tool that runs WordPress in a local sandbox without Docker. Spin up a site instantly:

npx @wp-now/wp-now start

Best for: testing a plugin or theme quickly without committing to a full local stack. Great for QA passes, code reviews of PRs, demos. Not the right tool for a long-running client site — the storage layer is ephemeral by default.

VVV (Varying Vagrant Vagrants)

The grandparent of WordPress local environments. Vagrant + VirtualBox-based. Still works, but VirtualBox virtualization is significantly slower than Docker on modern Apple Silicon, and most teams have moved off it. Mentioned for completeness; not recommended for new setups.

Picking — a short decision flow

• Solo dev, want it to just work → Local by Flywheel
• Team, want repo-committed environment → DDEV
• Already comfortable with Docker, want full control → docker-compose
• One-off testing, plugin demo → wp-now
• Cross-platform team that's already on Lando → keep Lando

What to set up once, regardless of tool

• WP-CLI installed. Most local tools include it (DDEV: ddev wp ...; Local: in the site shell). Worth getting fluent — every WP admin task has a CLI equivalent that's 10x faster.
• Query Monitor active on every dev install. See debugging WordPress plugins.
• Xdebug toggle ready.Even if you don't use it daily, having it one keystroke away changes how you approach hard bugs.
• Mailhog or equivalent capturing outbound mail. Critical when testing forms, account creation, password resets — never let local dev send real email.
• HTTPS with a trusted local cert. Most tools handle this; if rolling your own, use mkcert for OS-trusted local certs.
• Git hooks — pre-commit phpcs lint, pre-push test runs. Keeps the team aligned on quality without a separate review pass.

Database workflow

Most teams underuse the database side of local dev. A few patterns:

• Pull production DB into local periodically — wp db export on production, scp to local, wp db import, then wp search-replace prod.example.com local.example.com
• Use Migrate DB Proor WP CLI's built-in search-replace for the cleanup pass after import — URLs in serialized data need careful replacement
• For sensitive client data: sanitize before import. Use wp db query to scrub PII columns, or maintain a sanitized export script on production

Multi-site testing

If your work touches multisite-compatible plugins, run a multisite local setup at least occasionally. Behavior diverges in subtle ways — capabilities work differently, options live on the network level vs site level, plugin activation has two scopes (network-wide vs per-site).

DDEV: enable multisite during ddev config. Local: set in site config. Worth catching multisite bugs before a client multisite hits them.

Editor + tooling

The editor side matters too. The 2026 setup most agency devs run:

• VS Code with PHP IntelliSense, PHP Debug (Xdebug), WordPress Snippets, ESLint, Prettier. Or Cursor if AI-assisted code is part of your workflow — see AI Coding Tools Compared.
• PhpStorm for teams that lean heavy on refactoring, code intelligence, and integrated debugging. More opinionated, more capable.
• WP-CLI in your terminal with the wp-cli completion installed
• TablePlus or Sequel Ace for ad-hoc DB inspection

The migration story — local to staging to production

A local environment is most useful when there's a clean path to production. The shape:

1. Local — develop, test, run builds
2. Staging (managed host, often a one-click clone of production) — final QA, client review
3. Production

Code flows local → git → CI/CD → staging → production. Data flows production → staging → local on demand. Treat the data flow as one-way (production is the source of truth) and the code flow as one-way (local is the source of truth). Cross- contaminating directions is how data loss happens.

The right local setup pays itself back in the first week of serious work. The investment is small, the dividends are large, and most of the friction comes from sticking with a tool that doesn't fit your workflow. Pick the one that matches how you actually work, get the foundation pieces (WP-CLI, Query Monitor, Xdebug, Mailhog) configured once, and the rest gets out of the way. From here: Debugging WordPress Plugins Like a Pro is the natural next read, and WordPress Plugin Boilerplate Setup shows the project structure that pairs with this environment.