Skip to main content
Status: target. Nothing is deployed. There is no generated Encore app yet (services are plain TypeScript members under services/<name>; Encore is the generated target in .stackra/encore/, 0124), and how it reaches a runtime is an open question (DP2), no hosting for apps/console or apps/docs, no deploy workflow and no release records. This page is the procedure that must hold from the first deploy. When a target is chosen, replace its row in the table with a section on its real commands.

​
The rules

  1. Agents prepare and check; the owner runs every deploy. Every deploy command is behind an approval prompt. Answer no and hand it to the owner, with the commit SHA, the gate result and the list of secret names the release needs.
  2. Staging first, then production from the same commit, after pnpm verify is green on that exact SHA (CI). Never deploy a commit whose gate you did not see pass.
  3. Secrets are named by the agent and set by a human, in each environment, before the deploy. A missing secret fails provisioning, for example Encore’s secret key(s) not defined. See Secrets.
  4. A rollback is a redeploy of an older recorded release, not a build.
  5. Production needs the owner’s explicit approval each time. Two-person approval is deferred until a second maintainer joins; until then CODEOWNERS and branch protection are the control.
  6. Never skip the gate (--no-verify, “skip tests”) to save time. The break-glass path in CI gates locally instead.

​
Targets

​
A deploy

1

Prepare (agent)

Confirm pnpm verify is green on the SHA. List every new secret name and its purpose. List every migration and say whether it is expand-only. Write the smoke-test checks. Hand all of it to the owner.
2

Set secrets (human)

The owner sets each named secret in the target environment. The agent never sets or reads a value.
3

Deploy to staging (owner)

The owner deploys the full SHA to staging. A deploy is by commit hash, never by branch name.
4

Smoke test

The service’s health endpoint answers 200 and reports the new SHA; the console and docs load with no console errors, in both directions (LTR and RTL) and both themes where the app supports them; sign-in works against the target API.
5

Promote to production (owner)

The owner deploys the same SHA to production, approves explicitly and repeats the smoke test.
6

Record it

Record the release: environment, full SHA, who, gate result, smoke result, time. The record is what a rollback redeploys.

​
Rollback

  • Choose the target from the release records (the last release that succeeded before the current one), never from memory.
  • Redeploy that release’s commit to the same environment through the same approval as a deploy. Dry-run first where the tooling allows it.
  • The bad release keeps its record. Write a new record for the rollback that names the one it repairs, so the bad release counts as a failure and the rollback as its repair.
  • A rollback never goes further back than one good release. If there is none, roll forward.
  • Data is not rolled back. Migrations, secrets, bindings and store listings are separate. The redeployed code runs against the current schema, so migrations are expand-then-contract: the previous release must always run against the expanded schema. A release whose migration contracted the schema is rolled forward, never back.
  • A hand-run provider rollback is break-glass. Record it within the hour with the reason.

​
Checks that back this page

See also Release, Secrets and CI.