Frozen and live resources
Every resource in a stack is frozen or live, and you choose which. A frozen resource is created once, at initial setup, the one-time step the customer's admin runs; a live resource is created and updated by Alien on every release, without the admin.
export default new alien.Stack("acme-docs")
.add(documents, "frozen") // the admin creates it at initial setup
.add(policies, "frozen", { remoteAccess: true })
.add(index, "live") // Alien updates it on every release
.add(processor, "live")
.build()Initial setup and ongoing management
A deployment has two phases, and each one runs with different credentials:
Architecture diagram. Left: Customer's admin containing Setup package; Your side containing Alien manager. Right: customer-1's cloud account containing acme-docs deployment containing Frozen containing identity; documents; policies; Live containing index; processor.
- Initial setup. The customer's admin runs CloudFormation, Terraform, Helm, or the setup CLI with their own credentials, once. It creates the frozen resources and a scoped management identity.
- Ongoing management. On every release, Alien uses the management identity to create, update, and delete live resources and roll out code. No admin is involved.
Your choice of frozen or live decides what the management identity is allowed to do:
| Frozen | Live | |
|---|---|---|
| Created by | The customer's admin, at initial setup | Alien, during a release |
| Changed by | Initial setup, run again by the admin | Alien, during a release |
| Alien's management permissions | None to create, change, or delete it. Health checks only, plus narrow operations for a few types | <type>/provision, scoped to this stack's resources |
| What the customer reviews | The resource itself, in the setup template | The permission to manage resources of that type |
A frozen resource asks for less trust: Alien can't delete or reconfigure it. A live resource needs less coordination: you change it with a release, without asking anyone.
Choose by use case
Decide from what the resource holds and how often you expect to change it. In the running example:
documentsis frozen. It holds the customer's files. Their security team reviews the bucket once and wants proof that you can't delete it or open it up.indexis live. It holds data the processor can rebuild. You expect to reconfigure it as the product evolves, without waiting for the customer.policiesis frozen. Your backend writes to it through remote bindings. Its definition rarely changes.processoris live. Compute is always live, because every release ships new code.
The same type can go either way. A cache you rebuild freely is a good live KV. A KV that holds customer state their security review called out is a good frozen one.
Common misconceptions
"Storage is frozen, functions are live." You choose per resource for Storage, KV, Queue, Vault, Postgres, and AI. Only compute is fixed (always live), along with a few types that only initial setup creates, such as Key and ComputeCluster (always frozen).
A Sandbox can be live only on AWS, and on AWS one built from source or from a private base image must be live. The build fails if you pick a lifecycle a type doesn't support.
"Live resources are recreated on every deploy." They aren't. Alien tracks each resource's state and updates it in place, so a live bucket keeps its objects across releases. Alien deletes a live resource only when you remove it from the stack, or when a deployer turns off an optional resource.
"Frozen means the data survives." Data survives in both. Frozen decides who may change the resource and when: only initial setup, run by the customer's admin.
"Frozen limits what my code can do." It doesn't. Your Worker reads and writes a frozen bucket like any other. Runtime access comes from permission profiles, which are separate from the management identity.
"Enabling commands or remote access makes a resource live." It doesn't. Health checks, telemetry, commands, and remote bindings add their own narrow permissions, and the resource keeps its lifecycle.
Changes that need initial setup again
Frozen resources and permission profiles belong to initial setup, so changing them needs the admin's credentials again. A release needs initial setup again when it:
- adds, changes, or removes a frozen resource
- changes any permission profile, including removing a grant or a whole profile
- widens the management identity's permissions with
management: { extend }or{ override }
A ComputeCluster's machine counts, autoscaling bounds, and machine type within the same CPU architecture are the exception: they change without running initial setup again.
What happens to such a release:
- The update stops before it changes anything. The deployment reports
DEPLOYMENT_SETUP_REQUIREDand keeps running the previous release. - The customer's admin reruns initial setup the same way they ran it the first time: update the CloudFormation stack, apply the new Terraform, or rerun the setup command.
- The deployment continues to the new release. See Follow a deployment.
Some gaps show up only during the rollout, such as a grant the management identity lacks on a resource it's creating. The deployment then reports DEPLOYMENT_RESOURCE_SETUP_REQUIRED and waits instead of retrying.
Rerunning the setup command continues it on its own. After a CloudFormation stack update or a Terraform apply, retry the deployment with alien deployments retry.
Changes to live resources and code roll out with a normal release. Batch frozen changes, and tell customers ahead of time.
Next
- How Alien works: initial setup and ongoing management end to end.
- Inputs and secrets: values that differ per deployment.
- Permissions: what your code can access at runtime.
Bring an existing app
Move a product that ships as a Helm chart, docker-compose file, or container images onto Alien, so it deploys and updates in every customer environment from one alien.ts.
Inputs and secrets
Declare the values each deployment needs, say whether you or the customer's admin provides them, and keep customer secrets out of Alien.