On June 8, 2026, Fellyph Cintra published a deprecation notice on the Make WordPress Playground blog: @wp-now/wp-now is officially dead. No more updates, no more bug fixes, no more npm publishes. If you have been using wp-now to spin up local WordPress environments for plugin testing, theme development, or quick demos, the tool you rely on just got a sunset date. The replacement is @wp-playground/cli, and the migration is intentionally boring.

This is not a catastrophe. The Playground team spent months closing the feature gap before pulling the plug. The start command in Playground CLI now mirrors everything wp-now did, plus a handful of things wp-now could not. But if your CI scripts, your onboarding docs, or your muscle memory still reference npx @wp-now/wp-now start, it is time to update them.

What wp-now actually was

wp-now made local WordPress development feel like running a Node script. No Docker. No MySQL. No Apache. You pointed it at a directory and it spun up a working WordPress site in the browser, powered by WordPress Playground's WebAssembly runtime. For plugin developers, it was the fastest way to test a change without touching a real server. For theme designers, it was a zero-config preview environment. For anyone writing WordPress tutorials, it was the tool that let readers try code in seconds instead of minutes.

The problem was that wp-now was a community package, not an official Playground tool. As WordPress Playground matured into an official WordPress project with its own CLI, the Playground team had to choose between maintaining two overlapping tools or consolidating into one. They chose consolidation. The @wp-playground/cli package is the official, maintained replacement, and wp-now is the package that got retired.

The migration is one line

If your current workflow looks like this:

npx @wp-now/wp-now start

Change it to this:

npx @wp-playground/cli@latest start

That is the entire migration for most users. The flags carry over too. If you were specifying a WordPress version, a PHP version, or a Blueprint file, those all work the same way:

npx @wp-playground/cli@latest start --wp=6.8 --php=8.3
npx @wp-playground/cli@latest start --blueprint=./blueprint.json

The --skip-browser and --reset flags are still there. The behavior is the same. The output is the same. The only thing that changed is the package name.

What changed under the hood

The one workflow difference is how Playground CLI handles persistence. With wp-now, the --path flag selected both the project directory and the saved site. With Playground CLI, the start command saves the site based on your current working directory. The stored site lives at ~/.wordpress-playground/sites/<path-hash>/, where the hash is derived from the directory you ran the command from.

The practical change: run the command from the project directory you want to persist. If you have a plugin at ./my-plugin, cd into that directory first:

cd ./my-plugin
npx @wp-playground/cli@latest start

This keeps each project's WordPress state isolated. If you run it from your home directory, you get one persistent site. If you run it from ten different project directories, you get ten separate persistent sites. Each one remembers its database, its installed plugins, and its settings between runs.

What you get that wp-now could not do

Playground CLI is not just a renamed wp-now. It is a bigger tool. The start command covers the wp-now use case, but the CLI also exposes server, run-blueprint, build-snapshot, and custom mount configurations. If you need lower-level control over how WordPress boots, how files are mounted, or how the environment is configured, those options exist now without switching tools.

The CLI also integrates with the broader Playground ecosystem. PR previews through the GitHub Action, saved sites that persist in the browser, and the Sites API for managing Playground instances all work through the same toolchain. wp-now was a standalone shortcut. Playground CLI is part of a system.

There is also a server command for advanced workflows. If you are building CI pipelines, scripting automated tests, or running Playground in a non-interactive context, server gives you explicit control over mounts, storage behavior, versions, and Blueprints. The start command is the friendly default. The server command is the power tool.

What to update

Three things need changing if you are still on wp-now.

First, your package references. Any package.json scripts, CI configurations, or documentation that reference @wp-now/wp-now should point to @wp-playground/cli instead. Use @latest to stay current, or pin a version if you need reproducibility.

Second, your path assumptions. If your scripts relied on --path to both mount a directory and select a saved site, adjust them so the script cds into the project directory before running start. The mount still works with --path, but the saved site association follows the working directory.

Third, your mental model. wp-now was a quick-and-dirty tool. Playground CLI is an official part of the WordPress development toolchain. It has a documentation site, a migration guide, and a team maintaining it. Treat it the way you treat WP-CLI: as a standard tool that is not going anywhere.

The bigger shift

WordPress Playground started as an experiment. Run WordPress in a browser. No server, no database, just WebAssembly. It was clever, but it was a demo. Over the last year, it has become infrastructure. The PR preview action lets reviewers test pull requests in a live WordPress environment without checking out code. The Sites API lets you create, save, and restore WordPress instances like containers. The CLI lets developers treat WordPress as a portable, disposable environment.

The wp-now deprecation is a signal that Playground has graduated from "cool side project" to "official tooling." The team is not maintaining two CLIs because they do not need to. The official one is good enough. If you have been waiting for Playground to feel production-ready before adopting it, the deprecation of its most popular community tool is the team telling you it is time.

The migration guide is at wordpress.github.io/wordpress-playground. The Make WordPress announcement is at make.wordpress.org/playground. Both are worth bookmarking if you develop anything for WordPress.