Frozen & Live Resources

Every resource you add to a stack is either 🧊 frozen or 🔁 live. This is a tradeoff between security and control — and it exists because you're deploying to environments you don't control.

Three layers of permissions

Alien derives three separate layers of permissions from your stack definition:

Provisioning — Creates all resources during initial setup. The customer's admin runs alien-deploy up once with their own credentials. Alien never holds these permissions.
Management — What Alien uses day-to-day. Frozen resources get health checks only. Live resources get update permissions. This page covers this layer.
Application runtime — What deployed code can access at runtime. Controlled through permission profiles, completely separate from management permissions.

The frozen/live choice controls layer 2. It determines what Alien itself can do — not what your application code can access.

The Problem

When you deploy to a customer's AWS account, you need permissions. But there's a tension:

Creating infrastructure (S3 buckets, DynamoDB tables, IAM roles) requires broad permissions — you're creating things that don't exist yet.
Managing your application (pushing new code, rolling config changes) requires less permissions — but you still need remote access.

If you use the same permissions for both, you're over-privileged during normal operations. The customer's security team won't like that.

The Tradeoff

export default new alien.Stack("my-app")
  .add(data, "frozen")     // Alien can only monitor
  .add(cache, "frozen")    // Alien can only monitor
  .add(api, "live")        // Alien can manage remotely
  .build()

🧊 Frozen — Alien can only monitor it. Created once during initial setup, then Alien has no permissions to modify or delete it. The customer's security team knows this resource won't change.
🔁 Live — Alien can manage it from your cloud. Push code updates, roll config changes, redeploy — without the customer's involvement. But this requires management permissions.

In both cases, auto-derived management permissions avoid sensitive customer payload access. Even for live resources, Alien can update worker code and resource configuration without implicitly reading objects, KV rows, queue messages, or secret values. Sensitive management access is controlled separately through explicit management grants, either user-authored or added by preflights for concrete resources such as deployment secrets or command dispatch.

How to Choose

The question is: "Do I need to manage this remotely, or is monitoring enough?"

Any resource type can be either — it depends on the use case, not the type:

Use case	Frozen or live?	Why
Storage bucket that persists between deploys	🧊 Frozen	Stable infrastructure — monitoring is enough
Container running your API server	🔁 Live	You need to push image updates remotely
Worker running your latest code	🔁 Live	You need to push code updates remotely
Long-running container that should never restart	🧊 Frozen	Stability matters — you don't want remote restarts
Queue for async job processing	🧊 Frozen	The queue itself doesn't change, only messages do
VPC or networking config	🧊 Frozen	Set up once, never touched again

Two Phases

The frozen/live split creates a natural two-phase deployment:

Phase 1: Initial Setup (one-time)

The customer's admin runs alien-deploy up, which:

Creates all resources — both frozen and live
Creates the service identity Alien will use for ongoing management
Deploys the initial version of your code

This runs once. It uses the admin's own cloud credentials with elevated permissions.

Phase 2: Ongoing Management

After setup:

Alien uses the limited service identity created during setup
Manages live resources remotely — pushes code, rolls config, redeploys
Monitors frozen resources — health checks only
Never needs create/delete permissions

The customer's admin is not involved. Alien handles it automatically.

If a frozen resource's configuration changes between releases, the build fails with an error — enforced by preflight checks. You can override this with --allow-frozen-changes if needed.

Auto-Derived Permissions

You don't configure any of this manually. Alien automatically derives the management permissions it needs based on the frozen/live choice:

	Auto-Derived Permissions
🧊 Frozen	`heartbeat` only (read-only health checks)
🔁 Live	`management` (read + update) + `heartbeat`

The provision permission set (create, update, delete) is never auto-derived. It's only used during initial setup with the admin's own credentials. If you need Alien to create or delete resources after setup, you must explicitly opt in via management: { extend: ... }.

These are management permissions only — what Alien itself can do. What your deployed code can access at runtime is a separate layer, controlled through permission profiles.

Frozen & Live Resources

On this page