Upgrade a deployed site

Upgrading means: put newer kernel/pack/theme code on the install, then run migrations there. Content stays on the install under content-owned deploy.

Happy path

# From the operator checkout (host-local deploy tooling)
./deploy <id> --dry-run
./deploy <id>            # or ./deploy <id> --remote

That rsyncs code (not site.db / uploads), applies install registry / .htaccess, runs DROPBITS_SITE=<id> php bin/site migrate on the install, then boot, and appends deploy-log.jsonl.

Manual migrate (if you shipped code another way)

On the install:

cd /path/to/install   # tree that contains bin/site + sites/<id>/
DROPBITS_SITE=<id> php bin/site migrate
DROPBITS_SITE=<id> php bin/site boot

Until migrate succeeds, guests may see 503 upgrade_required — fail-safe, not the happy path.

Packs after upgrade

New pack files appear as available. Enable explicitly (CLI or Admin → Site). Migrate does not auto-enable capabilities.

Skip migrate (not for production)

./deploy <id> --skip-migrate

Only for controlled experiments. Production always migrates after code ship.

Rollback

Restore the pre-deploy tarball of LOCAL_INSTALL_ROOT, or redeploy a known-good checkout (code only) and migrate if needed. See Content-owned deploy and docs/DEPLOY.md § Rollback.