One CLI From Local Sandbox to Production

If you build WordPress sites for a living, your terminal is already where most of the real work happens. The tools that ship sites still lag behind that reality. InstaWP CLI is a standalone, npm-installable command-line tool that creates and manages WordPress sites from your terminal.

Local sandboxes, cloud sites, SSH, WP-CLI, sync, and CI/CD pipelines all run from one binary. This guide is for WordPress developers, agencies, freelancers, plugin and theme authors, and anyone whose AI coding agent needs a real WordPress environment to work against.

Key Takeaway

InstaWP CLI is a standalone npm package (@instawp/cli) that creates and manages WordPress sites from the terminal, with no Docker, no MySQL, and no desktop app required.

It covers the full WordPress lifecycle: local sandboxes via WordPress Playground, cloud sites on InstaWP infrastructure, SSH, WP-CLI execution, file sync, and team management.

AI coding agents like Claude Code, Cursor, and Codex can drive InstaWP CLI directly because every command supports --json output and a single INSTAWP_TOKEN environment variable.

Agencies and freelancers can spin up per-PR preview sites, demo sites, and client environments programmatically inside CI/CD pipelines.

What is InstaWP CLI

InstaWP CLI is a Node-based command-line tool that lets you create and manage WordPress sites from the terminal. You install it once with npm, authenticate either through your browser or with an API token, and from there a single binary handles everything from local development to cloud hosting on InstaWP infrastructure.

It is open source under the MIT license, requires Node.js 18 or higher, and is published to npm as @instawp/cli. Installation is one line:

npm install -g @instawp/cli

npm install -g @instawp/cli

The tool resolves sites by ID, name, or domain, so you do not need to memorize anything. It manages SSH keys for you. It generates one, uploads it, and caches the connection. WP-CLI works through the same binary.

Local-to-cloud sync happens through a single command. Every command supports --json for clean machine-readable output, which matters more than most product launches admit. Modern CI runners and AI agents need parseable output, not human-friendly tables.

A few weeks ago Automattic released Studio CLI as a standalone npm package, decoupled from the Studio desktop app. It is a thoughtful release. WordPress Playground in your terminal is genuinely useful. You can create a local site, run WP-CLI, and publish a temporary preview to WordPress.com.

Studio CLI also makes the case clearly: terminal-native WordPress tools are now table stakes, especially because AI agents work best in a CLI environment. Claude Code, Cursor, and Codex can all read shell output and run commands. They cannot use a desktop GUI.

So the question for everyone else is not whether the WordPress workflow belongs in the terminal. It does. The question is how far the terminal can take you.

InstaWP CLI was built around a wider scope from day one. Local sites are part of it, but so is cloud provisioning, real SSH, real WP-CLI on hosted sites, and one-command sync between environments. You sign in once and the same binary serves the full development-to-production lifecycle.

The problems InstaWP CLI was built to solve

Modern WordPress workflows are stitched together from too many tools. A typical agency stack still looks like this: Local by Flywheel for development, a separate host for staging, another host for production, FTP or rsync to move files between them, phpMyAdmin to handle the database, and a search-replace script when URLs change. Every transition is a context switch and a chance for something to break.

The pain shows up in five specific places:

Local environment setup eats hours

Docker on Windows ships slow file mounts. MAMP throws port conflicts. XAMPP hides PHP version differences from staging. Onboarding a new developer to a project can take half a day before any code is written.

InstaWP CLI launches local sites through WordPress Playground, which is PHP compiled to WebAssembly. There is no Docker dependency. No MySQL install. No Apache config. The site runs inside Node.

Local and cloud feel like different products

Most teams use one tool to build locally and a completely different platform to host. Migrating between them means manual database exports, search-replace queries, and tested deploy scripts. InstaWP CLI keeps both under one auth. instawp sites list shows your cloud sites. instawp create provisions a new one. SSH and WP-CLI work against any of them.

AI agents need a CLI, not a UI

If your AI coding agent is going to set up a WordPress site, run a test, deploy a change, and tear it down, every step has to be a shell command with parseable output. This is exactly why Studio shipped a CLI. InstaWP CLI was structured this way from the beginning, with --json on every command and a token-based auth flow that works inside CI.

CI/CD with WordPress is awkward.

Spinning up a per-pull-request preview site, running a smoke test, and tearing it down is something most teams want but few actually have. With a single environment variable and three commands you can do exactly that. The CLI’s CI example in the README is six lines.

Agency client work is repetitive

Creating a new WordPress sandbox for a client demo, copying a template, configuring SSH, and handing it off should not require a dashboard click-through. The CLI replaces that with a script you can rerun.

Who this is built for

What you can actually do with it

Rather than walking through every flag, here is the shape of a real workflow.

1. Authentication takes one command. instawp login opens your browser and finishes the handshake. For CI environments, set INSTAWP_TOKEN and skip the login step entirely.
2. Creating a site is one line. instawp create --name my-site --php 8.3 provisions a cloud WordPress site with PHP 8.3 and waits for it to be ready before returning. With --json, you get a machine-readable response you can pipe into another step.
3. Running WP-CLI commands works through a shorthand. instawp wp my-site plugin list runs wp plugin list against the site you named. The CLI handles the SSH connection in the background. No key generation, no host configuration, nothing in your ~/.ssh/config.
4. Opening a real shell is the same experience. instawp ssh my-site drops you into an interactive session. The CLI generated and uploaded the key the first time you connected and now caches it.
5. Syncing files uses rsync under the hood. instawp sync push my-site --path ./wp-content/ pushes your local theme or plugin work up. instawp sync pull brings the remote state down. There is a --dry-run flag because nobody trusts a sync the first time, and you should not.
6. Deleting a site cleans everything up. instawp sites delete my-site --force is what your CI tear-down step looks like.
7. A complete CI workflow for per-PR preview sites can be expressed in roughly the lines you would expect:

export INSTAWP_TOKEN=${{ secrets.INSTAWP_TOKEN }}
instawp create --name "pr-$PR_NUMBER" --json
instawp wp "pr-$PR_NUMBER" option get siteurl
instawp sites delete "pr-$PR_NUMBER" --force

export INSTAWP_TOKEN=${{ secrets.INSTAWP_TOKEN }}
instawp create --name "pr-$PR_NUMBER" --json
instawp wp "pr-$PR_NUMBER" option get siteurl
instawp sites delete "pr-$PR_NUMBER" --force

That is the entire lifecycle of a preview environment.

How InstaWP CLI compares

The terminal CLI space for WordPress is not empty, but most of the existing tools were built for a single slice of the workflow. Studio CLI focuses on local development and WordPress.com previews. wp-env is a Docker-backed local-only tool from the WordPress core team.

Local by Flywheel has an experimental CLI but expects the desktop app to be installed. None of them currently span local development and managed cloud hosting in one binary.

If your work ends at local development, Studio CLI or wp-env can be the right fit. If your work has to ship to a real production environment with backups, CDN, and SSL, you eventually need a CLI that follows you all the way there. That is the gap InstaWP CLI is built to close.

Putting it inside an AI agent workflow

The cleanest pairing for InstaWP CLI today is an AI coding agent like Claude Code. Tell the agent you want a WordPress site to test a plugin against, and it can run instawp create --name plugin-test --php 8.3 --json, parse the response, push the plugin code with instawp sync push, run instawp wp plugin-test plugin activate my-plugin, hit the site URL to verify, and then instawp sites delete --force when done.

Every step is a shell command. Every output is JSON. Nothing is hidden in a desktop UI the agent cannot see.

This is what Rich Tabor flagged when announcing Studio CLI. Putting WordPress in the terminal is what unlocks AI agents. InstaWP CLI extends that idea to the production side of the workflow.

Where the CLI fits in the broader InstaWP platform

The CLI is one entry point into the InstaWP platform, not a separate product. The same sites you create with instawp create show up in your dashboard. They share the same WordPress sandbox and WordPress staging sites features available through the UI.

You can promote a sandbox to a permanent hosted site, attach a domain, enable backups, and continue managing everything from either the terminal or the web. Teams and agencies can layer in WaaS workflows on top, where the CLI becomes the automation backbone for client provisioning.

This matters because most CLI tools force a choice. Either you live in the terminal forever or you leave it for the dashboard. Here both work on the same data, so a developer can script and a client services lead can click, and they end up at the same site.

Getting started in two minutes

If you have Node.js 18 or higher, the full setup is short. Install the CLI globally, authenticate, and create your first site:

npm install -g @instawp/cli

npm install -g @instawp/cli

instawp login

instawp login

instawp create ----name my-site --php 8.4

instawp create ----name my-site --php 8.4

You will have a running WordPress site in seconds. From there, instawp ssh, instawp wp, and instawp sync are the three commands you will reach for most often.

Must Read: Introducing InstaWP CLI: WordPress Sites From Your Terminal

For CI environments, generate an API token from your dashboard and export it as INSTAWP_TOKEN. The CLI will skip the login step and use the token directly.

The full README, including every command and flag, lives on the InstaWP CLI GitHub repo. It is in beta, so issues and feedback go through GitHub Issues.

Conclusion

The WordPress workflow has moved into the terminal because that is where modern development already lives. Studio CLI confirmed it. AI agents accelerated it. InstaWP CLI takes that idea and follows it through the entire site lifecycle, from a local Playground sandbox on your laptop to a fully managed WordPress cloud hosting site in production, with the same binary, the same auth, and the same scripts.

If you have ever lost an afternoon to Docker, retyped the same site setup for the tenth client, or wanted your AI agent to actually operate a real WordPress site instead of just writing code about one, this is the tool.

Get started with InstaWP CLI today and claim $25 in free credits to spin up your first sites. Create a free InstaWP account →

FAQs