The release readiness checklist for one app: an automated staging deploy, a promotion gate, and the check after

A push to main that goes straight to production reaches customers unchecked. In at least 17 of the 21 third-party apps I audited in June and July 2026, there was no deploy gate. A release readiness checklist for one app has three parts: an automated staging deploy, an explicit promotion step, and a check after promotion.

What a release readiness checklist is, and what a promotion gate does

A release readiness checklist for one app covers three parts: every merge to main deploys itself to staging, production changes only through an explicit promotion step, and the app is checked right after promotion. The promotion gate is the middle part, the point where a change waits until a person or a passing check lets it through.

The 21 apps behind that opening count are a selected set of third-party codebases I audited, not a random sample, so the count is not a rate for AI-built apps in general. The gate is one of the controls in the release path that DevOps for startups lays out for a small team.

In the Production Hardening Sprint, this gate is deliverable 7.4, which is to automate staging deployment and require an explicit promotion step for production.

Each part leaves evidence you can point to after the release:

The release readiness criteria are the checks that must pass before anyone takes the promotion step: CI is green, the migration has been reviewed, and the rollback is known. A release to production checklist is only as strong as the step that enforces it, because without a gate nothing stops a merge from skipping every line. Kept to these three rows, a deployment readiness checklist fits one app with no release manager: each row either left its evidence or the release is not ready. To turn the table into a production release checklist template, copy it and add a date column for each release; there is nothing to download.

Three neighbors cover the rest. The release process checklist you run on each individual deploy is the production deployment checklist. A software release checklist for the whole app, covering security, backups and monitoring, is the production readiness checklist. Launch day has its own go-live checklist.

What goes wrong without it

Three failures show up when the gate is missing, and each has a first check you can run today:

The first row is the gap in the opening count. In the same audits, the Deployment & Operations pillar averages 37.0 out of 100 across the 21 third-party apps. Those 21 apps were chosen for my June and July 2026 audits, not drawn at random, so neither number is a measure of AI-built apps at large.

The second row is the quiet one. Take a founder whose app ships only when the freelancer who built it runs the deploy from their own machine. An urgent fix is ready on a day that freelancer cannot be reached, nobody else knows the steps, and so the fix waits. When only one person knows how to deploy, a release path that lives in their routine stops when they do; a pipeline and a gate make shipping anyone’s job. If the step itself is unclear, start with what deploy means in software.

The third row defeats the point of having staging at all. A rehearsal that writes to the live database is a release with extra steps, and the separation it needs, along with the minimum pipeline for a one-person team, is covered in the article on one database and no staging. In software development, go live is the first promotion with real users behind it, which is why I would put the gate in place before that day rather than after.

How to automate deploys to staging and gate production on common hosts

Each section below gives the click path or workflow, the one setting that turns the second step into a gate instead of a second deploy, and what a manual approval step before a production deploy looks like on that host. The host behavior comes from each host’s own documentation, read on 2026-09-28; nothing here was run for this page.

Vercel: staged production builds and promote to production

Vercel’s docs say that by default, “when you merge to or make commits to your production branch (often main), Vercel will automatically promote the changes to Production.” To stage a production build instead, you must turn off the auto-assignment of domains.

1. In the project, open Settings, go to Environments and click Production.
2. In the Branch Tracking section, disable the Auto-assign Custom Production Domains toggle.
3. Merge to main as usual. Each merge now leaves a production deployment marked Staged, which serves no production traffic.
4. To release it, open the ellipsis menu next to the deployment, select Promote and confirm. Vercel promotes it without a rebuild and marks it Current.

A preview deployment can also go to production through the Deployments list, the ellipsis menu and Promote to Production. Vercel’s guide to promoting deployments describes that path as a complete rebuild, with the variables switching to those linked to the production environment.

My reading of the staged option: a staged build is a production deployment, so it runs with production’s variables and, through them, production’s database. A rehearsal that must not touch customer data belongs on a preview deployment with its own database; on the staged build it becomes the shared-database failure from the table above.

The other gate on Vercel is automatic. With Deployment Checks, “Vercel will hold each production deployment until all required checks pass before assigning it to your custom production domains”, and selecting Force Promote from the deployment details page bypasses them. A plan condition for Deployment Checks is not stated in Vercel’s docs page for the feature. The CI checks that feed it are the subject of CI/CD best practices.

GitHub Actions: a staging job and a gated production job

The pattern is two jobs in one workflow: a staging job on every push to main, and a production job that names an environment whose protection rule requires a reviewer. GitHub’s docs say that when a job references an environment, “the job won’t start until all of the environment’s protection rules pass”; a reviewer releases it with Approve and deploy.

That rule depends on the plan. In the words of GitHub’s guide to deployment environments: “For access to environments, environment secrets, and deployment branches in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, other deployment protection rules, such as a wait timer or required reviewers, are only available for public repositories.”

So on a private repository below GitHub Enterprise, the gate is a production workflow that runs only on the workflow_dispatch event, started with the Run workflow button in the Actions tab. GitHub’s docs on running a workflow manually say the workflow must be in the default branch and that “Write access to the repository is required”. That is a manual promotion step with no second approver, as I read it.

On a plan and repository where required reviewers are available, the set-up takes five steps:

1. In the repository, click Settings, then Environments in the left sidebar.
2. Click New environment, name it production and click Configure environment.
3. Select Required reviewers, enter the person who approves releases, and click Save protection rules. Only one listed reviewer has to approve a job.
4. Administrators can bypass the protection rules by default. If the gate must hold for them too, deselect Allow administrators to bypass configured protection rules and save again.
5. Commit the workflow below to main.

The gate holds only when this workflow is the only path to production. A host that also deploys the production branch on every push, as Vercel does by default and as Render’s On Commit setting does for a new service, needs that auto-deploy turned off first; otherwise the gate stops nothing.

name: release
on:
  push:
    branches:
      - main
jobs:
  staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-length commit SHA>
      - run: <your staging deploy command>
  production:
    needs: staging
    runs-on: ubuntu-latest
    environment: production   # required reviewer set on this environment
    steps:
      - uses: actions/checkout@<full-length commit SHA>
      - run: <your production deploy command>
# Private repo below GitHub Enterprise: move the production job to its own workflow with on: workflow_dispatch

If the app runs on Supabase, the same gate for database changes, two workflows with a required reviewer on production, is set out in a Supabase staging-then-production release. The order that keeps a schema change ahead of the code that needs it is a separate question: how to run database migrations on deploy.

Railway and Render: environments, preview environments and a manual promotion

Railway creates every project with a production environment, and a staging environment can sit beside it as a persistent environment; Railway’s environments docs give the example of one “configured to auto-deploy from a staging branch”. PR environments are temporary: they are created when a pull request opens and deleted once it is merged or closed. Railway’s words for the two-environment setup are separate staging and production environments “that auto-deploy when changes are made to different branches”, so the promotion step there is the merge into the production branch, by my reading. To hold production itself, Railway’s autodeploy docs offer Wait for CI, which keeps a new deployment waiting until every GitHub Actions check suite on the commit has finished, or Disable, after which Deploy Latest Commit in the Command Palette ships the newest commit when you choose.

Render’s preview environments can build a copy of production for each pull request, but “Preview environments require a Pro workspace plan or higher”, as Render’s preview environments docs put it. Production moves by the service’s Auto-Deploy setting: On Commit, which is the default for a new service; After CI Checks Pass; or Off, for when you “only want to trigger deploys manually” from the Manual Deploy menu on the Deploys page. On a lower Render plan, my reading is that the staging copy becomes a second service that tracks a staging branch.

A named approver for a production deploy is not stated in Railway’s or Render’s docs. What per-pull-request copies are for, and where they stop, is a separate topic: what preview deployments are.

CI/CD release management for a small team: who decides a release is ready

For a two-person team, release management is one person and one note. The person is whoever takes the promotion step: the approver on a protected environment, whoever starts the production run, or whoever clicks Promote. The note is my working rule: a few lines per release naming the change, the migration, the rollback and who promoted.

CI/CD release management then splits in two. The pipeline carries the change to staging, the gate carries it to production, and a named person owns the second step. Release planning as a product discipline, with roadmaps and KPIs, is a separate job and stays out of this page.

A risky release rollout checklist adds three things to the gate. Put the risky feature behind a flag so it can ship switched off, with one of the open source feature flags options if you have none yet. Rehearse the way back before you need it, which is what a rollback plan is for. Then find the host’s own rollback control ahead of time: how to roll back a deployment shows it on Vercel and Netlify.

Blue-green, canary and rolling: which promotion strategy a small app needs

A deployment strategy is how users move to a new copy of an app: blue-green switches all of them at once, canary sends a small share first and widens it only if the new copy behaves. One app on a host that builds each deploy as a new copy needs the host’s own swap and a flag on risky changes.

The “who needs it” column below is my reading for a single-service app; the “what it does” column follows each source’s description.

In the blue green deployment vs canary choice, a small app runs into cost first: the Google SRE workbook notes that a blue/green setup “uses twice as many resources” as a more traditional deployment. How canary deployment works, in the same workbook’s terms: the part of the service that receives the change is “the canary”, the rest is “the control”, and comparing the two decides whether the rollout goes on. A canary deployment strategy therefore needs three pieces: a way to send the change to a subset, a way to judge it good or bad, and a release process that acts on the verdict.

On Vercel, Rolling Releases is the managed version of a canary. “Rolling Releases are available on Enterprise and Pro plans”, “Pro teams can use Rolling Releases for one project”, and Vercel “directs a configurable fraction of your visitors, for example, 5%, to the new deployment”.

What immutable infrastructure implies in a cloud deployment context is that the running copy is never edited in place: in Netlify’s words, “Instead of pushing individual files to Netlify, you always create a new deploy.” An immutable deploy leaves the old copy intact, which is why a rollback can be quick: Vercel’s Instant Rollback works by assigning your domains to an existing deployment rather than doing a complete rebuild.

Those four rows are the types of deployment strategies a small app meets; Kubernetes strategies are out of scope here. For one app, the zero downtime deployment strategies come down to the host’s swap plus a schema change that old and new code can both run against, in the order the migrations guide above sets out.

Sources for the table: Martin Fowler’s description of blue-green deployment, the Google SRE workbook chapter on canarying releases, AWS’s description of rolling deployments and Netlify’s explanation of atomic deploys.

How to verify it: test the production promotion step

The promotion gate is verified in five steps: a change lands on staging with nobody deploying it, production keeps serving the old version until the step is taken, the step is taken and the app is checked, the promoter is recorded, and the change is rolled back once to prove the path.

Run the steps on a quiet day with a change nobody will mind seeing. The third step is the production verification test proper: the checks you run on the live app in the minutes after promotion.

1. 01 Merge a small visible change, such as a new footer string, to main. Evidence: the string shows on the staging URL (on Vercel, the staged build's own deployment URL), and the deployment list shows a build started by the merge with nobody running a deploy.
2. 02 Confirm production has not changed. Evidence: the production URL still lacks the string; on GitHub the production job waits for a reviewer, or in the workflow_dispatch form no production run exists until someone starts one; on Vercel, with auto-assignment off, the build shows as Staged.
3. 03 Promote, then run the production verification test. Evidence: the health endpoint answers, one core flow works end to end, and the error tracker shows no new errors for about five minutes after promotion, my working rule.
4. 04 Record who promoted and when. Evidence: a dated line in the release log, plus the deployment in the environment's deployment history on GitHub or the manual run in the Actions tab.
5. 05 Roll the change back once to prove the path. Evidence: the production URL no longer shows the string.

The production verification testing template is these five rows with a date column: copy them into the release log and fill in a row each time.

In the sprint, deliverable 7.4 is verified the same way: “Deploy a change to staging, then demonstrate the production promotion gate.”

Where the sprint does this

Deliverable 7.4 is recorded in the production readiness report, deliverable 13.1, which accounts for all 123 IDs, keeps failures visible until they are resolved and explains genuine non-applicable items. Your app’s current framework and hosting setup are the starting point for the work. Hosting, paid tools and API usage remain in your accounts, and we explain any required third-party costs before enabling them. Every deliverable and its check is listed in the published scope.

Common questions about promotion gates and releases

What are the four stages of the release management process?

For one app, I map the four stages to build and test, deploy to staging, promote, and verify. The pipeline owns the first two, a person or a passing check owns the promotion, and the verification is the check on the live app right after the change reaches customers. That mapping is mine, sized for a team without a release manager.

Is blue green deployment risky?

Blue-green deployment gives the code a rapid way back: if anything goes wrong, switching the router back to the old environment is the rollback. The risk sits in the data: Martin Fowler notes that databases “can often be a challenge with this technique, particularly when you need to change the schema to support a new version of the software”, and his fix is to change the schema so it supports both the new and old version first, deploy that, check it works so there is a rollback point, then deploy the new application.

What should be included in a release plan?

For one app, a release plan needs five lines: the change, the migration, the rollback, who promotes, and the check after promotion. That list is my working rule. A product team’s plan adds dates and owners across several groups, but for a single service those lines decide whether a release can be undone.

What is the purpose of go live?

Go live is the release that first puts the app in front of real users, the moment a mistake stops being private. As I read it, its purpose is to move the app from rehearsal to real traffic with a way back that has already been tried once.

Can you give me an example of verification?

A production verification test after a release is a good example. Right after promotion, call the health endpoint, run one core flow end to end, such as signing up and creating a record, and watch the error tracker for new errors for about five minutes, which is my working rule. Write down what each check showed, so the release log proves the change worked.