@instawp/cli · beta

Drive WordPress from your terminal.

The scriptable side of InstaWP. One token, local (free, no Docker), your cloud sites, and the sync between them, all non-interactive and drivable by any AI agent or CI. Provision, deploy, run, and roll back, from one command line.

Install the CLI → See every command

JSON on every command Remote WP-CLI, no SSH setup One INSTAWP_TOKEN

your terminal

$ npm install -g @instawp/cli
$ instawp login
✓ authenticated
# a real WordPress, ready when the command returns
$ instawp create --name demo --json
→ { "url": "https://demo.instawp.site", "http_ready": true }

Build, troubleshoot, and ship, in one loop.

An agent (or you) drives the whole cycle from one prompt: spin up a real WordPress locally for free, fix it against live logs, then push it to a cloud site and sync. No Docker, no SSH setup, no context switching.

claude code · instawp

$ export INSTAWP_TOKEN=iwp_••••

# 1 · BUILD ·····
# real WordPress on this machine: WASM PHP + SQLite, no Docker, free
$ instawp local create --name acme
→ ready · http://acme.localhost · wp-admin seeded
you› build the membership flow against acme, I'll watch
✓ agent scaffolds the plugin, posts, and a checkout page locally

# 2 · TROUBLESHOOT ·····
$ instawp logs acme --follow --php
PHP Warning: undefined array key "tier" in checkout.php:42
$ instawp wp acme -- option get acme_tiers --api
✓ agent patches the guard, the log goes quiet

# 3 · SHIP ·····
# local push provisions a cloud site AND deploys it, DB backed up first
$ instawp local push acme --with-db
→ cloud backed up · URLs rewritten · live: https://acme.instawp.site
✓ one session: local build → fix → live, no handoffs

Let the agent act freely, wrapped in a checkpoint.

Autonomy needs an undo button. An in-site MCP plays it safe by blocking risky writes. The CLI takes the stronger bet: act, but keep a one-command undo and a rollback artifact for the moves that can brick a site.

An undo button

Checkpoint a site (files and database), let the agent run a risky batch, roll the whole thing back in one command if it goes wrong.

$ instawp versions create acme --name "before refactor"
$ instawp versions restore acme <id> --force
# files + DB, restored in place

Safe database deploys

The riskiest WordPress move, made boring. db push backs the remote up first by default, fixes table-prefix mismatches so admin login survives, and rewrites URLs serialization-safe.

$ instawp db push acme dump.sql.gz --rewrite-prefix
→ backed up to ~/db-backup-….sql.gz
# then --search-replace, guid skipped

A --json safety contract

A DB push or a version restore will not run in --json without --force: it errors, it never hangs on a prompt. Failures return {success:false}; remote runs pass through their real exit codes.

$ instawp versions restore acme <id> --json
→ error: use --force (exit 1)

Pull a live site down. Push it back up.

Clone a real cloud site to a free, no-Docker sandbox on your machine (WordPress Playground: WASM PHP and SQLite). Iterate offline, then ship it back, database and all. WordPress has no official SQLite to MySQL exporter, so the CLI does the conversion for you.

instawp · local round-trip

# pull a live site down to a free, no-Docker sandbox
$ instawp local clone acme
→ MySQL→SQLite · URLs rewritten · wp-content synced · running on WASM
you› refactor the theme against the local copy, offline
✓ agent iterates with zero cloud round-trips

# ship it back: cloud backed up first, data-only, URLs rewritten
$ instawp local push acme --with-db
→ cloud backed up · imported · search-replace done · cache flushed

The whole control surface.

Everything an agent or a CI job needs to provision, deploy, run, observe, and scope, addressed by site name and authenticated with one token.

Provisioninstawp create --name pr-42 --temporary --jsonPolls for HTTP readiness so CI skips the curl-retry loop, then returns admin creds and a Magic Login URL.

Local ⇄ cloud

instawp local clone acme
instawp local push acme --with-db

Pull a live site down to a no-Docker WASM sandbox, push it back with its database.

Deploy files

instawp sync push acme --delete --dry-run
instawp plugin install acme ./plugin --activate

Mirror your local wp-content to the remote (preview first), or ship a plugin from a directory.

Run anything

instawp wp acme -- option get siteurl --api
instawp exec acme --shell 'wp cron event list | grep due'

WP-CLI and SQL over HTTPS, plus any shell pipeline. Real remote exit codes.

Observeinstawp logs acme --php --wp --jsonStructured log payloads the agent reasons over: the observe half of an observe-act loop.

Recover

instawp versions create acme --name pre-deploy
instawp db pull acme --output backup.sql.gz

Checkpoint before a risky change, or pull a gzipped database dump as a rollback artifact.

Scopeinstawp teams switch acme-clientsPoint one token at a single team's sites for agency and fleet automation.

Roll back

instawp versions list acme
instawp versions restore acme <id> --force

List restorable site versions, roll a site back to any one of them in place.

A preview site per pull request, then torn down.

Every command speaks JSON and runs non-interactively, with faithful exit codes and notices kept off stdout. The textbook ephemeral-environment pattern is a few lines, no curl-retry loop and no hand-rolled readiness gate.

ci · preview-per-pr.sh

$ export INSTAWP_TOKEN=iwp_••••
# spin up an auto-expiring preview, JSON back for the runner to parse
$ instawp create --name pr-$PR_NUMBER --temporary --json
→ { "url": "https://pr-128.instawp.site", "http_ready": true, "wp_admin_url": "…" }
# deploy this build and run the suite against the live URL
$ instawp sync push pr-$PR_NUMBER --delete --yes
$ instawp wp pr-$PR_NUMBER -- plugin activate acme --api
# tear it down (destructive ops need --force in --json, so no accidents)
$ instawp sites delete pr-$PR_NUMBER --force --json
✓ created → tested → destroyed, exit code is the test result

The CLI sets the stage. The MCP does the work.

The MCP acts inside one install through schema-validated tools. The CLI acts on the environment around it: provision, deploy, recover, scope. The loop that ties the two together is the whole point.

CLIProvision a targetinstawp create --temporary

›

CLIHand off its MCP URLacme.instawp.site/insta-mcp?t=…

›

MCPAgent builds inside itcreate · patch · plugins

›

CLIShip it, or roll it backlocal push · versions restore

Account MCP, on steroids. The CLI already spans local (free, on your machine), remote (your cloud sites), and sync between them. Fully scriptable, drivable by any agent or CI, today. See the MCP →

One install, one token.

Install itnpm install -g @instawp/cliNode package, updates itself once a day. instawp upgrade keeps you current.

Authenticateinstawp loginOpens the browser. For CI, use instawp login --token <api-token> or set INSTAWP_TOKEN.

Check your sessioninstawp whoamiConfirms the account and team the token is scoped to.

Any site by name, ID, or domain. The CLI resolves it for you.
Remote WP-CLI and SQL over HTTPS with --api, no SSH setup, works behind firewalls and in CI.
macOS, Linux, and Windows. Local sandboxes run on WordPress Playground (WASM), no Docker required.
Beta, in active development. Report issues on GitHub.

Dev Tools →SSH, Local Mount, InstaCode, Git

AI & MCP →The in-site MCP the CLI hands off to

API & Webhooks →Provision sites over REST

Put WordPress on the command line.

Install the CLI, point it at a free local sandbox or a live cloud site, and let your agent or your CI drive the whole loop.

Install the CLI → Read the docs

✓ One token · local + remote + sync · drivable by any agent or CI