Skip to content
Developer docs

Deployment

Move a verified build into production with explicit configuration, durable state, health gates, and a known rollback target.

Prepare the release

  1. Pin the source revision and package lockfile used to build the release.
  2. Run typecheck, server tests, frontend checks, browser tests, and the site build.
  3. Capture the capability manifest hash, evaluation result, approval, and migration set as release artifacts.
  4. Build and scan the deployable images or packages in CI.

Production shape

Terminate TLS at the edge, keep the API private to trusted callers where possible, and mount persistent storage for SQLite and the content-addressed store. Inject secrets through the deployment system. Do not bake provider keys into images or frontend bundles.

PROMPTSHEON_NODE_ENV=production
PROMPTSHEON_AUTH=true
PROMPTSHEON_CORS_ORIGIN=https://console.example.com
PROMPTSHEON_DB_PATH=/var/lib/promptsheon/promptsheon.db
PROMPTSHEON_CAS_PATH=/var/lib/promptsheon/cas

Admission and rollout

  1. Apply migrations before admitting traffic and verify /api/ready.
  2. Deploy with a graceful shutdown window for schedulers, SSE clients, and the database.
  3. Route a small canary slice and compare error rate, latency, cost, and evaluation signals.
  4. Promote only when the evidence matches the release gate.
  5. Keep the previous verified content hash and deployable revision available.

Rollback contract

Rollback should be a deliberate promotion of the last known-good artifact, not an ad-hoc edit on a running host. Preserve the audit entry, reason, operator, and observed impact. Verify readiness and the capability hash after the rollback.

Continue to production operations →