# 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

- 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

- The app deployed and working on a non-production [environment](/start-here/glossary/#environment) ([deploy quickstart](/source-cms/deploy/quickstart/))
- Production-grade configuration from the [deploy guide](/source-cms/deploy/guide/) (secret stores, ISR, autoscaling)

## Steps

<Steps>

1. ### Production credentials are dedicated and minimal

   A production [API client](/start-here/glossary/#api-client) of its own, with the minimum [scope](/start-here/glossary/#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 `Variables` list has the three canonical names, and revoking the dev client breaks nothing in production. Details: [auth guide](/source-cms/authenticate/guide/), [deploy guide step 1](/source-cms/deploy/guide/).

2. ### 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 `main` can 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](/cloud-platform/ci-cd/guide/#promote-through-environments); external CI equivalents in [deploy from external CI/CD](/source-cms/deploy/external-ci/).

3. ### The production domain is connected and serving

   The default `*.acquia-sites.com` URL is for verification, not launch. Register the custom domain on the production environment with `acli api:environments:domain-create myapp.prod --hostname='www.example.com' --task-wait`; the Cloud UI adds the same domain; see [managing domains](https://docs.acquia.com/acquia-cloud-platform/managing-domains) on docs.acquia.com. Point DNS at it (a `CNAME`, or an `A` record for an apex domain); `acli api:environments:dns-find myapp.prod` returns the exact values. Install or provision the SSL certificate ([SSL on Cloud Platform](https://docs.acquia.com/acquia-cloud-platform/ssl-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.com` returns `HTTP/2 200` (or a redirect into your app) with no certificate warning; `curl` fails loudly with `SSL certificate problem` when the certificate is missing or wrong.

4. ### 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](/source-cms/deploy/guide/#when-something-goes-wrong).

5. ### 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](/source-cms/deploy/guide/), [webhooks guide](/source-cms/content-api/webhooks/).

6. ### 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](/source-cms/deploy/operations/#roll-back-a-deploy) open.

7. ### 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](/source-cms/deploy/operations/#monitor-the-running-app).

8. ### 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](/source-cms/deploy/operations/#credential-rotation-inventory) has no row you can't answer for.

</Steps>

## 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

- [Operations guide](/source-cms/deploy/operations/): the runbooks this checklist made you rehearse.
- [CI/CD guide](/cloud-platform/ci-cd/guide/): promotion and governance mechanics behind items 2 and 8.
- [Deploy guide](/source-cms/deploy/guide/): the production configuration this checklist verifies.