A ready site per CI job
Waits for HTTP, then returns logins as JSON.
$ instawp create --name pr-42 --temporary --jsonThe 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.
Your agent runs the whole cycle from one prompt and one token. It builds on a free local WordPress, pushes to a cloud site, reads the live logs when something breaks, then patches and pushes again.
Every later push lands on the same linked site, so the loop is patch, push, check the log.
# free, on this machine: WASM PHP + SQLite, no Docker
$ instawp local create --name acme
✓ Instance "acme" created
# Starting WordPress latest with PHP 8.3...
→ http://127.0.0.1:9400
you › build a membership checkout on acme
✓ agent scaffolds the plugin and the checkout page
# first push creates the cloud site and links it to acme
$ instawp local push acme --with-db --force
✓ Cloud site created
✓ Site provisioned
✓ Cloud DB backed up: ~/db-backup-….sql.gz
✓ Database imported · URLs rewritten
✓ Push complete!
$ instawp logs acme --php -n 20
PHP Warning: Undefined array key "tier" in checkout.php on line 42
$ instawp wp acme --api -- option get acme_tiers
Error: Could not get 'acme_tiers' option. Does it exist?
you › fix it locally and push again
$ instawp local push acme
✓ guard added · same site updated · log is quiet
An in-site MCP stays safe by blocking risky writes. The CLI lets the agent act, then puts the whole site back if a change goes wrong.
db push saves the remote database first and fixes a mismatched table prefix, so admin login survives.--json it errors instead of waiting on a prompt.Clone a cloud site into a free local sandbox, work on it offline, then ship it back with its database. WordPress has no official SQLite to MySQL exporter, so the CLI converts both ways.
$ instawp local clone acme
$ instawp local push acme --with-db
Everything an agent or a CI job needs to provision, deploy, run, observe and recover, addressed by site name and authenticated with one token.
Waits for HTTP, then returns logins as JSON.
$ instawp create --name pr-42 --temporary --jsonSQL and WP-CLI over HTTPS, real exit codes.
$ instawp exec acme --shell 'wp cron event list | grep due'PHP and WordPress logs as structured JSON.
$ instawp logs acme --php --wp --jsonDry-run a wp-content mirror, or install a plugin.
$ instawp sync push acme --delete --dry-run
$ instawp plugin install acme ./plugin --activateA no-Docker WASM copy, pushed back with its DB.
$ instawp local clone acme
$ instawp local push acme --with-dbA named version, plus a gzipped DB dump.
$ instawp versions create acme --name pre-deploy
$ instawp db pull acme --output backup.sql.gzFiles and database, back in one command.
$ instawp versions list acme
$ instawp versions restore acme <id> --forcePoint the token at a single team's sites for agency and fleet automation.
$ instawp teams switch acme-clientsThe 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.
instawp create --temporaryacme.instawp.site/insta-mcp?t=…create · patch · pluginslocal push · versions restoreAccount 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 →
Three commands from zero to a CLI your agent or your CI can drive.
$ npm install -g @instawp/cliChecks for a new version once a day. instawp upgrade installs it.
$ instawp loginOpens your browser. In CI, pass --token or set INSTAWP_TOKEN.
$ instawp whoamiShows the account and the team the token is scoped to.
--api: no SSH setup, works behind firewalls and in CI.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.