Frozen & Live Resources

frozen and live answer one question: who is allowed to change this resource after setup?

export default new alien.Stack("my-app")
  .add(data, "frozen")
  .add(api, "live")
  .build()

• A frozen resource is owned by customer setup. An ordinary rollout cannot create, change, replace, or delete it.
• A live resource is owned by Alien's Deployment Manager. It can create, update, replace, or remove the resource as it rolls out a release.

This setting does not control what your application can read or write. Runtime access is configured separately with permission profiles.

Why the distinction exists

Customer setup and day-to-day deployment management need different cloud permissions.

During setup, the customer runs the generated CloudFormation, Terraform, Helm, or CLI flow with their own credentials. That flow creates setup-owned infrastructure and the limited identity used by the Deployment Manager.

After setup, the Deployment Manager uses that limited identity to provision and update live resources. It does not receive general authority to change frozen resources.

customer setup                         ongoing rollouts
──────────────                         ────────────────
creates frozen resources              create and update live resources
creates management identity           leave frozen resources unchanged

If a later release adds or changes a frozen resource, Alien stops the rollout and asks you to run setup again. Setup authority is required because the existing management identity does not own that change.

Which resources can use each lifecycle?

Workloads are live because Alien needs to deploy and replace their code:

• Worker
• Container
• Daemon

Storage, Queue, KV, Vault, Postgres, and AI can be frozen or live. Use frozen when changes should go back through customer setup. Use live when Alien must be able to create and reconcile the resource during normal rollouts.

Some foundational resources, including Network, Key, Artifact Registry, and Compute Cluster, are setup-owned and therefore frozen. Alien validates the lifecycle supported by each resource type during the build.

Permissions are separate

There are three distinct permission paths:

1. Setup permissions belong to the customer running the setup flow.
2. Management permissions let the Deployment Manager reconcile live resources.
3. Runtime permissions let your Worker, Container, or Daemon use linked resources.

For live resources, Alien derives the provisioning permissions needed for ongoing reconciliation. Frozen resources do not receive those permissions. Optional features such as health checks, telemetry, Commands, and Remote Bindings may add their own narrowly scoped permissions; they do not turn a frozen resource into a live one.

Observed resources are different again. Alien can discover and display them, but it did not create them and does not reconcile them. See Operate existing environments.