Releases

A release is an immutable snapshot of your built app — compiled code, packaged images, and stack metadata. A channel selects which release a set of deployments should follow. Every project starts with a production channel, preserving the default behavior: alien release advances production and production deployments update automatically.

Build

alien build --platform aws

This compiles your stack for the specified platform. Alien reads alien.ts, runs the appropriate toolchains (TypeScript, Rust, etc.), and produces build outputs.

You can build for multiple platforms at once:

alien build --platforms aws,gcp

Build steps

1. Read the stack — Alien loads alien.ts and resolves all resources and their connections.
2. Run toolchains — each worker's code is compiled using the configured toolchain (TypeScript, Rust, etc.).
3. Package outputs — build outputs are packaged into container images or platform-specific runtime bundles.
4. Write metadata — the stack definition, resource graph, and image references are recorded.

Content-hash dedup

Every build produces a content hash of the output. If your code hasn't changed, the build reuses the previous output instantly — no recompilation needed. This makes repeated builds and releases fast.

Supported platforms

| kubernetes | Kubernetes Pods and Services |

Release

alien release

This builds your code, pushes images to the registry, and creates a release on the manager. Alien auto-discovers which platforms to release from your manager's artifact registry configuration.

Use --platforms to override auto-discovery:

alien release --platforms aws
alien release --platforms aws,gcp

Test a release without updating production

Create a long-lived channel such as staging, configure the test deployment to follow it, then release directly to that channel:

alien release --channel staging

Production stays on its current release. A later normal alien release advances only production, so it cannot overwrite staging. When the tested release is ready, promote the exact immutable release instead of rebuilding it:

alien releases promote rel_… --channel production

Promotion uses the same artifacts that were tested. Channels are pointers, not copies or draft releases; the releases page labels which channels currently point at each release. A pinned deployment keeps running its pinned release even when its channel advances. Changing its channel changes where it resumes after it is unpinned.

What happens during release

1. Discover platforms — Alien queries the manager for configured platforms (or uses --platforms if specified).
2. Build — Alien rebuilds for every platform to ensure the release reflects your latest code. Content-hash dedup makes this instant when nothing changed.
3. Push — Images are pushed to the configured registry (embedded or external). If the same images were already pushed in a prior release, the push is skipped automatically.
4. Record — Alien records the release metadata (stack definition, image references, platform) on the manager.
5. Update — Deployments following the selected channel detect the new release and update automatically. Pinned deployments do not move.

Using --prebuilt

For CI/CD pipelines where build and push happen in separate steps, use --prebuilt to skip both:

# In your CI build step:
alien build --platforms aws,gcp
# Push images to your registry externally...

# In your CI release step:
alien release --prebuilt

This requires that stack.json already contains remote image URIs (not local paths).

Multi-Platform Releases

Each platform gets its own build output and deployment metadata, but the alien.ts manifest is the same. Workers, containers, and supporting infrastructure are packaged in the format Alien needs to update each deployment.

Build and release multiple platforms in one command:

alien build --platforms aws,gcp,azure
alien release --platforms aws,gcp,azure

Configure multiple artifact registries in your alien-manager.toml and alien release handles them all in a single command.

How Updates Propagate

Once a release is pushed, Alien's deployment loop moves each eligible deployment toward the recorded target:

• Push model: the manager calls cloud APIs to update workers and services directly. Updates are immediate.
• Pull model: the Operator polls for target releases (~30 seconds) and applies updates locally.
• Gated or disconnected deployments: deployments that require approval, are pinned, or use airgapped sync do not update until their deployment policy allows it.

The dashboard shows current version, target version, rollout state, last heartbeat, and failures. Each release has a detail page showing rollout status across every deployment: which are updated, updating, failed, still pending, pinned to another release, or superseded by a newer one. It includes per-deployment rollout durations, deployment group filters, an activity timeline of release events, and the stack contents packaged in the release. The page updates live while a rollout is in flight, so pushing a release and watching it land is one flow. Healthy deployments converge automatically; blocked deployments stay visible instead of becoming hidden version drift.

To roll back, promote an earlier release back to the channel — alien releases promote <release-id> --channel production — or pin an individual deployment to a known-good release from the CLI or the release page. Promotion reuses the exact immutable artifacts; nothing is rebuilt. A failed rollout can also roll forward: fix the problem and release again, and deployments converge through normal desired-state reconciliation.