# Docs

- Guide: Start here, design what runs where, then describe your stack, call deployments, develop locally, and release.

  - **Get started**
  - [Introduction](/docs): Alien provides infrastructure for deploying and operating software in remote environments at scale, close to sensitive data, private networks, local resources, and latency-critical workloads.
  - [Quickstart](/docs/guide/quickstart): Add Alien to your repository with a coding agent, or build a worker by hand, run it locally as two customers, and deploy it to a cloud account you control.
  - [How Alien works](/docs/guide/how-alien-works): The one-time initial setup the customer's admin runs, the ongoing management Alien does on every release, and what Alien can and can't do in a customer's account.
  - Architecture design
    - [Architecture design](/docs/guide/design): Decide which part of your product runs in each customer's environment, from only their encryption key to the whole product.

    - **Patterns**
    - [Control plane ⇄ Data plane](/docs/guide/design/control-plane-data-plane): Keep the shared part of your product in your cloud and run the part that handles customer data wherever each customer needs it, from a shared deployment in your cloud to the customer's own account.
    - [Agent or connector](/docs/guide/design/agent-or-connector): Run a small agent on the customer's machines, cluster, or network that reaches their private systems and connects out to your cloud.
    - [Whole product](/docs/guide/design/whole-product): Deploy every service and its storage into the customer's environment, including air-gapped sites, and know what you give up compared to a split.

    - **Data and connections**
    - [Classify your data](/docs/guide/design/classify-your-data): Sort every field your product stores or sends into content, derived data, describing text, credentials, and metadata, and decide with the buyer what may leave.
    - [Connect your backend](/docs/guide/design/connect-your-backend): How your backend and each deployment talk to each other, and how browsers reach a deployment without customer content passing through your cloud.

  - **Your stack**
  - [Stacks](/docs/guide/stacks): Describe what you deploy in alien.ts, the stack Alien builds, releases, and deploys into every remote environment.
  - [Bring an existing app](/docs/guide/existing-app): Move a product that ships as a Helm chart, docker-compose file, or container images onto Alien, so it deploys and updates in every customer environment from one alien.ts.
  - [Frozen and live resources](/docs/guide/frozen-and-live): Choose, per resource, whether the customer's admin creates it once at initial setup or Alien manages it on every release, and what each costs in permissions.
  - [Inputs and secrets](/docs/guide/inputs-and-secrets): Declare the values each deployment needs, say whether you or the customer's admin provides them, and keep customer secrets out of Alien.
  - [Permissions](/docs/guide/permissions): Grant each workload exactly the access it needs with permission profiles, and understand the three permission layers in a deployment.
  - [Networking and endpoints](/docs/guide/networking): Expose a Worker or Container over HTTPS, keep services private inside the stack, and know which network choices belong to initial setup.

  - **Connect your backend**
  - [Backend connections](/docs/guide/backend-connections): Every way your backend and a customer's deployment exchange work and data, what each one carries, and when to use it.
  - [Commands](/docs/guide/commands): Run code in a customer's environment from your backend and get the result back, with zero inbound networking and no ports to open.
  - [Remote bindings](/docs/guide/remote-bindings): Read and write one resource in the customer's account from your backend, through cloud APIs with scoped credentials and no inbound networking.

  - **Develop and release**
  - [Local development](/docs/guide/local-development): Run your whole stack on your machine with alien dev, using local equivalents of every cloud resource.
  - [Testing](/docs/guide/testing): Deploy your stack from a test suite with @alienplatform/testing, then call its endpoints and commands like your backend would.
  - [Releases](/docs/guide/releases): Publish your stack as a release, move channels to roll it out, pin deployments, and automate it from CI.
  - [Build with an AI agent](/docs/guide/ai-agents): Install the Alien agent skills so your coding agent can decide what runs in each customer's environment and build it end to end.

  - **Customer-managed keys**
  - [Customer-managed keys](/docs/guide/customer-managed-keys): Let each customer hold the key that makes their data readable, in their own AWS KMS, Google Cloud KMS, or Azure Key Vault, and revoke it at any time.
  - [Quickstart](/docs/guide/customer-managed-keys/quickstart): Connect a test key as your own customer, encrypt and decrypt one value, then watch decryption fail when the key is disabled.
  - [Add customer-managed keys to your product](/docs/guide/customer-managed-keys/add-to-your-product): Build a Customer-managed keys settings page into a product you host. The customer connects a key in their cloud; your backend encrypts through the Encrypt/Decrypt API.
  - [AWS Virtual Keys](/docs/guide/customer-managed-keys/virtual-keys): Encrypt S3, Aurora, DynamoDB, or EBS in your own AWS account with a key your customer holds, through an ordinary AWS KMS key ARN.
  - [Customer-managed keys in a deployment](/docs/guide/customer-managed-keys/in-a-deployment): Encrypt a deployment's storage, databases, and volumes with a key the customer owns and can revoke, using alien.Key in alien.ts.
  - [Data and keys](/docs/guide/customer-managed-keys/security): What Alien receives, what the customer's key controls, what must match at decrypt time, and what your application must do.

  - **Local AI models**
  - [Local AI models](/docs/guide/local-ai-models): Run your product's AI requests on each customer's own model account, with their approved models, their terms, and their committed spend, from your hosted product or from inside their cloud.
  - [Quickstart](/docs/guide/local-ai-models/quickstart): Connect a test model provider as your own customer and send your first request through the AI Gateway.
  - [Add customer AI models to your product](/docs/guide/local-ai-models/add-to-your-product): Build an AI models settings page into a product you host. The customer connects their model provider; your backend calls it through the AI Gateway.
  - [Requests and models](/docs/guide/local-ai-models/routing): How the AI Gateway picks the customer, model, provider, and protocol for each request, and how to read its logs and usage.
  - [Local AI models in a deployment](/docs/guide/local-ai-models/in-a-deployment): Call models in the customer's own Amazon Bedrock, Vertex AI, or Azure AI Foundry with no API keys, or serve open-weight models on GPUs.

  - **Subaccounts**
  - [Subaccounts](/docs/guide/subaccounts): Give each customer a single-tenant deployment in its own AWS account, Google Cloud project, or Azure resource group, created and deployed by Alien in your cloud.
  - [Connect a cloud](/docs/guide/subaccounts/connect-a-cloud): Give Alien access to create subaccounts in your AWS organization, Google Cloud organization, or Azure subscription.
  - [Warm pools](/docs/guide/subaccounts/warm-pools): Keep subaccounts ready, with their quotas already requested, so a new customer's deployment starts at once instead of waiting on the cloud provider.
  - [Quotas](/docs/guide/subaccounts/quotas): How many subaccounts your cloud allows, how to raise that limit, and how Alien requests the quotas each new account needs.
- Infrastructure: Every resource your product uses, in your cloud or the customer's: what each becomes on each platform, and what each platform needs for initial setup.
  - [Infrastructure](/docs/infrastructure): Every resource your product uses, in your cloud or the customer's, from Workers to Postgres to the customer's own AI models, and the native service each becomes on AWS, Google Cloud, and Azure.
  - [Using resources](/docs/infrastructure/using-resources): Declare a resource in alien.ts, link it to the code that uses it, call it through a binding, and choose whether the admin or Alien manages it.

  - **Compute**
  - [Choose compute](/docs/infrastructure/compute): Pick a Worker, Container, or Daemon for each workload in your stack, and group machines into compute pools.
  - Worker
    - [Worker](/docs/infrastructure/worker): Stateless compute that runs on HTTP requests, commands, queue messages, storage events, or a schedule, and scales to zero when idle.
    - [Worker API reference](/docs/infrastructure/worker/api): Handler registration, event types, waitUntil, and the Worker binding in TypeScript, Python, and Rust.
    - [Worker behavior and limits](/docs/infrastructure/worker/behavior): Guarantees, limits, per-platform details, and design decisions for Workers.
    - [Events and triggers](/docs/infrastructure/worker/events-and-triggers): Run a Worker from queue messages, storage events, and cron schedules.
    - [Toolchains](/docs/infrastructure/worker/toolchains): How Alien builds and packages Worker code from TypeScript, Rust, Python, or a Dockerfile, or uses a prebuilt image.
    - [Wait until](/docs/infrastructure/worker/wait-until): Run background work in a Worker after the response is sent.
    - [Worker pricing](/docs/infrastructure/worker/pricing): What a Worker costs in the customer's cloud, with a worked example.
  - Container
    - [Container](/docs/infrastructure/container): Long-lived services and background processes from an image, with internal DNS, public endpoints, persistent volumes, backups, and GPUs.
    - [Container API reference](/docs/infrastructure/container/api): Container builder methods, endpoint and volume options, SDK clients, outputs, and volume CLI commands.
    - [Container behavior and limits](/docs/infrastructure/container/behavior): Placement, scaling, endpoints, volumes, backups, per-platform details, and limits for the Container resource.
    - [Container pricing](/docs/infrastructure/container/pricing): What a Container costs in the customer's cloud account, with list prices for load balancers, volumes, and snapshots.
  - Daemon
    - [Daemon](/docs/infrastructure/daemon): One long-lived process on every eligible machine or Kubernetes node, for agents, collectors, connectors, and host loaders.
    - [Daemon API reference](/docs/infrastructure/daemon/api): Daemon builder methods, runtime options, public endpoints, environment variables, and outputs.
    - [Daemon behavior and limits](/docs/infrastructure/daemon/behavior): Placement, per-platform behavior, host runtime support, public endpoints, and limits for the Daemon resource.
    - [Daemon pricing](/docs/infrastructure/daemon/pricing): What a Daemon costs in the customer's cloud account.
  - Sandbox
    - [Sandbox](/docs/infrastructure/sandbox): Isolated environments your app creates at runtime to run code it doesn't trust, such as user scripts, builds, or code a model wrote.
    - [Sandbox API reference](/docs/infrastructure/sandbox/api): Every Sandbox method and type in the TypeScript, Python, and Rust SDKs.
    - [Sandbox behavior and limits](/docs/infrastructure/sandbox/behavior): Guarantees, limits, egress rules, image startup, and per-platform behavior for Sandbox resources.
    - [Sandbox security](/docs/infrastructure/sandbox/security): Isolation boundaries, users and privileges, outbound enforcement, trusted callers, and known limits of Sandbox resources.
    - [Remote Sandboxes for a hosted product](/docs/infrastructure/sandbox/customer-sandboxes): Run the code your product executes for a customer inside sandboxes in their cloud, called from your hosted backend through the Sandbox Gateway.
    - [Sandbox pricing](/docs/infrastructure/sandbox/pricing): What sandboxes, the egress gateway, and NAT cost in the customer's cloud, with a worked example.
  - [ComputeCluster](/docs/infrastructure/compute-cluster): ComputeCluster pools, hardware requirements, scaling, node permissions, and platform mapping for containers and daemons.

  - **Data**
  - Storage
    - [Storage](/docs/infrastructure/storage): Object storage for files, uploads, and blobs on S3, Cloud Storage, Blob Storage, or a local directory, with one API across clouds.
    - [Storage API reference](/docs/infrastructure/storage/api): Every Storage method and type in the TypeScript, Python, and Rust SDKs, with parameters, results, and error codes.
    - [Storage behavior and limits](/docs/infrastructure/storage/behavior): Consistency, durability, limits, operation semantics, triggers, notifications, encryption, and per-cloud details for the Storage resource.
    - [Customer buckets for a hosted product](/docs/infrastructure/storage/customer-buckets): Keep each customer's files in a bucket in their own cloud account while your backend stays hosted and reads and writes it directly.
    - [Storage pricing](/docs/infrastructure/storage/pricing): What a Storage resource costs in the customer's cloud account on AWS, GCP, and Azure, with a worked example.
  - KV
    - [KV](/docs/infrastructure/kv): A key-value store for small records on DynamoDB, Firestore, Table Storage, or a local database, with TTLs, conditional writes, and prefix scans.
    - [KV API reference](/docs/infrastructure/kv/api): Every KV method and type in the TypeScript, Python, and Rust SDKs, with conditional writes, scan pagination, and error codes.
    - [KV behavior and limits](/docs/infrastructure/kv/behavior): Consistency, conditional writes, TTL, scan semantics, limits, and per-cloud details for the KV resource.
    - [KV pricing](/docs/infrastructure/kv/pricing): What a KV resource costs in the customer's cloud account on DynamoDB, Firestore, and Table Storage, with a worked example.
  - Queue
    - [Queue](/docs/infrastructure/queue): A message queue with at-least-once delivery on SQS, Pub/Sub, Service Bus, or a local queue, for background work and Worker triggers.
    - [Queue API reference](/docs/infrastructure/queue/api): Every Queue method and type in the TypeScript, Python, and Rust SDKs, with batch outcomes, leases, and error codes.
    - [Queue behavior and limits](/docs/infrastructure/queue/behavior): Delivery guarantees, leases, limits, triggers, and per-cloud settings for the Queue resource.
    - [Queue pricing](/docs/infrastructure/queue/pricing): What a Queue resource costs in the customer's cloud account on SQS, Pub/Sub, and Service Bus, with a worked example.
  - Postgres
    - [Postgres](/docs/infrastructure/postgres): A managed PostgreSQL database on a private network, on Aurora, Cloud SQL, Flexible Server, or a local process, with pgvector included.
    - [Postgres API reference](/docs/infrastructure/postgres/api): The Postgres connection API in the TypeScript, Python, and Rust SDKs, TLS modes, the binding per platform, and error codes.
    - [Postgres behavior and limits](/docs/infrastructure/postgres/behavior): What Postgres guarantees on each platform, sizing and tiers, backups, changes to a running database, deletion, and limits.
    - [Postgres pricing](/docs/infrastructure/postgres/pricing): What a Postgres resource costs in the customer's cloud account on Aurora, Cloud SQL, and Flexible Server, with a worked example.

  - **Secrets and keys**
  - Vault
    - [Vault](/docs/infrastructure/vault): Secrets your software reads and writes at runtime, stored in the cloud's own secret service in the environment you deploy to.
    - [Vault API reference](/docs/infrastructure/vault/api): Every Vault method in the TypeScript, Python, and Rust SDKs, the binding per platform, and error codes.
    - [Vault behavior and limits](/docs/infrastructure/vault/behavior): How Vault stores secrets on each platform, naming rules, size limits, deletion, access scoping, and throttling.
    - [Vault pricing](/docs/infrastructure/vault/pricing): What a Vault resource costs in the customer's cloud account on SSM Parameter Store, Secret Manager, and Key Vault, with a worked example.
  - [Key](/docs/infrastructure/key): A customer-managed encryption key in the customer's own key service, used to encrypt storage, databases, and volumes, and small values from code.

  - **AI and email**
  - AI
    - [AI](/docs/infrastructure/ai): Model inference through the customer's own cloud, Amazon Bedrock, Vertex AI, or Azure AI Foundry, with no API keys in your app.
    - [AI API reference](/docs/infrastructure/ai/api): The AI client in the TypeScript and Python SDKs, the binding, the gateway endpoints, and error codes.
    - [AI behavior and limits](/docs/infrastructure/ai/behavior): Guarantees, limits, protocols, model availability, and per-cloud details for the AI resource.
    - [AI models](/docs/infrastructure/ai/models): The models Alien serves on each cloud, their native protocol, and the setup each cloud needs before they answer.
    - [AI pricing](/docs/infrastructure/ai/pricing): What AI inference costs in the customer's cloud, with a worked example.
  - Email
    - [Email](/docs/infrastructure/email): Send and receive mail on customer-owned domains with Amazon SES in the customer's AWS account.
    - [Email API reference](/docs/infrastructure/email/api): The Email binding, permission sets, runtime domain management, inbound mail, and sending events.
    - [Email behavior and limits](/docs/infrastructure/email/behavior): Guarantees, limits, inbound activation, update semantics, and what initial setup provisions for the Email resource.
    - [Email pricing](/docs/infrastructure/email/pricing): What Amazon SES costs in the customer's AWS account, with a worked example.

  - **Networking and access**
  - Network
    - [Network](/docs/infrastructure/network): The VPC or VNet a deployment runs in. When Alien adds it, the network modes, how to set them, and outputs.
    - [Network settings reference](/docs/infrastructure/network/settings): Every StackSettings.network mode and field.
    - [Network behavior and limits](/docs/infrastructure/network/behavior): Guarantees, CIDR selection, subnet layout, limits, and per-cloud details for the Network.
    - [Network pricing](/docs/infrastructure/network/pricing): What a Network costs in the customer's cloud, by mode, with a worked example.
  - [Supporting resources](/docs/infrastructure/supporting-resources): ArtifactRegistry, Build, and ServiceAccount, and the names deployment status shows for every resource Alien adds to a stack.

  - **Platforms**
  - [AWS](/docs/infrastructure/platforms/aws): A deployment in a customer's AWS account: what the admin needs, initial setup with CloudFormation, Terraform, or the CLI, the management role, updates, and removal.
  - [Google Cloud](/docs/infrastructure/platforms/gcp): A deployment in a customer's Google Cloud project: what the admin needs, initial setup with Google login, Terraform, or the CLI, what it creates, updates, and removal.
  - [Azure](/docs/infrastructure/platforms/azure): A deployment in a customer's Azure subscription: what the admin needs, initial setup with Terraform or the CLI, the managed identity and its role limits, updates, and removal.
  - [Kubernetes](/docs/infrastructure/platforms/kubernetes): A deployment in a customer's Kubernetes cluster: what the admin needs, Helm or a new EKS, GKE, or AKS cluster, the Operator that pulls releases, tunnels, and removal.
  - [Linux servers](/docs/infrastructure/platforms/machines): A deployment on a customer's own Linux hosts: what they need, the join command, the machine agent that pulls releases, offline behavior, and removal.
  - [Single-tenant in your cloud](/docs/infrastructure/platforms/single-tenant): A deployment dedicated to one customer in your own cloud account: how to create it, infrastructure changes without rerunning initial setup, and a customer-managed key on AWS.
  - [Setup packages](/docs/infrastructure/platforms/setup-packages): The setup packages Alien builds from each release for initial setup (CloudFormation, Terraform, Helm, and a CLI): when they're built, versions, hosting, settings, and previews.
  - [Push, pull, and air-gapped](/docs/infrastructure/platforms/deployment-models): How releases and commands reach a deployment after initial setup: push through a scoped cloud identity, pull through an outbound Operator, or air-gapped.
- Deployment UX: The screens your customer's admin uses to set up and manage your software in their cloud: a link to the deployment portal, the portal launched from your product, or your own UI.
  - [Deployment UX](/docs/deployment-ux): What your customer's admin sees when they set up your software in their own cloud, and the three levels of building it into your product.

  - **Send a link**
  - [Create a setup link](/docs/deployment-ux/setup-links): A setup link is a URL for one customer that opens the deployment portal. Create one in the dashboard, CLI, or API, choose what it allows, and send it.
  - [Deployment portal](/docs/deployment-ux/deployment-portal): A branded setup page Alien hosts for your customer's admin. They open one link, set up your software in their own cloud, and follow its status.
  - [Brand the portal](/docs/deployment-ux/branding): White-label the deployment portal with your logo, colors, and domain, and rename the setup CLI and Google sign-in your customer's admin sees.

  - **Launch from your product**
  - [Add a Deploy button](/docs/deployment-ux/deploy-button): Add a Deploy in your cloud button to your settings page that opens the deployment portal, then show the deployment's progress and removal in your product.
  - [Show deployment progress](/docs/deployment-ux/deployment-progress): Show your customer what their deployment is doing, who must act next, and when it's ready, from a few fields on one API response.
  - [Errors and retries](/docs/deployment-ux/errors-and-retries): Show a deployment's errors so customers know whether to wait, fix something in their cloud, or retry, and hide the noise Alien retries on its own.
  - [Verify and activate](/docs/deployment-ux/verify-and-activate): Check that your product can reach a customer's new deployment, then turn the feature on. Running means Alien finished, not that the feature works.
  - [Updates and connection](/docs/deployment-ux/updates-and-connection): Keep your deployment card honest after initial setup. Show when a new release needs the customer's admin, and when Alien can't confirm the current state.
  - [Remove a deployment](/docs/deployment-ux/remove-a-deployment): Remove a customer's deployment from your product, switch traffic off first, and keep or erase the data in their cloud.
  - [Follow removal](/docs/deployment-ux/follow-removal): Show a customer's removal until it ends, including the last step their admin finishes in their own cloud, and close your record when it's done.

  - **Build it into your product**
  - [Build your own setup screen](/docs/deployment-ux/setup-screen): Add a Deploy in your cloud screen to your product. One API call creates the deployment and returns the setup step for the customer's cloud.
  - [Sizes and networks](/docs/deployment-ux/sizes-and-networks): Offer Small, Medium, and Large sizes and a network choice when a customer sets up a deployment from your product.
  - [Resize a deployment](/docs/deployment-ux/resize-a-deployment): Let customers change the size of a running deployment from your product, and show the resize until it finishes.

  - **Best practices**
  - [Who acts next](/docs/deployment-ux/who-acts-next): Make every deployment state say who must act next, your customer's admin, Alien, or your team, and hand off to the admin when it's their turn.
  - [Status messages](/docs/deployment-ux/status-messages): The words to use on your deployment card for each state, how to write errors your customer can act on, and how to keep status accessible.
  - [Links and branding](/docs/deployment-ux/links-and-branding): Checks before your first customer opens a setup link: link expiry and limits, a branded portal and CLI, sizes, networks, and removal.
- Production: Ongoing management after customers deploy: watch deployments, get webhooks, roll out releases, search logs, debug, and fix issues with Remote Operator.
  - [Production](/docs/production): Ongoing management of your customers' deployments. Watch status, get webhooks, roll out releases, search logs, debug, and fix issues with Remote Operator.

  - **Before launch**
  - [Go-live checklist](/docs/production/go-live-checklist): The checks to finish before the first real customer deploys, with why each matters and how to do it.
  - [Private managers](/docs/production/private-managers): Run the Alien manager in your own AWS, Google Cloud, or Azure account so deployment traffic and logs stay in your cloud.

  - **Watch deployments**
  - [Deployments and groups](/docs/production/deployments): Find every remote environment, read its status, and tell a running deployment from a healthy one.
  - [Follow a deployment](/docs/production/customer-setup): Watch a customer's initial setup and the deployment after it from the dashboard or the CLI, and know when to step in and when the admin must act.
  - [Webhooks](/docs/production/webhooks): Get a signed HTTPS request when a deployment starts running, fails, updates, loses its heartbeat, or is deleted, instead of polling.
  - [Logs and metrics](/docs/production/logs): Search the logs every deployment sends, read health and resource metrics, and forward logs to Datadog, Coralogix, Axiom, or any OTLP endpoint.

  - **Release and fix**
  - [Roll out releases](/docs/production/rollouts): Move deployments between releases with channels, promotion, and pins, stage a rollout, verify it landed, and handle held releases.
  - [Debug a deployment](/docs/production/debugging): The CLI sequence for finding why a deployment failed, stalled, or misbehaves, from its status down to a shell on the host.
  - [Troubleshooting](/docs/production/troubleshooting): Find your symptom, learn what it means and who has to act, and fix stuck, failed, silent, or half-removed deployments.

  - **Remote Operator**
  - [Remote Operator](/docs/production/remote-operator): One outbound-only container that lets your team and agents diagnose and fix customer deployments through named, approved, audited operations.
  - [Add to an existing product](/docs/production/remote-operator/add-to-existing-product): Add Remote Operator to a Helm chart or Amazon ECS service you already ship, verify it with a read-only diagnostic, and record the version it runs.
  - [Operations](/docs/production/remote-operator/operations): The built-in operations catalog, risk tiers, approval rules in alien.ts or Helm values, and how to build and publish your own plugin.
  - [Access requests](/docs/production/remote-operator/access-requests): Request time-boxed access to operations and debug sessions, see who approves on each platform, and revoke a grant.
  - [Debug sessions](/docs/production/remote-operator/debug): Run kubectl, aws, gcloud, or az against one deployment with scoped, time-boxed credentials, and open a shell on Machines and local deployments.
  - [Slack and the AI agent](/docs/production/remote-operator/slack): Connect Slack for rollout reports and access-request approvals, and use the AI agent that investigates deployments and answers @Alien.
  - [Upgrade, rotate, and remove](/docs/production/remote-operator/lifecycle): Rotate an installation's connection key, upgrade or roll back the Operator, recover a stuck Helm release, repair a lost connection, and uninstall it.
- API reference: Exact interfaces: alien.ts, the CLI, SDKs, and the REST API.
  - [API reference](/docs/reference): Look up alien.ts options, CLI commands, SDK packages, REST endpoints, permission sets, and terms.

  - **Configuration**
  - [Stack](/docs/reference/stack): Every stack-level option in alien.ts. Resources and lifecycles, platforms, permissions, inputs, operations, and dynamic containers.
  - [Permissions](/docs/reference/permissions): Permission profiles, scopes, management access, custom permission sets, and every built-in permission set by resource.
  - [Environment variables](/docs/reference/environment-variables): Variables Alien injects into workloads, binding variables, how to set your own variables and secrets, and reserved names.

  - **CLI**
  - [alien CLI](/docs/reference/cli/alien): Every command and flag of the alien CLI: build, release, onboard customers, deploy, and operate deployments.
  - [alien-deploy CLI](/docs/reference/cli/alien-deploy): Every command and flag of alien-deploy, the CLI your customers run to set up, update, and remove a deployment.

  - **SDKs**
  - [TypeScript SDK](/docs/reference/sdk/typescript): Runtime bindings, command handlers, event handlers, and waitUntil for TypeScript code that runs in a deployment.
  - [Python SDK](/docs/reference/sdk/python): Async Python bindings for resources linked to a workload, queue handlers for Workers, and remote bindings.
  - [Rust SDK](/docs/reference/sdk/rust): The alien-sdk crate for Rust workloads, with resource bindings and the Worker context for commands, events, and waitUntil.
  - [Testing package](/docs/reference/sdk/testing): Deploy a stack from a test with @alienplatform/testing, call its endpoints and commands, then tear it down.
  - [Platform API client](/docs/reference/sdk/platform-api): Call the Alien REST API from your backend with the typed @alienplatform/platform-api TypeScript client.

  - **REST API**
  - [REST API](/docs/reference/api): Base URL, API keys, scopes and roles, errors, and pagination for the Alien REST API.
  - [Auth](/docs/reference/api/auth)
  - [API keys](/docs/reference/api/api-keys)
  - [Workspaces](/docs/reference/api/workspaces)
  - [Projects](/docs/reference/api/projects)
  - [Setup links](/docs/reference/api/setup-links)
  - [Deployment groups](/docs/reference/api/deployment-groups)
  - [Deployments](/docs/reference/api/deployments)
  - [Releases](/docs/reference/api/releases)
  - [Release channels](/docs/reference/api/release-channels)
  - [Packages](/docs/reference/api/packages)
  - [Dynamic containers](/docs/reference/api/dynamic-containers)
  - [Machines](/docs/reference/api/machines)
  - [Domains](/docs/reference/api/domains)
  - [Commands](/docs/reference/api/commands)
  - [Operations](/docs/reference/api/operations)
  - [Debug sessions](/docs/reference/api/debug-sessions)
  - [Remote bindings](/docs/reference/api/remote-bindings)
  - [Remote Operator install](/docs/reference/api/remote-operator-install)
  - [Managers](/docs/reference/api/managers)
  - [Events](/docs/reference/api/events)
  - [Resources](/docs/reference/api/resources)
  - [AWS virtual keys](/docs/reference/api/aws-virtual-keys)
  - [Gateways](/docs/reference/api/gateways)
  - [Cloud regions](/docs/reference/api/cloud-regions)
  - [User](/docs/reference/api/user)

  - **Platforms and terms**
  - [Platforms](/docs/reference/platforms): Which resources each platform supports and what Alien provisions for them on AWS, Google Cloud, Azure, Kubernetes, Linux servers, and Local.
  - [Glossary](/docs/reference/glossary): Short definitions of the Alien terms used across the docs, CLI, and dashboard, from deployment groups and setup links to frozen resources and the Operator.
- Examples: Complete projects grouped by how much of the product runs in the customer's environment.
  - [Examples](/docs/examples): Complete Alien projects, from a one-command Worker to a whole product in a customer's Kubernetes cluster, grouped by how much runs in the customer's environment.

  - **Start here**
  - [Hello world](/docs/examples/hello-world): One Worker with an HTTPS route and one command your backend can call, in TypeScript or Rust, from local development to a customer's cloud.
  - [Deploy a Next.js app into a customer's cloud](/docs/examples/nextjs-application): Run an existing Next.js app as a Container in each customer's AWS, Google Cloud, or Azure account, with its own HTTPS endpoint.
  - [Run a Python service in the customer's cloud](/docs/examples/python-container): Build a locked Python project into a Container without a Dockerfile, serve HTTP from it, and call linked resources with the alienplatform SDK.
  - [Call models in the customer's cloud](/docs/examples/ai-quickstart): A Worker that lists and calls the models in Amazon Bedrock, Vertex AI, or Azure AI Foundry with its own cloud identity. No API keys.

  - **Control plane ⇄ Data plane**
  - [Build a GitHub integration with a hosted dashboard](/docs/examples/github-agent): A full product split into a hosted Next.js dashboard and a small GitHub Worker that runs in each customer's environment, with the GitHub token kept in the customer's vault.
  - [Chat with a private Postgres database](/docs/examples/private-postgres-chat): A streaming Next.js chat app in the customer's cloud that answers from a private Postgres through a model served by the same cloud. No API keys, no database password in the app.
  - [Receive webhooks in the customer's cloud](/docs/examples/webhook-api): Give each customer an HTTPS endpoint that stores webhooks in their own account, query the events from your backend with commands, and configure each deployment with stack inputs.
  - [Process events in the customer's cloud](/docs/examples/event-pipeline): One Worker that handles queue messages, new files in a bucket, and an hourly schedule inside the customer's account, with results your backend reads through commands.
  - [Route commands to a Worker and a Daemon](/docs/examples/command-routing): Call the same command name on two resources in one customer deployment and pick the one that answers with a target.
  - [Store AI trace history in the customer's object storage](/docs/examples/trace-history): Build a durable, queryable AI trace store on SlateDB and the customer's bucket, with no database server to run in their cloud.
  - [Build a vector database on the customer's object storage](/docs/examples/vector-database): Run stateless Rust readers and writers behind an Nginx router, with every vector stored in the customer's bucket and concurrent writes coordinated by ETags.

  - **Agent or connector**
  - [Build a Kubernetes agent](/docs/examples/kubernetes-agent): A TypeScript agent in each customer's Kubernetes cluster that reports pods, deployments, and nodes to your API and answers commands, with read-only access, a generated enrollment token, and updates on every release.
  - [Query a private database](/docs/examples/private-database): A connector Worker beside a database you can't reach, with the connection secret in the customer's vault and only results returned to you.
  - [Build a command-only agent for employee devices](/docs/examples/endpoint-agent): Run a Rust Daemon on each device that watches files, flags sensitive data, keeps events in an encrypted local database, and answers your backend only through commands.
  - [Run an agent's tools in the customer's cloud](/docs/examples/remote-tools): Keep the agent loop in your product and run its tool calls in a private Worker next to the customer's files.

  - **Whole product**
  - [Run a service in your customers' Kubernetes clusters](/docs/examples/customer-kubernetes): Ship one Rust service to every customer's Kubernetes cluster, including air-gapped sites, with one Helm install per customer and outbound-only updates.
  - [Ship a multi-service app into a customer's Kubernetes cluster](/docs/examples/full-application): Deploy a gateway, dashboard, API, worker, scheduler, Postgres, Redis, and object storage as one release into each customer's cluster.

  - **Keys, models, and storage**
  - [Encrypt your data with a key in each customer's KMS](/docs/examples/customer-keys): Create a key in each customer's AWS KMS, Cloud KMS, or Key Vault and encrypt and decrypt with it from your hosted backend, without ever holding the key.
  - [Run model calls on each customer's AWS or Google Cloud account](/docs/examples/customer-models): Release a stack with one AI resource, let each customer connect Bedrock or Vertex AI, and call their models from your hosted backend through the AI Gateway.
  - [Store files in each customer's own bucket](/docs/examples/customer-storage): Create a dedicated bucket in each customer's AWS, Google Cloud, or Azure account and read and write it from your hosted backend, with no compute in their cloud.

  - **Remote Operator plugins**
  - [Build a custom Remote Operator plugin](/docs/examples/custom-operations): Write a Rust plugin with one read-only and one mutating operation against your application's admin API, then publish it and run it in customer deployments.

## Blog

- [A kill switch for your customers' data](https://www.alien.dev/blog/customer-managed-keys): In multi-tenant SaaS, every customer's data sits behind one vendor's key. What it takes to give each customer their own key, and how we built it.
- [Auth for BYOC apps, part two: when the client is an agent](https://www.alien.dev/blog/auth-for-byoc-agents): Control plane auth answers whether a person may reach a deployment. When the software inside the deployment acts on its own and talks to the outside world, it needs an identity of its own.
- [Authentication for BYOC apps](https://www.alien.dev/blog/byoc-authentication): When your app runs in the customer's cloud, where does login happen and where do API keys live? Auth stays in your control plane; the data plane only verifies tokens.
- [The agent nobody operates](https://www.alien.dev/blog/the-agent-nobody-operates): Most B2B products ship a component that customers run inside their own environment. It usually has no owner, no release process, and more access than anything else you ship.
- [What is BYOC? Bring your own cloud, explained](https://www.alien.dev/blog/what-is-byoc): BYOC means the vendor's software runs in the customer's cloud account while the vendor still operates it — and the second half is the part people miss.