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

php playground/bin/deploy <id> --dry-run
php playground/bin/deploy <id>
# Optional maintainer rotate: see docs/DEPLOY.md

That copies code into LOCAL_INSTALL_ROOT (not site.db / uploads), writes the install registry / .htaccess, runs DROPBITS_SITE=<id> php bin/site migrate on the install, then boot. SSH/FTP publish follows from deploy.env.

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. Live semantics: Install on server — Live.

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   # host-local rotate only

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.