Containers can now keep state. Give a container persistent storage and each replica gets its own durable volume, mounted where you say:

const db = new alien.Container("db")
  .code({ type: "image", image: "ghcr.io/acme/db:v1" })
  .replicas(3)
  .persistentStorage("20Gi", { mountPath: "/var/lib/data" })
  .port(5432)
  .permissions("execution")
  .build()

Each replica has a stable identity — db-0, db-1, db-2 — and its volume follows that identity. Restarts, upgrades, and machine replacement all reattach the same disk to the same replica. Peers find each other by name, so clustered software that expects stable members just works.

Replicas are placed across availability zones, and each volume is provisioned in the right zone for its replica. Losing a zone loses one member, not the dataset.

This is the capability that databases, queues, and durable-execution engines need — the class of software that previously meant hand-rolled StatefulSets, PVCs, and an operator per product. We've been running a distributed durable-execution engine and a Postgres connection pooler on it in real customer-style deployments: journals survive restarts, in-flight work completes through rolling updates.

• Durable volumes — EBS and equivalents on each cloud, kept through every kind of replacement
• Stable ordinals — predictable names for clustering and peer discovery
• Zone-aware placement — replicas and their disks spread across failure domains

Read the docs →