dropbits Documentation

Content-owned deploy

Routine deploy = ship code to the install, then migrate schema on the install. User content (site.db + uploads) is never uploaded by default.

Normative companion: docs/DEPLOY.md.

Default (CONTENT_OWNED=1)

ShippedNot shipped
Kernel src/, packs/, assets/, bin/, public/, migrationssites/*/data/site.db (+ WAL)
Site themes from checkout (mtime-guarded)sites/*/data/uploads/
secrets, sessions, backups, deploy-log.jsonl

Script default is already CONTENT_OWNED=1 when unset.

Before you ship

  1. Pull remote editorial content when staging for a remote deploy (./deploy <id> --remote pulls site.db + uploads into the local install first).
  2. Operator tarball of LOCAL_INSTALL_ROOT → backups/ (recommended every production / remote deploy).
  3. Prefer --dry-run once.
./deploy <id> --dry-run
./deploy <id>
./deploy <id> --remote   # sync remote content, then code-only ship + restore DB/uploads

Never default to --with-content

Escape hatch only for rare bootstrap / intentional DB push:

./deploy <id> --with-content
# or in deploy.env: CONTENT_OWNED=0

Do not make that the happy path. Re-running import-dev, create_demo, or a full DB restore as part of routine deploy will overwrite live editorial work.

Remote rotate + restore

Remote deploy moves the live tree aside, rsyncs code (still excluding DB/uploads when content-owned), then always restores site.db + uploads + secrets from the swap before purge. If restore fails, the swap is left in place — do not delete .dropbits-deploy-swap/ until the DB is back (Troubleshooting).

Themes

With content-owned deploy, only themes are compared for newer-path prompts (keep / pull / overwrite / abort). DB and uploads are not treated as “upload if newer.”

See also