v0.0.1-beta.31

Fixed — remote docroot resolved from the server (domain-cutover sites)

After a custom-domain cutover, the platform API reports the new primary domain (e.g. instawp.com) as the site's sub_domain/main_domain, but the HestiaCP web dir keeps the original name (instawp-marketing.instawp.site). The CLI built remote paths as ~/web/<api-domain>/public_html, so exec/wp (SSH) cd'd into a nonexistent dir ("No such file or directory") and sync pushed to the wrong, non-served path — only an absolute --remote-path worked.

• ensureSshAccess now resolves the real web dir from the server (resolveRemoteWebDir — an SSH lookup for the public_html that actually holds wp-config.php) and stores it in conn.domain (resolved once, cached). All path construction — exec/wp cd, sync's buildRemotePath, db, migrate — now targets the served docroot. No API field exposes the original name, so this is done over SSH; best-effort, keeps the API domain if the lookup fails.
• Verified end-to-end: instawp wp <cutover-site> option get siteurl → https://instawp.com, exit_code: 0 (previously failed on a bad cd).

v0.0.1-beta.30

Fixed — CLI auto-resolves the SSH origin for CDN-fronted sites (no env var needed)

beta.29 made SSH fail fast on CDN-fronted sites but still required INSTAWP_SSH_HOST=<origin>. The CLI now figures out the origin itself:

• ensureSshAccess prefers the origin IP from site_meta.ip_addr (via GET /sites/{id}/credentials) over the update-ssh-status host, which for a CDN-fronted site is the proxied edge (port 22 filtered). This is exactly what InstaWP's own SSH bridge does (ip_addr ?? sub_domain). Verified end-to-end against a real CDN-fronted site: it now resolves the reachable origin and connects with no override.
• Host precedence: explicit override (--ssh-host / INSTAWP_SSH_HOST) > auto-detected origin IP > API host.
• Self-heal: if a cached host fails preflight (e.g. a CDN host cached before this shipped), the cache is dropped and re-resolved automatically — no manual --refresh needed.

INSTAWP_SSH_HOST / --ssh-host remain as a manual override for sites where the API doesn't expose ip_addr.

v0.0.1-beta.29

Fixed — SSH-backed commands hung ~2 min on CDN-fronted sites

When a site is fronted by a CDN (Bunny), the platform API returns the proxied edge hostname — port 22 there is unreachable and the origin is never exposed — so every SSH-backed command (sync, db, logs, ssh, plugin install, local, migrate push, wp/exec in SSH mode) hung for ~2 minutes then failed with a raw Operation timed out.

• Origin-host override. Point SSH at the true origin: env INSTAWP_SSH_HOST (global) or INSTAWP_SSH_HOST_<siteId> (per-site, wins over global), or the --ssh-host <host> flag on sync/db/ssh/wp/exec. The override beats the API host and is applied even to a stale cached (pre-cutover) host. --refresh drops the cached host and re-resolves (use once after the platform starts returning the origin).
• Fast-fail preflight. Before any SSH/rsync/scp, the CLI TCP-probes host:port (~5s) and, if unreachable, replaces the 2-minute hang with an actionable diagnostic ("…likely behind a CDN…set INSTAWP_SSH_HOST / retry with --api / update the platform").
• wp/exec auto-fall-back to --api when SSH is unreachable (gated by --no-fallback). The run-cmd API transport isn't behind the CDN.
• db pull --api / db push --api. A non-SSH transport over run-cmd (base64+gzip round-trip; push chunks the dump and imports it, with a remote backup first and optional --search-replace). Best for small/medium DBs — one/many API round-trips, no streaming; --timeout overrides the per-call budget; --incremental isn't supported over --api. For large DBs use SSH (set INSTAWP_SSH_HOST if CDN-fronted).

Companion platform ticket (the real fix): update-ssh-status / sites/{id}/details should return the SSH origin host/IP (e.g. origin_ip/ssh_host), not the CDN-fronted sub_domain. Once it does, the CLI prefers it and SSH works globally with no override. Until then the above are the mitigations.

Not yet included: sync --api (a whole-tree per-file base64 loop over run-cmd) — deferred; use INSTAWP_SSH_HOST for file sync to CDN-fronted sites, or db --api + wp --api for DB/commands.

v0.0.1-beta.28

Added — cache purge

• instawp cache purge <site> purges the site's CDN edge cache (the CLI equivalent of the dashboard "Purge Cache" button; POST /sites/{id}/purge-cache). --object additionally clears the server object cache (Redis; POST /sites/{id}/clear-object-cache). Both features are plan-gated — when absent the CLI reports a "skipped" no-op (not an error) and points to instawp wp <site> cache flush for the WordPress-level object cache.

v0.0.1-beta.27

Fixed — sync push/pull include/exclude ordering (#18)

• sync push/pull now emit user --include patterns BEFORE user --exclude patterns. rsync is first-match-wins, so the previous order (excludes first) made the standard include-only idiom (--include '*/' '*.html' --exclude '*') silently match nothing — the catch-all --exclude '*' matched every path before any include was considered, looking exactly like "already in sync." Ordering is now built by a pure, unit-tested buildSyncFilterArgs helper. (--delete stays last; it's an action flag, not a filter rule.)

Added — migrate push (local WordPress → new hosted site)

• instawp migrate push [path] mirrors an on-disk WordPress install up to a brand-new hosted InstaWP site — the standalone-CLI replacement for the plugin's wp instawp local push. It archives the WP files (zip), exports the DB (wp db export if wp-cli works on the install, else mysqldump from wp-config.php creds), creates a reserved site, uploads both archives into the new site's webroot over SSH, and triggers the server-side restore-raw engine (PUT /sites/{id}/restore-raw), which unzips, imports, and search-replaces the old domain → new domain to produce a faithful copy.
• Runs entirely on the CLI's personal API token over site-scoped routes — no Connect record and no migration-dashboard/tracking entry is created (the actual files+DB migration is identical to the plugin's).
• Files archive excludes exactly what the plugin does: wp-content/instawpbackups, wp-content/upgrade, and the instawp-connect / instawp-helper / iwp-migration plugins.
• Flags: --path, --name, --source-url (auto-detected from wp-cli/wp-config when omitted), --wp, --php, --keep-archives, --dry-run, --json. The WP root is auto-located by walking up to wp-includes/version.php.
• New libs lib/wp-local.ts (WP-root/wp-config/version detection + source-domain normalization, all pure & unit-tested) and lib/wp-archive.ts (streaming zip via archiver + DB export). Adds the archiver dependency.

v0.0.1-beta.26

Added — incremental db push (#17)

• db push --incremental ships only the row-level delta since the last push instead of the whole DB: it diffs the dump against a per-site baseline (~/.instawp/baselines/<id>/) and applies a minimal REPLACE/DELETE set (no DROP/CREATE). First run, a schema/DDL change, or --full do a normal full push and refresh the baseline. Requires a per-row dump (mysqldump --skip-extended-insert --order-by-primary; extended-insert dumps are rejected). Reuses the existing safety machinery — remote backup first, prefix/role-key remap, scoped URL search-replace, --verify. The full db push path is unchanged; incremental is purely additive.
• MVP scope: tables with a single-column primary key (WP core + most plugin tables); anything without one — or any DDL change — auto-falls-back to a full push. The diff engine (lib/db-delta.ts) and baseline store (lib/db-baseline.ts) are pure and unit-tested.
• Memory-bounded: the baseline is stored as a compact per-row hash manifest (PK → content hash), not the full dump, and the current dump is streamed line-by-line (gz-decompressed on the fly) — so a large DB diffs in a few hundred MB instead of loading both dumps into the heap (a naive 2× full-dump diff OOM'd at ~4 GB on a 166 MB DB).

Added — db push readiness/scoping + backup retention (large-DB feedback #16)

• db push --verify polls the site URL until it answers HTTP after the import (a large import can briefly return 000 right after import/flush); reported as verified in the summary.
• db push --sr-tables <table...> scopes --search-replace to specific (prefixed) tables instead of all tables — faster on big DBs whose bulk rows have no URLs. Default stays --all-tables.
• db backups list <site> and db backups prune <site> [--keep <n>] [--older-than <days>] [--force] manage the ~/db-backup-*.sql.gz files db push leaves behind (they previously accumulated with no way to view/clean them).
• Internal: extracted the HTTP-readiness helper to lib/http-ready.ts (now shared by sites create and db push --verify).

v0.0.1-beta.25

Improved — db push transport & progress (large-DB path)

From round-3 feedback (a 166 MB full-parity push — the transform logic held; transport/progress needed polish):

• db push compresses the dump in transit — scp now uses -C (SQL compresses ~5–10×), cutting upload time on large dumps. (#13)
• Non-interactive runs show progress — when stdout isn't a TTY (pipe / CI / background), each phase prints a one-line marker to stderr (Backing up… / Uploading… / Importing… / Rewriting URLs…) instead of going silent until the final summary. (#14)
• db push summary reports timing — adds an elapsed: 144s (1.2 MB/s) line. (#15)

v0.0.1-beta.24

Added — db push prefix-safety, URL remap, sync mirroring & webroot, exec shell

These address feedback from a real LocalWP → cloud "mirror overwrite" workflow.

• db push now detects a table-prefix mismatch (e.g. a wp_ dump pushed to an iwpa4c7_ site) instead of silently importing orphan tables the site never reads. It warns loudly and offers to rewrite; pass --rewrite-prefix to remap the dump's table identifiers non-interactively. Rewriting also remaps the prefix-bound role/capability keys ({prefix}capabilities, {prefix}user_level, {prefix}user_roles) after import so admin login survives.
• db push --search-replace <from> <to> runs a serialization-safe wp search-replace across all tables right after import — the near-universal next step after a cross-domain push.
• instawp wp/exec no longer leak the server login banner/MOTD into command stdout (or the --json payload). Output is now exactly the command's output, so --field, --format=count, and value capture are clean.
• exec --shell '<cmdline>' runs the arguments as one shell command line on the remote (enables pipes, ;, >, globs). The misleading -- ps aux | grep php help example (which actually piped locally) is fixed.
• sync push/pull --delete makes the remote/local a true mirror (removes extraneous files), guarded by a confirmation prompt (skip with --yes; preview with --dry-run). Additive remains the default. Not supported on Windows (SFTP transport).
• sync push/pull --remote-path <path> / --webroot transfer files outside wp-content/ (e.g. webroot-level ABSPATH/variations/).
• versions create now echoes the restore/list hint using the same site identifier you typed (no more short-name in, FQDN out).
• db push --search-replace now skips the guid column (WP best practice — post GUIDs are permanent identifiers, not links); same applied to local push --with-db.
• db push success summary prints readable rewrote_prefix / search_replaced lines (from -> to) instead of [object Object].
• exec --stdin streams local stdin to the remote command (uploads, restore pipes, tar … | exec --stdin 'tar xzf -') — closes the last gap from the feedback. It passes the command as an ssh argument so stdin is free to stream; the non-login remote shell it uses also means no MOTD on that path.

v0.0.1-beta.23

Added — update notifier + instawp upgrade

• The CLI now checks npm for a newer version at most once a day (cached in ~/.config/instawp/) and prints a one-line hint to stderr when an update is available — e.g. ⚡ Update available: 0.0.1-beta.22 → beta.23 · run: instawp upgrade. It's instant on cache hits and only does a short, timeout-bounded network call on the daily refresh.
• instawp upgrade (alias update) self-updates via npm i -g @instawp/cli@latest; --check reports without installing.
• Never pollutes output or surprises you: the hint is suppressed in --json, CI, and non-interactive shells (so harnesses never see it), and it never auto-installs by default. Opt into hands-off updates with INSTAWP_AUTO_UPGRADE=1; silence the hint with INSTAWP_NO_UPDATE_NOTIFIER=1.

v0.0.1-beta.22

Added — plugin install, sql, and HTTP-ready create

• instawp plugin install <site> <zip|dir> [--activate] — install a plugin from a local .zip (scp + wp plugin install --force) or directory (rsync into wp-content/plugins/, then activate). Removes the base64-over-exec dance.
• instawp sql <site> "<query>" — run a SQL query via WP-CLI; hits MySQL directly so it's immune to the object cache (handy for verifying state behind a cache).
• instawp create now waits until the site answers HTTP, not just until the provisioning task finishes — DNS/edge propagation lags task completion by 30–120s, so "Ready" now means actually reachable (no more hand-rolled curl-retry gates). --no-wait still returns immediately; --json includes http_ready.

Notes (from heavy CLI-driven test-harness use)

• exec/wp faithfully forward argv with per-arg shell-quoting (since beta.21) — quoted multi-word args and wp db query "…" work without --. For bulk file transfer use sync push (rsync), not exec: passing large data as a command argument hits the OS ARG_MAX limit (that's a kernel limit, not a CLI cap), which is what made base64-over-exec unreliable.