Local WordPress development on a Mac comes down to a choice between WordPress-specialized tools and a general PHP environment. The specialized tools (LocalWP, WordPress.com's Studio) install WordPress for you and add host-specific extras like push-to-staging. A general environment treats WordPress as what it is — a PHP app with a MySQL database — and serves it alongside your Laravel, Node and static projects. Which one fits depends on whether WordPress is your whole week or one project among several.
The specialized route, honestly
- LocalWP (Local by Flywheel) — the most popular choice: one-click WP installs, blueprints, and push/pull to WP Engine and Flywheel hosting. If you live on those hosts, that sync alone can decide it.
- Studio by WordPress.com — lightweight and free, built on WordPress Playground; quick for theme tinkering, with sync into the WordPress.com ecosystem.
- wp-env / Docker— the core team's reproducible-environment tool; right for plugin CI, heavy for day-to-day client work (it inherits Docker-on-Mac's VM overhead — the trade-offs).
The common limitation: they're WordPress-only. The moment a client project arrives that isn't WordPress, you're running a second environment beside the first.
The general-environment route
WordPress needs PHP-FPM, MySQL, a domain and mail — the same stack as any PHP app (assembled by hand in Local PHP development on a Mac). MAMP built its reputation on exactly this; Herd handles WP behind its paid database tier; ServBay does it on subscription. PortBay is the free, open-source version of the same idea. The WordPress setup:
- Drop a WordPress folder into PortBay (or point it at a fresh download) and press play — PHP version pinned, site served at
https://mysite.testwith a trusted certificate. Pretty permalinks work; no MAMP-style port juggling. - Create the MySQL database in one click and run the famous five-minute install against it.
- Outgoing mail — password resets, WooCommerce receipts, contact-form plugins — lands in the built-in local inbox instead of vanishing or needing an SMTP plugin.
- Client preview: a one-click Cloudflare tunnel gives the site a public HTTPS URL without deploying. (Trusted local HTTPS also means payment-gateway sandboxes and OAuth plugins behave like production — the details are in the local HTTPS guide.)
- Migrating an existing site from MAMP? The import is automated.
WordPress multisite, locally
Multisite — one WordPress install serving a network of sites — adds exactly one local-dev decision: subdirectory or subdomain mode. Subdirectory mode (mysite.test/client-two) is the easy one, and works in any environment that serves the main domain: add define('WP_ALLOW_MULTISITE', true); to wp-config.php, run Network Setup from Tools, paste the generated config and rewrite rules, done. Nothing about your environment changes; it's a WordPress configuration, not a tool feature.
Subdomain mode (client-two.mysite.test) is where local setups usually break, for two infrastructure reasons: every subdomain has to resolve (wildcard DNS — *.test via dnsmasq covers it), and the HTTPS certificate has to cover *.mysite.test— a single-host certificate won't, which is why subdomain networks greet you with browser warnings on tools that issue per-site certs. mkcert can issue a wildcard cert in one command (mkcert mysite.test "*.mysite.test"); the wiring is covered in the local HTTPS guide. The practical advice: develop in subdirectory mode unless production genuinely runs subdomains — the modes aren't interchangeable after setup, so mirror production, but don't volunteer for the wildcard plumbing you don't need. (LocalWP, to its credit, asks the mode question at site creation and handles the local URLs for you.)
Agency reality: WordPress is rarely alone
The strongest argument for the general environment is the project list itself. A typical freelancer or agency Mac is running a couple of WordPress sites, a Laravel app, something in Next.js and a static site — and one tool serving all of them beats one tool per stack. Each project gets its own runtime version, domain, certificate and database, side by side.
Where agents fit
WordPress work is full of bounded, checkable tasks — “add a custom post type,” “fix the contact form's validation,” “the receipt email renders broken in dark mode” — which makes it a natural fit for AI coding agents, if the agent can see a running site. PortBay's task board dispatches Claude Code, Codex, Cursor or Antigravity into the running WordPress install: the agent edits the theme, loads https://mysite.test, checks the email in the inbox, and reports back on the card (the assignment workflow). The specialized WP tools don't have an answer to this yet.
Recommendation
All-WordPress, hosted on WP Engine or WordPress.com: stay specialized — LocalWP or Studio, the workflow integration is worth it. Mixed projects, multiple clients, or agents in the loop: a general environment is the better daily driver, and PortBay does it free, open source and with the agent board built in.