Manage organization and application controls through their canonical owners. GitHub organization access, Cloudflare account access, and application roles are separate permissions.
| Change | Source or operator boundary |
|---|---|
| GitHub organization policy, membership, repositories, rulesets, environments | org/github/ and its existing modules |
| Cloudflare account, zone, storage, Access policy, ordinary DNS | org/cloudflare/ |
| Worker code, bindings, routes, Custom Domains, deployment observability | org/apps/<APP>/ and central release adapters |
| App registration and exceptional dependencies | org/catalog.json |
| Organization-secret values | Authorized operator in GitHub organization secrets; never Terraform values |
| Selected-repository secret allowlists | Existing Terraform declarations where supported |
| Product roles and tenant access | Application authorization contracts, not GitHub organization membership |
-
Identify the intended control and its owner. Read root
AGENTS.md, the app's instructions, and Terraform and Wrangler ownership. For a new GitHub repository, follow Manage repositories. -
Make configuration changes in the owning source. Keep each remote object in one Terraform state. Preserve
movedblocks for address refactors and import records for adopted objects. Do not create a resource in the dashboard and then give a second tool ownership of it. -
For credential changes, identify every consuming job and service first. Have an authorized operator update the organization secret with the intended repository scope. Check Credentials and the explicit environment mappings in
deploy-app.yml. Keep values out of pull requests, Terraform, shell arguments, and logs. -
Review the resulting plan and complete the deployment workflow. A secret-value update alone is not a source change and does not select an app for deployment. Use the app's established secret-installation path in a trusted release; do not assume updating GitHub immediately rotates a Worker secret. There is no generic secret-rotation workflow.
-
Verify the intended access boundary, affected application health, and subsequent drift result. Record the change and its verification without copying credentials into the record.
The scheduled workflow checks the two Terraform roots independently. Inspect
issues titled Terraform drift detected: github or
Terraform drift detected: cloudflare and their linked plan runs. Decide
whether to restore the declared configuration or review a source change that
adopts the intended remote setting.
A failed plan is not evidence of a clean root. Drift detection covers Terraform-owned resources; it is not a complete audit of deployed Worker code, bindings, or user journeys. Do not edit state or delete locks to silence drift.
There is no one-command app deletion or rename procedure. Inventory runtime consumers, bundled consumers, public routes, storage, queued work, credentials, and retained data before proposing retirement. App IDs also influence Worker names, Terraform declarations, and GitHub environments.
Move consumers away and verify that traffic and background work have stopped.
Plan data retention and recovery separately. Review any removal of
prevent_destroy explicitly with the resource owner. Deleting the app folder
or catalog entry alone is not a safe teardown; the catalog and Terraform
checks deliberately prevent incomplete ownership changes.