Ember
Every job gets its own tiny virtual machine. Idle ones sleep as snapshots; disk to answering queries in 78 ms. Built from scratch on this cluster.
78 ms best wake · ~22 ms VM restore · recorded runs · source
What it runs
task run once
A fresh VM per job, no network device, destroyed after. The guest reaches exactly one thing: its channel to the host daemon.
session sleep & wake
An agent's sandbox. Banked between turns, relit with memory, processes and open files intact; snapshots offload to S3, so a session survives its node.
serving always answering
A warm HTTP endpoint. Requests go through a node-local Envoy straight into the VM; the control plane can restart mid-request and traffic notices nothing.
stateful a database that sleeps
Postgres banked to disk when idle, woken by the next connection. Zero compute while asleep, and the disk outlives the VM.
composite wakes as one
Several VMs, one private network, banked and relit as a unit. A scratch Kubernetes cluster ran as one workload.
isolation hostile by default
No VM, and nothing it was restored from, is ever shared between two customers. Task and session guests have no network device at all. Quotas fail closed: quota 0 is a hard stop at submit.
the moving parts how it fits together
An Elixir control plane manages Firecracker VM lifecycle on Kubernetes; a Go daemon on each node owns the machines. Workloads are declared as Kubernetes custom resources.
POST /v1/workloads/:name/tasks → 202 + a task_id POST /v1/workloads/:name/sessions → a session_id, then /v1/sessions/:id/invoke serving → plain HTTP, straight into the VM