Patterns
Most Alien use cases follow one of three patterns. The pattern determines how work is split between your environment and the customer's environment.
Remote Command Target
A command-enabled Worker, Container, or Daemon runs in the customer's environment. Your control plane targets that resource by name, the application executes an explicit handler, and the result comes back through Alien.
┌─────────────────────────┐ ┌─────────────────────────┐
│ Your Cloud │ │ Customer Environment │
│ │ │ │
│ ┌─────────────────┐ │ │ ┌─────────────┐ │
│ │ Control Plane │────┼─command─┼───▶│ Target │ │
│ │ │◀───┼─result──┼────│ Worker / │ │
│ └─────────────────┘ │ │ │ Container / │ │
│ │ │ │ │ Daemon │ │
│ │ │ │ └──────┬──────┘ │
│ │ │ │ │ │
│ ┌────────▼────────┐ │ │ ┌──────▼──────┐ │
│ │ Dashboard │ │ │ │ Private │ │
│ │ Processing │ │ │ │ Resources │ │
│ └─────────────────┘ │ │ └─────────────┘ │
└─────────────────────────┘ └─────────────────────────┘Most logic lives in your cloud. The command target provides access to private resources the outside world cannot reach — databases behind VPCs, Active Directory, internal APIs, or local AI models.
Use cases: AI workers (tool calls in customer's VPC), data connectors, security scanners, browser automation for internal apps (Jira Data Center, SAP, GitLab), cloud remediation agents.
Typical implementation: use a Worker with command() handlers for
bounded, stateless work that can scale to zero. Use a Container for a
service process, or a Daemon when one receiver must run on every eligible
machine. Containers and Daemons run their own receiver from
@alienplatform/commands.
import { command, storage } from "@alienplatform/sdk"
const ws = storage("workspace")
command("get-active-users", async ({ limit }: { limit: number }) => {
const pool = new Pool(await getCustomerCredentials())
const { rows } = await pool.query(
"SELECT id, name FROM users WHERE active = true LIMIT $1",
[limit ?? 100]
)
return { rows, count: rows.length }
})
command("read-file", async ({ path }: { path: string }) => {
const object = await ws.get(path)
return object.data.toString("utf8")
})The sender names the resource explicitly:
import { CommandsClient } from "@alienplatform/commands"
const commands = new CommandsClient({ managerUrl, deploymentId, token })
const result = await commands.target("customer-tools").invoke("get-active-users", {
limit: 100,
})Control Plane / Data Plane
You run the control plane. A stateful data plane runs in the customer's environment with persistent storage and compute.
┌─────────────────────────┐ ┌─────────────────────────┐
│ Your Cloud │ │ Customer Environment │
│ │ │ │
│ ┌─────────────────┐ │ │ ┌─────────────┐ │
│ │ Control Plane │────┼─updates─┼───▶│ Data Plane │ │
│ │ - Lifecycle │ │ │ │ - Storage │ │
│ │ - Updates │◀───┼telemetry┼────│ - Compute │ │
│ │ - Monitoring │ │ │ │ - Database │ │
│ └─────────────────┘ │ │ └─────────────┘ │
└─────────────────────────┘ └─────────────────────────┘The data plane is the product. It handles the actual workload and stores data. Your control plane manages the lifecycle — ships updates, monitors health, handles incidents.
Use cases: managed databases (BYOC), AI gateways, observability platforms, any product where the compute/storage component runs in the customer's cloud.
Typical implementation: Alien Container resources with persistent storage, autoscaling, and internal networking.
Full App
A complete application runs in the customer's environment. You ship updates and monitor, but all data and logic stays remote.
┌─────────────────────────┐ ┌─────────────────────────┐
│ Your Cloud │ │ Customer Environment │
│ │ │ │
│ ┌─────────────────┐ │ │ ┌─────────────┐ │
│ │ Ship Updates │────┼─────────┼───▶│ App │ │
│ └─────────────────┘ │ │ │ - API │ │
│ │ │ │ - Workers │ │
│ ┌─────────────────┐ │ │ │ - Queue │ │
│ │ Monitor │◀───┼─────────┼────└──────┬──────┘ │
│ │ (logs/metrics) │ │ │ │ │
│ └─────────────────┘ │ │ ┌──────▼──────┐ │
│ │ │ │ Storage │ │
│ │ │ │ Database │ │
│ │ │ └─────────────┘ │
└─────────────────────────┘ └─────────────────────────┘The app is self-contained. Multiple workers, storage, queues, databases — all inside the customer's environment. You ship updates and have full visibility, but no data leaves.
Use cases: enterprise SaaS with self-hosted requirements, AI agents that need extensive private data access, internal tools deployed across many customer environments, cloud action platforms with HTTP APIs and event triggers.
Typical implementation: multiple Alien resources — Worker, Container, Storage, Kv, Queue — working together.
Choosing a pattern
| Remote Command Target | Control / Data Plane | Full App | |
|---|---|---|---|
| Where is most logic? | Your cloud | Split | Customer's environment |
| Is the remote component stateful? | Usually no; optional | Yes | Yes |
| Primary purpose? | Execute commands | Run infrastructure | Run application |
| Typical Alien resources | 1 Worker, Container, or Daemon | Multiple Containers | Multiple of any type |
Decision:
- Need persistent storage or heavy compute in the customer's environment? → Control Plane / Data Plane
- Running a full application (API, workers, storage)? → Full App
- Just need access to private resources? → Remote Command Target
What all patterns share
- No inbound control-plane access — cloud-provider delivery or the in-environment Operator pushes to Workers; app-owned Container/Daemon receivers lease targeted work over outbound HTTPS. No VPN.
- Release control —
alien releaserecords a target release, and eligible deployments converge according to their policy. - Scoped telemetry — logs, metrics, and traces are collected per deployment under the telemetry contract the customer approved.
- Multi-cloud — the same stack can target AWS, GCP, Azure, Kubernetes, or restricted environments.