Alien
Infrastructure for software outside your cloud.
Some of your product has to run where you don't control the infrastructure: a customer's AWS, Google Cloud or Azure account, their Kubernetes cluster, or a site with no internet access at all. Alien runs that piece there (the data plane) and keeps it connected to your control plane: releases roll out on their own, logs come back, and your backend can call into it, all over connections the environment opens outbound.
The manager is the center of it. Run it yourself from this repository, or let alien.dev run it for you. The same alien CLI works with both.
Quickstart
Install the CLI:
curl -fsSL https://alien.dev/install | sh
With alien.dev
alien login
alien init && cd alien
alien dev # run the app locally, no cloud account needed
alien release # build and publish a release
alien onboard acme --platforms kubernetes
The Quickstart walks through it.
With your own manager
Start a manager. It prints an admin API key the first time:
docker run -d --name alien-manager -p 8080:8080 -v alien-data:/data \
-e BASE_URL=http://localhost:8080 \
ghcr.io/alienplatform/alien-manager
docker logs alien-manager
Point the CLI at it, release your app, and onboard a customer:
alien login --manager http://localhost:8080 --token ax_admin_...
alien release
alien onboard acme --platforms kubernetes --secret-input accessToken=...
alien onboard prints a token for the customer and the commands their Kubernetes admin runs once. Their cluster pulls the chart and images from your manager with that token, which stays out of shell history:
read -rs ALIEN_TOKEN # paste acme's token, then Enter
printf '%s' "$ALIEN_TOKEN" | helm registry login manager.example.com --username acme --password-stdin
printf 'management:\n token: %s\n' "$ALIEN_TOKEN" | \
helm install files oci://manager.example.com/charts/files \
--namespace files --create-namespace \
--set management.name=acme \
--values values.yaml \
--values -
For real customers, run the manager where their clusters can reach it over HTTPS: with the Helm chart on Kubernetes, the Terraform module on Amazon ECS, or docker run on any machine. See Self-hosting.
How it works
Your cloud Customer environment
┌──────────────────────────┐ ┌──────────────────────────────┐
│ alien CLI your │ │ Operator │
│ │ backend │ outbound │ ├─ deploys each release │
│ ▼ │ │ HTTPS │ ├─ ships logs and traces │
│ Manager ◀─────┘ ◀──────┼─────────────┼── ├─ relays tunnel requests │
│ │ │ │ └─ updates itself │
│ ▼ │ │ │
│ OpenTelemetry backend │ │ Your containers, storage │
└──────────────────────────┘ └──────────────────────────────┘
Alien deploys in two ways:
- Push. The customer grants a narrowly scoped role in their cloud account, and the manager deploys through the cloud's APIs.
- Pull. The customer runs the Operator: a Helm chart on Kubernetes, or a container in their cloud. It connects outbound to the manager, fetches releases and deploys them locally. Nothing listens for inbound connections.
Both give you the same things: releases, heartbeats, logs and commands. See How Alien works.
Define your app
import * as alien from "@alienplatform/core"
// The customer's S3-compatible bucket, supplied at install time.
const bucket = new alien.Storage("bucket").build()
const api = new alien.Container("api")
.code({ type: "source", src: ".", toolchain: { type: "rust", binaryName: "api" } })
.cpu(0.5)
.memory("512Mi")
.tunnel(8080) // reachable from your backend through the manager
.link(bucket)
.permissions("api")
.build()
export default new alien.Stack("files")
.platforms(["kubernetes"])
.add(bucket, "frozen")
.add(api, "live")
.permissions({ profiles: { api: { bucket: ["storage/data-read", "storage/data-write"] } } })
.build()
The same resources map to each platform's native services: Storage becomes S3, Google Cloud Storage, Azure Blob Storage, or an S3-compatible store (MinIO, Ceph) on Kubernetes. Workers, queues, key-value stores and vaults work the same way. See Infrastructure.
After one install
Once a customer installs, you don't need access to their environment again:
-
Releases. alien release rolls out to every deployment following its channel (production by default). Stage releases on other channels, promote them with alien releases promote, and pin a deployment with alien deployments pin. The Operator also updates itself to the version the manager runs.
-
Images. Clusters pull images through the manager with their deployment token. No registry credentials to hand out.
-
Logs and traces. Deployments send OpenTelemetry to the manager, which forwards it to your backend: Datadog, Grafana, Honeycomb, Axiom, Coralogix, or any OTLP endpoint. alien logs --deployment acme/acme shows recent logs without one.
-
Tunnels. Your backend calls a container inside any deployment through the manager, over the Operator's outbound connection. Request and response bodies stream in both directions, and the app's own Authorization header passes through:
curl https://manager.example.com/v1/deployments/acme/tunnels/api/files \
-H "Proxy-Authorization: Bearer ax_tunnel_..." \
-H "Authorization: Bearer <your app's token>"
alien tokens create --tunnel makes a token that can only call tunnels, optionally for a single customer. Revoke it with alien tokens revoke.
-
Commands. Invoke handlers inside a deployment from your backend with Remote Commands.
Air-gapped environments
Sites with no connection to your manager get the same app through one folder their admin carries in and out. You keep running alien release; the site runs alien-deploy sync on both sides of the gap:
alien onboard site-7 --platforms kubernetes --airgapped # the site's token, bundle key and start command
# online: sends the site's reports, downloads the next signed update into site-7-sync/
alien-deploy sync --token ax_... --manager https://manager.example.com
# inside the site: verifies the signature, pushes images to the site's registry,
# installs or upgrades the chart, writes a report for the trip back
alien-deploy sync --registry registry.internal/vendor -f values.yaml \
--trusted-key ed25519:... # first install only; later updates must match it
After the first run, alien-deploy sync with no options does whatever the side it runs on can do. Updates carry only the image layers the site doesn't have, reports carry the site's state and logs (none are lost between trips), and alien-deploy rollback returns to the previous release. See Air-gapped deployments.
Least-privilege permissions
Alien derives the permissions each part needs from the stack definition:
- Provisioning. The customer's admin sets up the environment once with their own credentials. Alien never holds these.
- Management. What Alien uses day to day. Frozen resources only get health checks. Live resources can be updated, but management never includes data access.
- Application. What your code can reach, as declared in permission profiles.
storage/data-read becomes s3:GetObject on AWS, storage.objects.get on Google Cloud and the matching Azure role.
See Permissions and Frozen and live.
Examples
More in examples/.
Repository
Documentation
Community
