wp-now Is Deprecated: Migrate to WordPress Playground CLI

Every few years, a small developer tool quietly becomes the thing you reach for without thinking. For a lot of us building plugins and themes, wp-now was one of those. No Docker, no MySQL, no Apache — just npx in a plugin folder and you had a working WordPress site in seconds. It made writing demos, reproducing bugs, and shipping a quick prototype almost frictionless.

That tool is now officially retired. The WordPress Playground team announced this week that @wp-now/wp-now is deprecated and that all future local-development work moves to the @wp-playground/cli package. The change is small in code and large in habit, which is exactly the kind of change that catches teams a quarter later when something breaks in CI and nobody remembers why.

So here is the honest version: what actually changed, what to type instead, and what I would do about it on a Monday morning in a shop that ships WordPress for real clients.

What is actually new

On 8 June 2026, Fellyph Cintra posted the official notice on Make WordPress Playground: wp-now is deprecated, migrate to Playground CLI. The reasoning is simple. New local-development work has moved to the official Playground CLI, and the start command there now offers the familiar wp-now behavior plus more configuration room. The official Playground docs page for wp-now now carries the same notice: the npm package @wp-now/wp-now will not receive further updates.

The replacement is @wp-playground/cli. According to the official Playground CLI documentation, it requires Node.js 20.18 or higher and exposes two main commands. start is the simplified path: it auto-detects whether you are sitting inside a plugin or a theme folder, auto-mounts it, persists the site between sessions under ~/.wordpress-playground/sites/, logs you in, and opens the browser. server is the advanced path: manual mounts, manual configuration, no automatic persistence, well suited to CI pipelines.

The migration itself is small. From the deprecation post:

# Before
npx @wp-now/wp-now start

# After
npx @wp-playground/cli@latest start

Existing flags you used with wp-now — --wp=<version>, --php=<version>, --blueprint=<path>, --port=<port> — keep working the same way. The biggest mental shift: run the command from inside the project folder you want to mount, rather than passing --path. Auto-mount handles the rest.

This is not happening in isolation. The June 2026 developer recap on developer.wordpress.org lists the wp-now deprecation alongside Gutenberg 23.3’s new modal media editor, the React 19 revert, and ongoing Abilities API refinements. And Fellyph Cintra’s WordCamp Europe 2026 session — What’s new in WordPress Playground — covers the wider story: a Blueprints Editor, a File Editor, an Admin Database Manager, modular PHP versions, OpCache support, and over 40% performance gains in the runtime. The CLI move is part of a Playground platform that has matured fast.

Why it matters for WordPress and WooCommerce people

If you only ever click around in wp-admin, this is a non-event. If you maintain plugins, themes, or WooCommerce extensions, three things change in your day.

First, your README files and onboarding docs are about to lie to your contributors. Anywhere your repo says “run npx @wp-now/wp-now start to spin up a dev site”, that command still works today, but it will receive no fixes. New contributors who land on a fresh laptop in six months may hit edge cases that have already been fixed upstream — only on the new package. Stale onboarding is one of the quietest forms of contributor friction.

Second, your CI matrix needs a look. If you use Playground in GitHub Actions to spin up disposable WordPress environments for end-to-end tests, the server command in @wp-playground/cli is the right surface — it gives you explicit control over mounts and ports, which is what you want in a pipeline. The wp-now flow will keep working for a while; it just stops getting better.

Third — and this is the bigger picture — Playground itself is becoming the standard local environment for WordPress, not just a browser demo toy. Blueprint files let you describe a full WordPress install (specific WP version, specific PHP version, specific plugins, specific landing page, pre-logged-in user) as a single JSON file you can commit to your repo. The run-blueprint and build-snapshot commands turn that into reproducible CI jobs and shareable ZIP snapshots. For agencies, that means a client demo, a reproduction case, and a CI environment can all be the same artifact. That is the kind of thing WordPress has historically not done well, and it is now real.

What I would do (or not do) about it

If you have a single side-project plugin, do this in five minutes today: open your README, swap the wp-now command for the Playground CLI equivalent, run it once locally to make sure your plugin still auto-mounts, and commit. Done. You will not feel the difference for weeks, and that is the point — your future contributors will not feel the friction either.

If you maintain a serious plugin or theme codebase — the kind with a CONTRIBUTING.md, GitHub Actions, and more than one developer — treat this as a small, scheduled migration. Concretely: add a blueprint.json to your repo, pin a WordPress version and a PHP version your test suite cares about (PHP 8.3 is the current Playground default; pin lower if your minimum support matters), wire npx @wp-playground/cli@latest server into your e2e job, and delete the old wp-now references in the same PR. That is one afternoon of work and it removes a class of “works on my machine” tickets for a year.

What I would not do: panic-rewrite anything in production. wp-now was a local dev tool. Nothing on your live site depends on it. Nobody is going to break a client site over this. The risk here is purely contributor experience and CI reliability, not uptime.

And if you have been on the fence about Playground as a serious environment, this is the moment to look again. The combination of Blueprints, the new CLI, the Admin Database Manager, and a 40%-faster runtime makes it credibly the fastest way to stand up a clean WordPress for any purpose — bug repro, client demo, plugin smoke test, training material. It earns the upgrade.

One sentence to take with you: WordPress quietly fixing the boring parts — local dev, reproducibility, CI — is exactly the kind of maturity work that makes the platform keep winning over the next decade, even when nobody writes a press release about it.