# Understand the release model

StormTrust intentionally keeps organization infrastructure and applications in one repository. That gives related changes one review boundary. It does not make the organization a single deployment, state file, or application version.

## Source intent and remote state

The catalog describes app intent and relationships. Terraform's GitHub and Cloudflare roots own separate remote state objects in R2\. Wrangler controls application releases against Terraform-owned identities and durable resources. The [ownership reference](/stormtrust/engineering/cloudflare/ownership/) defines the setting-level boundary.

A catalog entry, Terraform state record, release manifest, and healthy service answer different questions. An entry can exist before an app's first deploy. A Worker can deploy successfully while its downstream service is unhealthy. Operational evidence must preserve those distinctions.

## Shared code and runtime services

Shared modules are bundled into consumers. A change therefore requires new consumer bundles. Service bindings call another deployed Worker; changing the service does not necessarily require new consumer code. The selector verifies runtime consumers while avoiding an automatic consumer redeployment.

Both relationships need compatible contracts. Stage ordering helps with creation and sequencing, but does not make an API-breaking change safe. Keep old consumers working while introducing new provider behavior, then migrate consumers before removing the old contract.

## Verification, release, and deployment

Pull-request checks validate the proposed revision. After merge, the main workflow applies selected Terraform changes, verifies apps, and packages compiled code. Deployment uses those packages and resolves production settings on a separate copy. This keeps compilation out of the deployment job.

That process is not a transaction across the organization. A migration or Worker deployed earlier remains changed if a later stage fails. Application state also survives code deployments. Recovery must account for the actual partial result, not only the workflow's final red status.

## Versions have different purposes

A commit identifies source. A lockfile fixes build inputs. A compatibility date selects runtime behavior. A Cloudflare version identifies uploaded Worker code and configuration, while a deployment activates version traffic. An immutable asset URL is a public consumption contract.

Record the appropriate identifiers from the [operations reference](/stormtrust/engineering/operations/reference/). Do not infer that every app runs the same revision because they share a repo. Do not overwrite an immutable asset URL to imitate a code rollback.

## Operational limits

The shared toolchain minimizes new-app setup, but framework builds still need adapters where their output differs. Runtime probes are app-specific and incomplete. Production has no shared preview-promotion system, automatic rollback, or transaction spanning Workers and their data.

Those capabilities require implementation and validation before the docs can present them as supported procedures. The existing recovery path is a reviewed correction, with separate state and data recovery where necessary.