Skip to content
Developer Docs

Deploy a change

Last updated View as MarkdownAgent index

Release through GitHub Actions. Terraform applies selected infrastructure before verified Worker packages are deployed.

Prerequisites

Complete Validate a change. Use GitHub access that can review the repository and authorize its workflow. The deployment environment must have its required organization-secret access.

  1. Open a pull request and inspect its Terraform Plan comment. Confirm the selected roots, apps to verify, and apps to deploy. Review changes to bindings, routes, migration files, and resource ownership.

  2. Resolve review conversations. Once the intended infrastructure and application deployments are approved, add terraform-apply. This label covers application deployment as well as Terraform. Verification-only changes need no deployment label.

  3. Wait for Verify, Plan, and Apply authorized on the latest commit. Adding the label reruns planning. A pushed commit needs fresh checks. Merge only when those gates pass.

  4. In the repository's Actions runs, open apply.yml for the merged commit. Confirm selected Terraform roots finish successfully before the build jobs. Each selected app is verified and packaged in this run.

  5. Follow the deployment stages. Dependencies precede consumers, and the gateway is last. Read each deployment summary and preserved receipts. Confirm every Worker in the app's package has a deployment receipt.

  6. Perform the appropriate health checks. Record the commit, workflow run, affected apps, and observed result in your release or incident record. A successful upload alone does not prove a private service or user journey is healthy.

To locate a run from the repository checkout:

gh run list --workflow apply.yml --branch main --limit 10
gh run view <RUN_ID>

Failed or partial releases

A failed prerequisite blocks later stages. Earlier Workers and migrations may already be active; the workflow does not undo completed changes. Production runs queue, so also inspect pending runs before choosing a recovery action. Use Recover a release to decide between retrying and deploying a correction.

There is no normal workstation apply or deploy path. Do not bypass the workflow with dashboard edits or a local Wrangler deployment.

Developer Docs