Go-live checklist
Goal: launch with nothing left to chance: every item below is either done or consciously deferred before production traffic arrives, each with its check and a link to the page that implements it.
What you’ll have when you’re done
Section titled “What you’ll have when you’re done”- Every launch-blocking concern (credentials, promotion, domain, CORS, caching, rollback, monitoring, rotation) checked or consciously deferred.
- A written answer to “how would we roll back” and “who would notice a failure” before either question is urgent.
Prerequisites
Section titled “Prerequisites”- The app deployed and working on a non-production environment (deploy quickstart)
- Production-grade configuration from the deploy guide (secret stores, ISR, autoscaling)
-
Production credentials are dedicated and minimal
Section titled “Production credentials are dedicated and minimal”A production API client of its own, with the minimum scope, never shared with Dev or Stage; each environment reads its own site URL and client pair. Cloud Platform environment variables are not encrypted, which is exactly why the client is dedicated and minimal. Check: the production environment’s
Variableslist has the three canonical names, and revoking the dev client breaks nothing in production. Details: auth guide, deploy guide step 1. -
Production deploys are gated; Dev and Stage are not
Section titled “Production deploys are gated; Dev and Stage are not”Branches auto-deploy to Dev and Stage; production changes only on a deliberate act (a tag deploy, or a manual pipeline job). If pushing to
maincan change production, the gate is missing. Check: push a trivial commit to the main branch and confirm production did not redeploy: no new task appears in the production environment’s task log, and its deployed commit/tag is unchanged. Mechanics: CI/CD guide, promotion; external CI equivalents in deploy from external CI/CD. -
The production domain is connected and serving
Section titled “The production domain is connected and serving”The default
*.acquia-sites.comURL is for verification, not launch. Register the custom domain on the production environment withacli api:environments:domain-create myapp.prod --hostname='www.example.com' --task-wait; the Cloud UI adds the same domain; see managing domains on docs.acquia.com. Point DNS at it (aCNAME, or anArecord for an apex domain);acli api:environments:dns-find myapp.prodreturns the exact values. Install or provision the SSL certificate (SSL on Cloud Platform). DNS changes can take up to 48 hours to propagate, so do this item early, not on launch morning. Check:curl -I https://www.example.comreturnsHTTP/2 200(or a redirect into your app) with no certificate warning;curlfails loudly withSSL certificate problemwhen the certificate is missing or wrong. -
CORS allows the production origin, and only the origins you mean
Section titled “CORS allows the production origin, and only the origins you mean”Client-side fetches from the production domain need it in the CMS’s
API > CORS configuration > Allowed origins; preview and Stage domains belong there too if their pages fetch client-side. Server-side rendering doesn’t need CORS at all, so an empty allowlist is correct for a fully server-fetched app. Check: the browser console on the live site is free of CORS errors. Details: deploy guide troubleshooting. -
Caching and revalidation behave under production settings
Section titled “Caching and revalidation behave under production settings”ISR memory cache at 0, revalidation wired (webhook or
acquia-force-revalidate), and a publish actually updates the live page within your chosen window. Check: publish a test entry, watch it appear on the live site, and record how long it took; that number is your staleness budget. Details: deploy guide step 2, webhooks guide. -
You know how you’d roll back, before you need to
Section titled “You know how you’d roll back, before you need to”A rollback is a procedure you rehearse, not a plan you improvise. Read the runbook for your deploy path and confirm its preconditions hold (previous artifact identifiable, backups current). Check: you can answer “what exactly would we do if this deploy is bad” in under a minute, with the operations runbooks open.
-
Monitoring is on and someone would notice a failure
Section titled “Monitoring is on and someone would notice a failure”Know where the environment’s logs live, have the log stream reachable during launch, and decide what external check tells you the site is down (the platform won’t page you). Check: an uptime check against the production URL alerts a human. Details: operations guide, monitoring.
-
Rotation is scheduled, not aspirational
Section titled “Rotation is scheduled, not aspirational”Every credential this setup created has an owner and a date: the production API client, CI credentials, webhook secrets. Check: the rotation inventory has no row you can’t answer for.
When something goes wrong
Section titled “When something goes wrong”Launch day traffic and the site is fine but publishes stop propagating
revalidation configuration diverged between Stage and production (different webhook URL, different secret). Re-run checklist item 5 against production specifically; Stage having worked proves nothing about production’s wiring.
The domain serves the default Acquia page instead of your app
DNS points at the environment but the domain isn’t registered on it (or vice versa). Both halves are required; re-check item 3.
Next steps
Section titled “Next steps”- Operations guide: the runbooks this checklist made you rehearse.
- CI/CD guide: promotion and governance mechanics behind items 2 and 8.
- Deploy guide: the production configuration this checklist verifies.
Was this page helpful?
What went wrong?
Still stuck? Contact Acquia Support (opens in a new tab)