Deployment Models

Every Alien deployment runs on one of three models. They share the same stack definition, release pipeline, and capabilities — automatic updates, telemetry, remote commands. What changes is who runs the deployment loop and how it reaches the customer's environment.

Use push when you can — it's the simplest model, with no agent to install or operate in the customer's environment. Reach for pull when the target is Kubernetes or the customer's security team won't allow any external identity. Airgapped is for environments that have no network egress at all.

Push

The Deployment Manager impersonates a service identity inside the customer's cloud and calls cloud APIs directly to push updates, read logs, and dispatch commands. The customer's environment runs no Alien process of its own.

╔═ Your Cloud ══════════════════════╗                ╔═ Customer's Cloud ══════════════════╗
║                                   ║                ║                                     ║░
║  ┌── Alien Deployment Manager ──┐ ║                ║  Their databases, services, infra   ║░
║  │                              │ ║                ║                                     ║░
║  │                              │ ║                ║  ┌─ Isolated Area ──────────────┐   ║░
║  │                              │ ║  cloud APIs    ║  │                              │   ║░
║  │  Push updates       ─────────┼─╬────────────────╬─▶│  ┏━━━━━━━━━━┓                │   ║░
║  │  Read logs          ◀────────┼─╬────────────────╬──│  ┃  Worker  ┃                │   ║░
║  │  Run commands       ─────────┼─╬────────────────╬─▶│  ┗━━━━━━━━━━┛                │   ║░
║  │                              │ ║                ║  │  ┏━━━━━━━━━━┓                │   ║░
║  │                              │ ║                ║  │  ┃ Storage  ┃                │   ║░
║  └──────────────────────────────┘ ║                ║  │  ┗━━━━━━━━━━┛                │   ║░
║                                   ║                ║  │                              │   ║░
╚═══════════════════════════════════╝                ║  └──────────────────────────────┘   ║░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                 ║                                     ║░
                                                     ╚═════════════════════════════════════╝░
                                                      ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

Choose push if: the customer's security team will grant scoped cross-account access. The model is simpler — no agent to install or monitor, no software to keep alive in the customer's environment, and updates are immediate.

How push works

1. During initial setup, the customer's admin runs whichever deployment method they picked from the portal — CLI, Terraform, or CloudFormation. It creates the isolated area and the service identity.
2. The Deployment Manager impersonates that identity whenever it needs to manage the deployment — update worker code, read logs, run health checks.
3. When you run alien release, the Deployment Manager picks up every deployment that needs updating, impersonates the identity for each one, and swaps the live resources. Updates are immediate.

What gets created

AWS: Cross-account IAM role with trust policy, Lambda workers, S3 buckets, DynamoDB tables, SQS queues. Every permission is restricted to resources matching the deployment prefix.

GCP: Service account with impersonation grant, Cloud Run services, Cloud Storage buckets, Firestore databases, Pub/Sub topics. Custom roles with project-level scope.

Azure: User-Assigned Managed Identity with federated credentials (OIDC), Container Apps, Blob Storage, Table Storage, Service Bus. Custom role scoped to the resource group.

Push security

• The service identity is scoped to the deployment — it can only manage the resources in the isolated area.
• Frozen resources can only be monitored after setup. Only live resources can be managed remotely.
• The customer can review permissions before approving and revoke access at any time.

Pull

A lightweight agent runs inside the customer's environment. It connects outbound to the Deployment Manager over HTTPS, polls for new releases, and applies them locally using its own credentials. The Deployment Manager never touches the customer's environment directly.

╔═ Your Cloud ══════════════════════╗                ╔═ Customer's Cloud ══════════════════╗
║                                   ║                ║                                     ║░
║  ┌── Alien Deployment Manager ──┐ ║                ║  Their databases, services, infra   ║░
║  │                              │ ║                ║                                     ║░
║  │                              │ ║    HTTPS       ║  ┌─ Isolated Area ──────────────┐   ║░
║  │                              │ ║  (outbound)    ║  │                              │   ║░
║  │  Fetch releases  ◀───────────┼─╬────────────────╬──│─── ┏━━━━━━━━━┓               │   ║░
║  │  Send telemetry  ◀───────────┼─╬────────────────╬──│─── ┃  Agent  ┃               │   ║░
║  │  Fetch commands  ◀───────────┼─╬────────────────╬──│─── ┗━━━━━━━━━┛               │   ║░
║  │                              │ ║                ║  │    ┏━━━━━━━━━━┓              │   ║░
║  │                              │ ║                ║  │    ┃  Worker  ┃              │   ║░
║  └──────────────────────────────┘ ║                ║  │    ┗━━━━━━━━━━┛              │   ║░
║                                   ║                ║  │    ┏━━━━━━━━━━┓              │   ║░
╚═══════════════════════════════════╝                ║  │    ┃ Storage  ┃              │   ║░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                 ║  │    ┗━━━━━━━━━━┛              │   ║░
                                                     ║  └──────────────────────────────┘   ║░
  No inbound ports. No external identity.            ║                                     ║░
                                                     ╚═════════════════════════════════════╝░
                                                      ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

Choose pull if: the target is Kubernetes, the customer is on-prem, or their security team won't allow any external identity in their cloud. The agent handles everything locally; the Deployment Manager only sees what the agent reports back.

Kubernetes

Kubernetes is the primary pull target. The customer's admin installs the project-branded Helm chart from the deployment portal:

helm install acme oci://pkg.alien.dev/acme/my-app/helm \
  --namespace acme --create-namespace \
  --values values.yaml

The portal generates values.yaml with the sync token and an encryption key already filled in. The agent runs as a single-replica Deployment in the target namespace, managing Pods, Services, ConfigMaps, and other resources.

Infrastructure resources (storage, databases, queues) aren't provisioned by Alien on Kubernetes — they're provided externally by the cluster operator and configured via Helm values. See Infrastructure on Kubernetes for the mapping.

Pull security

• No inbound networking. The agent only makes outbound HTTPS requests.
• Local credentials. The agent uses whatever credentials exist in the environment. Nothing leaves the perimeter.
• Encrypted state. Local agent state is encrypted with the key provided during setup.
• Tear down at any time. Uninstalling the Helm release (or running the CLI's destroy) removes all managed resources.

Airgapped (preview)

For environments with no network egress at all — classified networks, fully disconnected sites, regulatory islands — the agent can run without a sync URL. There's no connection to the Deployment Manager: releases and commands are delivered out-of-band to the agent's local API, and telemetry is buffered for later export.

What this looks like in practice: the customer's admin installs the agent (typically via Helm, same chart) but with sync.url unset. Your release artifacts are handed over through whatever channel the customer's policy allows — usually a physical transfer or one-way diode. A local CLI on the customer's network then pushes them to the agent.

Airgapped is in preview — the agent runtime is complete, but the developer-facing tooling for producing release bundles and the customer-facing portal flow are still landing. Talk to us if you have an airgapped deployment coming up.

Mixing models

A single project can have customers on all three models simultaneously. The choice is per-deployment, made when the customer's admin opens the deployment portal. From your side, every customer shows up the same way in the dashboard — same release stream, same telemetry view, same remote commands. The model just changes how that work reaches them.