Docs

Deployment Models

Push or pull — two ways to manage your application in customer environments.

Alien supports two deployment models. Both use the same stack definition, the same release pipeline, and give you the same capabilities — automatic updates, telemetry, remote commands. The difference is how your application gets managed.

Push

Alien manages resources directly inside the customer's cloud. It impersonates a service identity in the customer's account and calls cloud APIs to push updates, read logs, and dispatch commands.

╔═ Alien ═══════════════╗                ╔═ Customer's Cloud ═══════════════════╗
║                       ║  impersonate   ║                                      ║░
║  Push updates  ───────╬───────────────▶║  ┌─ Isolated Area ───────────────┐   ║░
║  Read logs     ◀──────╬────────────────║  │  Function · Storage · Queue   │   ║░
║  Run commands  ───────╬───────────────▶║  └───────────────────────────────┘   ║░
║                       ║                ║                                      ║░
╚═══════════════════════╝                ╚══════════════════════════════════════╝░
                                          ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

Updates are immediate. Best for AWS, GCP, and Azure.

Choose push if: you want the manager to handle everything. The customer grants scoped cross-account access, and Alien pushes updates directly. Simplest model — no agent to install or monitor.

How push works

  1. During initial setup, the customer's admin runs a one-time command that creates the isolated area and the service identity.
  2. Alien impersonates that identity whenever it needs to manage the deployment — update function code, read logs, run health checks.
  3. When you run alien release, Alien 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 functions, 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 Alien over HTTPS, polls for new releases, and deploys them locally using its own credentials. Alien never touches the customer's cloud directly.

╔═ Customer's Environment ═══════════════════════════════╗
║                                                        ║░
║  ┌─ Agent ──────────────────────────────────────────┐  ║░
║  │                                                  │  ║░
║  │  Polls for updates ──────────────────────────────── outbound HTTPS
║  │  Deploys locally                                 │  ║░
║  │  Reports health ─────────────────────────────────── outbound HTTPS
║  │                                                  │  ║░
║  └──────────────────────────────────────────────────┘  ║░
║                                                        ║░
║  No inbound ports. No firewall changes.                ║░
╚════════════════════════════════════════════════════════╝░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

No cross-account access. No inbound networking. Best for on-prem, air-gapped, or when the customer's security team won't allow any external identity.

Choose pull if: your customer's security team won't allow any external identity in their cloud. The agent handles everything locally.

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. alien-deploy down removes all managed resources.

Decision Framework

PushPull
Who manages deploymentAlien, directlyAgent, locally
Access modelImpersonationLocal credentials
NetworkAlien calls cloud APIsAgent makes outbound HTTPS only
Update speedImmediate~30 seconds (poll interval)
Best forAWS, GCP, AzureOn-prem, air-gapped

Use push when the customer is comfortable granting scoped access. Use pull when they aren't, or when the environment is on-prem.

Both models support the same features: releases, remote commands, telemetry, health checks.

On this page