The production deployment checklist for one app: what to check before, during and after every release

One line of a production deployment checklist carries a date: the backup, because one taken last week does not cover the migration you are about to run. In at least 17 of the 21 third-party apps I audited in June and July 2026, there was no deploy gate. The 15 items below run before, during and after every release.

The production deployment checklist

A production deployment checklist for one app is 15 items in three groups: seven before the release (CI green, a dated backup, the migration order, the variables, the rollback, a preview, a green staging deploy), three during (the promotion, the migration, the health endpoint) and five after (a core flow, the error tracker, uptime, a flag, the record).

The 21 apps behind that count are third-party apps I audited in June and July 2026. They are a selected set, not a random sample, so the number describes those audits and is not a rate for all apps. The release path this list sits inside, from the first commit to the running app, is covered in DevOps for startups.

Before the release, the build, the data and the way back:

During the release, the three steps that change production:

After the release, the proof that it worked:

The table gives each item the test that proves it and the evidence I would keep. Both columns are my working rule, not a vendor’s requirement.

Read as a general checklist for software deployment, this list works on any host; what changes is who runs the three steps in the middle. On a VPS those three are yours to script. On a managed host some of them are host settings: Vercel promotes a commit to the production branch automatically by default, and Railway can wait for a new deployment’s health endpoint before switching traffic to it. The example stack further down still runs its migration from your own CLI or CI, which is my reading of Supabase’s migration guide.

A deployment pipeline audit checklist, where you judge how releases happen rather than one release, uses these same items: if the pipeline cannot produce the evidence column, that gap is the finding. A fresh CI/CD checklist is the same list for a pipeline set up this week, and it can fill the evidence column from the first release. Repeatable deployment best practices are this list in the same order every time, with the record kept. For a SaaS on a VPS, the perfect pre-release checklist is still these seven before items; what the server adds comes after the release, in the scheduled checks further down.

This list runs at every release. The list you work through once, before an app takes real users, is the production readiness checklist; an ultimate deployment checklist for a product launch is a launch-day document, and that is the go live checklist. For apps on Vercel, Vercel’s production checklist groups its launch items under operational excellence, security, reliability, performance and cost optimization, and this list does not repeat it.

How to fill it in

The software deployment plan template here is the seven before items with a date column added, copied into whatever you keep release notes in; there is nothing to download. For a software deployment plan example, the filled release further down uses the same rows. Where a step depends on the host, what it does comes from that host’s documentation, read in September 2026.

Before: the build, the backup, the migration, the variables and the rollback

The build item has one command at its center. npm ci needs an existing package-lock.json, and if the dependencies in the lockfile do not match those in package.json, it exits with an error instead of updating the lockfile. The lockfile only helps if the build reads it: in a voice-AI SDK I audited, the server Dockerfile installed whatever npm resolved on build day, and the committed lockfile never reached the image (that finding belongs to a wider question: what an npm malware package can do).

For the migration, my working rule is expand, then deploy, then remove: add the new column or table first, ship the code that uses it, and drop what the old code needed in a later release. On Supabase, supabase db push compares your local migrations folder with the table of applied migrations and runs only the ones not yet applied, in order, as Supabase’s migration guide describes. Whether your code is ready for them is the review in the third item.

The rollback point on Vercel is a previous production deployment. Vercel’s Instant Rollback is a way to quickly revert to one, and on the Hobby plan you can roll back to the immediately previous deployment, while Pro and Enterprise teams can pick any deployment that was previously aliased to a production domain. The rollback reassigns your domains to an existing build instead of rebuilding, so environment variables you changed since then are not applied. After a rollback, Vercel also turns off auto-assignment of production domains, so new pushes to your production branch won’t replace the rolled-back deployment until you promote one again.

The mistake to catch here: a migration that drops a column the old code still reads. If the release fails after that migration, rolling the code back puts the old build in front of a schema it no longer matches.

During: the three steps that decide the release

The promotion, the migration and the health endpoint decide whether the release goes out cleanly. The common mistake is watching the build log and calling the release done when it finishes. A finished build says the code compiled; the health endpoint of the new deployment says it started and can answer.

Railway’s health checks build this step into the deploy. You enter your health endpoint in the service settings, and Railway will wait for it to serve a 2xx status code before switching traffic to the new deployment; if it does not do so within the timeout, the deploy will be marked as failed. Railway does not monitor that endpoint after the deployment has gone live, which is why uptime is its own item after the release.

Azure App Service deployment best practices put these three steps in a slot swap: you deploy to a staging slot, validate the change there, and swap the slot into production. Deployment slots are available only when the app runs in the Standard, Premium or Isolated tier of an App Service plan, as Azure App Service deployment slots sets out.

On a VPS, you script the same three steps. Best practices for a microservices deployment come to this list run once for each service that changes. Running it the same way at every release covers most of what best practices for DevOps deployment ask for.

After: what to keep as evidence

The release record is the evidence the list was used. Write the row the same day, with the error-tracker watch in it, because which commit, which backup and who promoted are the first things you need when the next release fails. Post it where the people who answer your users will see it, so they know what changed before the first question arrives.

The security half of an after-deploy check, the part a deploy security checklist template would cover, depends on where the app runs. Which platform controls Vercel runs for you and which stay yours is in is Vercel safe; the Replit version of these checks is in is Replit production ready. The pipeline’s own security, meaning who can push, promote and read secrets, is CI/CD security best practices. If the host itself is still an open question, start with the deployment target comparison, and if the word “deploy” still feels vague, what deploy means in software covers the basics.

A filled example

This is an illustration with stated assumptions, not a client’s release. One app: Next.js on Vercel, a Supabase Postgres database, one additive migration in this release, and one new feature behind a flag. Each row says what the item means for this stack and what to keep; it gives no times or results.

Supabase backs up Pro, Team and Enterprise Plan projects daily, and recommends that free tier plan projects regularly export their data with the Supabase CLI db dump command and keep off-site backups. On the Free plan, the dated backup in the second row is that export, taken right before the migration.

Given Vercel’s default promotion, the promotion row exists here only once the Auto-assign Custom Production Domains toggle is turned off for the project, which stages each production build until someone promotes it. The release readiness checklist covers that setting.

After the release: server maintenance checklist for the platform and the app

After a release, five checks need a schedule rather than a deploy: dependency updates, certificate and domain expiry, log retention, a backup restore test, and the dashboards. On a managed host that is the whole server maintenance checklist; on a VPS, add the operating system, disk and memory.

The how-often column is my working rule, rough guidance rather than a standard. On a managed host the platform runs the operating system and disk half, so the VPS rows apply only when the server is yours.

For the VPS rows, a server health check checklist is the last two rows of that table, run on the schedule beside them. What maintenance covers overall, including dated jobs such as certificates and sign-in credentials, is in what app maintenance includes; this table is only the checks that follow a release. The alerting half, who hears about a failed check and how fast, belongs with hardening SaaS applications resilience.

How to verify the result

The evidence for a production deployment is the release record: one row per release with the commit, the backup timestamp, the migration id, who promoted, the health result, the error-tracker watch and the rollback point. A complete row for every release shows the list is in use.

Each field comes from somewhere you can point to. The commit and who promoted come from the host’s deployment list, the backup timestamp from the backup or export itself, the migration id from the migration file name, and the health result from the response of the health endpoint. The rollback point is the deployment id you named before the release.

In the Production Hardening Sprint, three deployment deliverables each have their own verify step. Staging deployment and production promotion, deliverable 7.4, is verified this way: deploy a change to staging, then demonstrate the production promotion gate. Migration-aware deployment, deliverable 7.5, is verified this way: deploy a representative schema change and verify sequencing and failure handling. And tested rollback, deliverable 7.6, is verified this way: roll back a test release and verify application behavior and retained data.

Where the sprint does this

Those checks test setup work the sprint does. We automate staging deployment and require an explicit promotion step for production, integrate database migrations into the deployment process with ordering and compatibility checks, document and rehearse release rollback, including how database changes are handled safely, and provide browser-accessible preview deployments for pull requests with isolated test configuration. Each lands in the production readiness report, which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. The full list is in the published scope.

Common questions about release checklists

What is a deployment checklist?

A deployment checklist is the fixed set of checks run every time code goes to production: preparation before it, the steps that change production during it, and confirmation after it, each with something written down to show it happened. It differs from a launch list, which runs once.

What are 5 items that regularly scheduled maintenance will check?

For a web app, my working rule puts five on a schedule: pending dependency updates, certificate and domain renewal dates, how long logs are kept, a test restore from backup, and the uptime and error dashboards. On a VPS, operating system patches, free disk space and memory join them.

How to perform a health check on a server?

Request the app’s health endpoint, for example with curl -i https://your-app.example/health, and confirm it returns a success status from the version you just deployed. Then let the host repeat that check on every deploy: on Railway, you enter the endpoint in the service settings and Railway waits for a 2xx status code before switching traffic. What the endpoint itself should test is a separate design question.

How to reduce deployment time?

My reading: keep every item and shorten the build instead. The checks are where a bad release gets caught, so cutting them saves time now and costs more of it in the next outage. Measure where the time goes first; if it is the build, making builds faster is its own topic, and the promotion, migration and health check can run from a script so nobody waits on them.

Can you give me an example of a software deployment?

One release of a Next.js app on Vercel with a Supabase Postgres database: CI installs with npm ci, a dated export is taken, one additive migration runs, the staged deployment is promoted, and the new feature goes live behind a flag. Every row of that release, with the evidence for each, is in the filled example above.