Updates and development

Updates and local development#

For removal, use the uninstall guide and its copyable agent prompt. Keep mail by default. Review resource ownership and move incoming mail before removing its Worker.

To move an existing installation to a newer version, follow the upgrade guide. The short form: check out the target release, then rerun pnpm run deploy with the same account, owner, URL and BOXOX_PLAN.

Use reviewed release tags instead of main. The current release is unsigned. When a signed tag is available, verify its signature against a trusted maintainer identity. Inspect migrations and dependency changes before deploying. Back up the installation and run the workspace checks. Keep OWNER_EMAIL and the installation account set when running pnpm run deploy again. If Workers Builds watches a branch, review what will merge into that branch before it deploys. The CLI deployment path applies D1 migrations. Do not assume another build command does so.

For local development, copy the example secrets file at the repository root:

cp .dev.vars.example .dev.vars
pnpm install --frozen-lockfile
pnpm db:migrate
pnpm --filter @boxox/mail build
pnpm --filter @boxox/web build
pnpm --filter @boxox/worker dev

Run pnpm --filter @boxox/web dev in a second terminal. Fill .dev.vars with development credentials as needed. Never commit it.

Local protected routes still require valid Access configuration and identity. A plain unauthenticated local request can return 503 until you configure Access. Do not disable authentication to make it pass.

Run local checks with pnpm -r --if-present typecheck, pnpm --filter @boxox/worker exec vitest run, and pnpm --filter @boxox/web build. Worker tests use local D1/R2 and fake model bindings. Remote bindings, including Browser Run, can access paid account services when you invoke them.