WordPress Studio: a Playground-backed desktop app and CLI for local WordPress work
WordPress Studio, a free desktop app and CLI that helps developers streamline their local WordPress development workflow.
At a glance
- What is it?
- WordPress Studio is a GPL-2.0 Electron application from Automattic that creates local WordPress sites through WordPress Playground, syncs them with WordPress.com or Pressable, and exposes the same features through a CLI. It removes the PHP, MySQL and web server setup step, but it also removes the control that setup gives you.
- Who is it for?
- WordPress Studio fits developers who want a WordPress site running in seconds, who work with WordPress.com or Pressable hosting, and who want the same operations available from a terminal through the Studio CLI. It does not fit anyone who needs a custom PHP version, a specific MySQL configuration, or a stack of server software they control.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What WordPress Studio replaces, and for whom
The standard local WordPress setup is a chain of installs: a web server, a PHP build with the right extensions, MySQL or MariaDB, and a way to keep them running. WordPress Studio's README states the app "requires no external dependencies" and that sites spin up "in seconds." That is the specific problem it addresses. The dependency chain is replaced by the application itself, which carries the runtime.
The intended user is a plugin or theme developer who wants to see changes against a real WordPress install without maintaining that install. The README frames the app as being for "creating and managing WordPress sites and testing and building plugins and themes locally." The secondary audience is anyone who needs to hand a working preview to a client or teammate, which the Preview Sites feature covers.
It is also, by design, a WordPress.com-adjacent tool. Sync targets are WordPress.com and Pressable. That is not a limitation of the software so much as a statement about who the software was built for.
How Playground, sync and the CLI fit together
The runtime is WordPress Playground. The README says Studio is "Powered by WordPress Playground and WordPress.com," and package.json describes the product as a "Local WordPress development environment using Playgrounds." Playground runs WordPress in a browser-oriented environment rather than as a conventional LAMP stack, which is why the app can ship without asking the user to install PHP or MySQL.
The repository is an npm workspace monorepo. package.json declares workspaces for apps/*, tools/* and packages/*, and the start script delegates to the studio-app workspace. The postinstall script downloads the pieces the runtime needs, including a PHP binary and WordPress server files, which is the concrete mechanism behind the "no dependencies" claim: the dependencies are fetched at install time and bundled rather than installed by the user.
Studio Sync moves data between a local site and a WordPress.com or Pressable production or staging site. The README describes it as selective, letting you choose "specific plugins, standalone themes, or the database." The desktop app and the CLI reach the same features; the README says the CLI exists to "access WordPress Studio features outside the desktop application."
Installing WordPress Studio and running a first site
The README does not present a command line install. It directs users to download the app from the WordPress.com Studio page for macOS, Windows or Linux, and states that no dependencies are required. If you want to build the application from source instead, the repository is an npm workspace and package.json pins the toolchain.
npm install
npm startThe devEngines block requires Node 24 or newer and npm 11 or newer, with packageManager set to npm@11.13.0. Running npm install triggers the postinstall script, which downloads the PHP binary, WordPress server files, site translations and agent skills. Expect that step to need network access; it is not a pure local install.
Once the app is open, the workflow the README describes is to create a site, work on it locally, and optionally push or pull through Studio Sync. The CLI exposes the same operations outside the app. The README does not list CLI subcommands, so check the documentation under developer.wordpress.com/docs/developer-tools/studio/ before scripting against it.
Where Studio is the wrong tool
If your work depends on a specific PHP version, a particular set of PHP extensions, or a MySQL configuration you control, Studio's bundled runtime is the wrong layer to fight. The app decides what runs. The README's framing of early access to "version support, and experimental features without needing to configure anything manually" is a benefit for most users and a constraint for anyone whose production environment differs from what Playground serves.
Preview Sites expire. The README states that preview sites expire after seven days without updates. A link handed to a client is therefore not a permanent artifact, and any workflow that treats it as one will break quietly.
Studio Sync is also not a general migration tool. It targets WordPress.com and Pressable. If your hosting is elsewhere, the sync half of the product does not apply to you, and you are left with the local development environment and the import feature the README mentions for bringing an existing site in.
Local by Flywheel and DevKinsta as the comparison point
The closest alternatives are Local by Flywheel and DevKinsta, both of which also wrap local WordPress in a GUI. The difference is architectural. Those tools provision a container or a virtualized stack with a real web server and a real database, and they expose configuration for PHP versions and database access. Studio runs WordPress through Playground instead, which is why it can claim no external dependencies and why it starts faster.
The trade is configurability. With a container-based tool you can open a database client, edit my.cnf, or swap PHP builds. With Studio, the runtime is a downloaded binary managed by the app. For plugin and theme development against current WordPress, that trade is usually worth taking. For debugging environment-specific behavior, it usually is not.
The second difference is sync. Local and DevKinsta pair with their own hosting products; Studio pairs with WordPress.com and Pressable. The choice of local tool is therefore partly a choice of hosting relationship.
Maintenance, releases and the GPL-2.0 licence
The repository is not archived, and the last push was on 2026-09-15. Releases are frequent: v1.21.0 on 2026-09-07, v1.20.0 on 2026-08-28, and v1.19.0 on 2026-08-24, with release notes kept in RELEASE-NOTES.txt at the repository root. That cadence matters for upgrade cost, because a desktop app that auto-updates will move under you. Pinning a version for a team is possible for the CLI side but the desktop application is the primary distribution channel.
The licence is GPL-2.0, declared in package.json as GPL-2.0-or-later and in the README as GPLv2. For internal use this changes nothing. If you intend to redistribute a modified build, the GPL obligations attach to the whole distributed work, and the repository's CONTRIBUTING.md and docs/code-contributions.md govern how changes are accepted upstream. This is a description of the licence, not legal advice; talk to counsel about your specific distribution plan.
The README also lists non-code contribution paths, including translation through GlotPress, which is worth knowing if your team localizes its tooling.
Editorial conclusion
WordPress Studio fits developers who want a WordPress site running in seconds, who work with WordPress.com or Pressable hosting, and who want the same operations available from a terminal through the Studio CLI. It does not fit anyone who needs a custom PHP version, a specific MySQL configuration, or a stack of server software they control. Before committing, verify the PHP and WordPress versions the bundled Playground runtime actually serves, and check that Studio Sync covers the plugins and database objects your site depends on, because the README describes selective sync at the level of plugins, standalone themes and the database, not individual tables.
Frequently asked questions
Does WordPress Studio require PHP or MySQL to be installed?
No. The README states the app requires no external dependencies, and package.json shows a postinstall script that downloads a PHP binary and WordPress server files. The runtime comes from WordPress Playground rather than from software you install yourself.
How long do WordPress Studio preview sites stay online?
The README states that preview sites expire after seven days without updates. A preview link is a working artifact, not a permanent deployment.
Which hosting providers can WordPress Studio sync with?
Studio Sync targets WordPress.com and Pressable production or staging sites, and the README describes choosing which plugins, standalone themes or database content to move. Other hosts are not covered by the sync feature.
Community notes