Alien

Alien provides infrastructure to deploy and operate software inside your users' environments, while retaining centralized control over updates, monitoring, and lifecycle management.

Why Alien?

Self-hosting works - until someone starts paying for your software.

Customers run it in their own environment, but they don't actually know how to operate it. They might change something small like Postgres version, environment variables, IAM, firewall rules, and things start failing. From their perspective, your product is broken. And even if the root cause is on their side, it doesn't matter... the customer is always right, you're still the one expected to fix it.

But you can't. You don't have access to their environment. You don't have real visibility. You can't run anything yourself. So you're stuck debugging a system you don't control, through screenshots and copy-pasted logs on a Zoom call. You end up responsible for something you don't control.

Alien provides a better model: managed self-hosting.

Quickstart

Install the CLI:

curl -fsSL https://alien.dev/install | sh -s -- --login

irm https://alien.dev/install.ps1 | iex

Create a project and start developing:

alien init
cd alien && alien dev

Follow the Quickstart guide to build an AI worker, test it locally, and deploy it — no cloud account needed to start.

CLI automation

Every platform workflow has a non-interactive form. Link a directory once, then commands use that project unless --project is provided explicitly:

alien login
alien projects list
alien link --project my-project
alien projects describe --json

# Configure project capabilities.
alien projects capabilities enable models \
  --model byo/claude-opus-5 \
  --provider anthropic

# Create a least-privileged key and onboard a customer environment.
alien api-keys create --for ai-gateway --description production-backend --json
alien onboard acme --external-id customer_123 --setup-items models,keys --json

# Print an executable request for the active environment.
alien examples ai-gateway --protocol anthropic-messages

# Search structured gateway diagnostics without writing a raw query.
alien logs --source ai-gateway --status provider-error --provider anthropic --json

# Inspect live rollout state without parsing the raw stack state.
alien deployments status production/api
alien deployments resources production/api --json
alien deployments wait production/api --for ready --timeout 10m --json

# Read privacy-safe aggregate usage.
alien usage ai --range 7d --json

Resource detail commands accept get, describe, and show; list commands accept both list and ls. JSON mode never prompts and writes structured data to stdout, making the same CLI suitable for humans, scripts, and coding agents. The normalized resource view intentionally excludes resource configuration, internal controller state, environment variables, and arbitrary provider outputs.

Features

• AWS, GCP, and Azure support - Deploy to all major clouds.
• TypeScript & Rust — First-class support for both. Python and arbitrary containers coming soon.
• Real-time Heartbeat — Know the instant a deployment goes down.
• Auto Updates & Rollbacks — Push a release and every remote environment picks it up automatically.
• Local-first Development — Build and test on your machine. Local equivalents for every cloud resource.
• Cloud-agnostic Infrastructure — Ship to AWS, GCP, and Azure customers without maintaining separate integrations. Alien maps a single API to each cloud's native services at deploy time.
• Remote Commands — Invoke code on remote deployments from your control plane. Zero inbound networking. Zero open ports. No VPC peering.
• Observability — Logs, metrics, and traces from every deployment. Full visibility without touching customer infrastructure.
• Least-privilege Permissions — Alien derives the exact IAM permissions required to deploy and manage your app.

How deployment works

Push model

Like sharing a Google Drive folder. The customer grants least-privilege access to an isolated area in their cloud. You run alien serve on your infrastructure and it manages everything through cloud APIs (e.g. AWS UpdateWorkerCode). No network connection to their environment needed.

alien serve

Pull model

Like an app checking for updates. For customers that can't or won't allow a cross-account IAM role, they can run alien-operator in their environment instead. It connects outbound to the Alien server, fetches releases, and deploys locally. No inbound connections, no open ports.

docker run ghcr.io/alienplatform/alien-operator \
  --sync-url https://alien.example.com \
  --sync-token <token> \
  --platform aws

Both models give you the same capabilities: updates, telemetry, remote commands.

One codebase, every cloud

Ship to AWS, GCP, and Azure customers without maintaining separate integrations. Alien maps your stack to each cloud's native services at deploy time.

import * as alien from "@alienplatform/core"

const data = new alien.Storage("data").build()
const secrets = new alien.Vault("credentials").build()

const api = new alien.Worker("api")
  .code({ type: "source", src: "./api", toolchain: { type: "typescript" } })
  .link(data)
  .link(secrets)
  .commandsEnabled(true)
  .publicEndpoint("api")
  .build()

export default new alien.Stack("my-app")
  .add(api, "live")
  .add(data, "frozen")
  .add(secrets, "frozen")
  .build()

At deploy time, each resource maps to the cloud's native service.

Releases

Push a release and every environment updates automatically.

alien release

What you can build

• AI Worker — Operator harness in your cloud, tool execution in theirs. Read files, run commands, query data — all local.
• Data Connector — Query Snowflake, Postgres, or any private database. No shared credentials, no exposed services.
• Browser Automation — Headless browser inside their network. Navigate Jira, SAP, GitLab, on-prem wikis.
• Security Outpost — Scan IAM policies, storage, network configs from inside the perimeter. On a schedule or on-demand.
• Cloud Actions — API inside their network. Restart services, rotate credentials, react to infrastructure changes.

Remote commands

Invoke code inside the customer's environment from your control plane. Zero inbound networking, zero open ports.

Define a handler in the customer's environment:

import { command, storage } from "@alienplatform/sdk"

const files = storage("files")

command("read-file", async ({ path }) => {
  const data = await files.get(path)
  return { content: new TextDecoder().decode(data) }
})

Invoke it from your backend:

import { CommandsClient } from "@alienplatform/commands"

const commands = new CommandsClient({ managerUrl, deploymentId, token })
const result = await commands.target("api").invoke("read-file", {
  path: "report.csv"
})

Least-privilege permissions

You're deploying to someone else's cloud. Every permission needs justification. Alien derives exactly the permissions needed from your stack definition — for AWS, GCP, and Azure.

export default new alien.Stack("my-app")
  .add(data, "frozen")
  .add(api, "live")
  .permissions({
    profiles: {
      execution: {
        data: ["storage/data-read", "storage/data-write"],
      },
    },
  })
  .build()

From this definition, Alien derives three layers of permissions:

Provisioning — Creates all resources during initial setup. The customer's admin runs alien-deploy deploy once with their own credentials. Alien never holds these permissions.

Management — What Alien uses day-to-day to manage the deployment:

• 🧊 Frozen resources: health checks only. No ability to modify, delete, or read data.
• 🔁 Live resources: push code, roll config, redeploy. But still no data access — Alien can call lambda:UpdateWorkerCode but never s3:GetObject. Management and data access are separate.

Application runtime — What the deployed code can access. Only what's declared in permission profiles.

Production deployment

1. Generate a config template:

alien serve --init   # creates alien-manager.toml

2. Provision cloud resources for push-mode platforms:

module "alien_infra" {
  source = "github.com/aliendotdev/alien//infra/aws"

  name          = "my-project"
  principal_arn = aws_iam_role.manager.arn
}

3. Run the server.

docker run -d -p 8080:8080 \
  -v alien-data:/data \
  -v ./alien-manager.toml:/app/alien-manager.toml \
  -e BASE_URL=https://manager.example.com \
  ghcr.io/alienplatform/alien-manager