A merged pull request is not permission to deploy. A release task names the target environment, exact revision, release owner, required migration, verification, and recovery path.

Current deployable artefacts

The Packbase web repository builds a Vite application and Cloudflare Worker:

bun run build
bun run deploy

deploy invokes Wrangler and requires the appropriate Cloudflare identity. The Worker serves dist, uses a PACKBASE_API_URL binding for /context, and runs before HTML assets. The API URL saved in a browser’s Advanced sign-in setting is separate and cannot verify the deployed Worker binding.

The Packbase server repository builds a multi-stage Node 24 image from the repository root:

docker build --file apps/server/Dockerfile --tag packbase-server:local-check .

The image generates Prisma, verifies the native uWebSockets.js addon, exposes port 8000, and starts TypeScript source through tsx. It does not run database migrations and currently does not install FFmpeg, so a successful image build does not prove the video-upload path is ready.

The current repositories do not identify one canonical production host, pre-deploy command, backup system, log service, or rollback command. Provider-specific comments and scripts are clues, not a runbook.

Release record

Before an authorised deploy, record:

Environment:
Release owner:
Revision or image digest:
Included pull requests:
User-visible change:
Configuration change:
Database step:
Compatibility order:
Preflight checks:
Post-deploy checks:
Stop condition:
Rollback or fix-forward action:
Communication location:

If any required field cannot be determined from the task, provider, or current runtime, stop before changing shared state. Do not guess a platform from a Prisma hostname or an old script.

Preflight

  1. Start from a clean, reviewed revision with required CI passing or explicitly waived under the hotfix rule.
  2. Confirm the production target and currently deployed revision.
  3. Review environment and binding changes without printing secret values.
  4. Review migration commands separately; the server’s migrate path accepts data loss and does not run Prisma SQL migration deployment. The release record must name the complete environment-specific sequence.
  5. Confirm old server, SDK, and web versions can coexist for the rollout order.
  6. Confirm the platform termination grace can drain current in-memory work.
  7. Name the behaviour and data invariant to verify after deploy.
  8. Decide the point at which rollback becomes riskier than fixing forward.

Do not deploy from a dirty checkout, a local branch whose commit is not recorded, or an environment containing unreviewed configuration changes.

Verification

Verify the deployed revision, product behaviour, authentication boundary, affected read and write, background completion when relevant, and error logs. For an HTML or metadata change, check both the Worker request path and browser API path. For a database change, verify the intended constraint or data state, not merely server liveness.

Record the result on the release task. If a check cannot run, say so while the release is still active.

Recovery

Code rollback does not automatically reverse a schema or user-data change. Prefer additive releases that let old and new code coexist. When fixing forward, keep the mitigation small and leave a follow-up task for the complete repair.

Do not run the repository’s self-host update script on an unfamiliar deployment as a generic rollback or update tool; it can stash local changes and assumes a particular filesystem layout.