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:

1. 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.
2. Management — What Alien uses day-to-day. Frozen resources get health checks only. Live resources get update permissions. This page covers this layer.
3. 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, management permissions never include data access. Even for live resources, Alien can call lambda:UpdateFunctionCode but never s3:GetObject. Alien manages the resource without accessing the customer's data. Data access is controlled separately through permission profiles.

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:

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:

1. Creates all resources — both frozen and live
2. Creates the service identity Alien will use for ongoing management
3. 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:

1. Alien uses the limited service identity created during setup
2. Manages live resources remotely — pushes code, rolls config, redeploys
3. Monitors frozen resources — health checks only
4. 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:

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.