Go-live checklist

The go-live checklist is the set of checks to finish before the first real customer deploys your software. Each item says why it matters and how to do it.

Projects and keysCopy Anchor Link

• Use a separate project for staging. Tests then never create setup links, releases, or deployments next to real customers. Create a second project in the dashboard and point staging CI at it with ALIEN_PROJECT or --project.

• Give each backend a scoped key. A leaked key can then do only what that service needs. Run alien api-keys create --for deployments, or use Settings → API Keys, and keep it on your backend, never in the browser.

  A project key can't update itself, re-enable a disabled key, or extend or remove a key's expiry (API_KEY_UPDATE_FORBIDDEN). A leaked key can't keep itself alive.

• Keep a separate key for removal. Deleting a deployment needs the project.admin role. Create it with alien api-keys create --for project-admin and use it only where removal runs.

• Pin the CLI version in CI. The CLI that runs alien release builds the artifacts, so an older CLI can ship artifacts without a fix you rely on. Install the version alien --version prints on your machine, and bump it together with your @alienplatform/* packages:

curl -fsSL https://alien.dev/install | sh -s -- --version <version>

Initial setupCopy Anchor Link

Initial setup is the one-time step the customer's admin runs in their account. If you built your own setup screen, run these checks through it instead of a setup link.

• Set it up yourself in a test account. You see exactly what the customer's admin sees, and you find permission and quota problems before they do. Create a setup link, the URL that opens the deployment portal (the setup page Alien hosts for the admin), and then:
  1. Open the link in a private window.
  2. Run initial setup in a test account on each platform you offer.
  3. Release an update.
  4. Remove the deployment.
• Offer only what you tested. Restrict the link's platforms and setup methods to the ones you ran end to end, set maxDeployments, and set an expiry. See Setup links.
• Brand the portal. The admin should see a branded portal on your domain, and your renamed setup CLI. See White-label.
• Decide the telemetry setting. The customer chooses Automatic, Approval required, or Off per deployment. With Off, Alien collects no logs from that deployment, so agree on how you'll debug it before it goes live. See Logs and metrics.
• Keep the link while its deployment exists. The customer's stack uses the link's token when it's deleted. Revoke the link only after the deployment is Deleted.

ReleasesCopy Anchor Link

• Release to a canary channel first. One bad release then reaches a few deployments, not all of them. A channel is a pointer to a release that deployments follow. Point your own or a few friendly deployments at canary and promote to production after they're healthy. See Staged rollout.
• Gate CI on the rollout. A published release isn't a deployed one. Run alien deployments wait <deployment> --for ready after each wave. It fails at once when the deployment settles on an older release, for example when the release waits for initial setup.
• Add health checks to Containers. Alien replaces replicas one at a time and waits for each replacement to be healthy. Without .healthCheck(), a replica counts as healthy as soon as it starts. See How replicas are replaced.
• Know your rollback. Write down the command before you need it: alien releases promote <previous-release> --channel production, or alien deployments pin <deployment> <release> for one deployment.

MonitoringCopy Anchor Link

• Get alerted on status. A failed update keeps the previous release serving, so nobody notices unless you watch status. Subscribe to deployment.failed and deployment.heartbeat_lost with webhooks, and pick a Slack Monitor Reports Channel for rollout reports (see Slack).
• Check your own health signal too. Running means the last update finished, not that your service answers. Call your service from where your product calls it, and treat a missing heartbeat as "not connected", not "down". See Deployment status.
• Forward logs to your tool. Your on-call already watches it. Open Settings → Integrations and choose Datadog, Coralogix, Axiom, or Custom OTLP. See Forward logs.
• Practice the first look. Run alien deployments get, alien deployments events, and alien logs against a staging deployment so the commands are familiar. See Debug a deployment.

Customer's adminCopy Anchor Link

• Name who contacts the admin. Some fixes need the customer: rerunning initial setup for a held release, raising a quota, approving an access request, deleting the setup stack. Decide who on your team reaches out, and keep an admin contact for each customer.
• Tell customers before a change that needs initial setup again. A release that adds, changes, or removes a frozen resource or needs new permissions waits until the admin reruns initial setup. Keep these rare, and announce them. See Held releases.
• Agree on approvals. On Kubernetes, the customer approves debug sessions and some Remote Operator operations. Agree on where approval requests go, for example a shared Slack channel. See Access requests.

RemovalCopy Anchor Link

• Test removal before launch. Deleting your own database row leaves the deployment running in the customer's account. On a test deployment:

  1. Run alien deployments delete <deployment>.
  2. As the admin, delete the setup stack.
  3. Confirm the status reaches Deleted.

  See Remove a deployment.

• Tell the customer what stays. Frozen resources, final volume snapshots, and anything initial setup didn't create stay in their account until they delete them.

NextCopy Anchor Link

• Debug a deployment
• Roll out releases
• Troubleshooting