Voids

A brick is the artifact. A void is the artifact placed onto a CAP and serving traffic. The two are not interchangeable. A brick on your disk is inert. A void is a running process with a public URL, a slug, an owner, and a lease.

Every void is created from exactly one brick and pinned to one slug. The slug is a stable, short, human-pronounceable identifier the fleet generates on first deploy, like lazy-fox orquiet-harbor. From that moment the void answers HTTPS at<slug>.app.lilylabs.io until you kill it or the fleet evicts it.

What the fleet knows, and what it does not

From the fleet's perspective a void is stateless. The CAP runs your brick in a Wasmtime sandbox, routes HTTPS to it, and forwards logs. It does not back up your in-memory state, it does not snapshot files you write to /tmp, and it does not replicate anything to other CAPs. If your void crashes or moves, anything the brick held in memory is gone.

Persistence is your concern. Talk to an external database, an object store, or a managed cache from inside the brick over outbound HTTP. The fleet provides the runtime and the URL; it does not provide durability.

Lifecycle

A void moves through three states. Pending while Raptor selects a CAP and the brick is pushed. Live once the CAP has loaded the module and the first health probe succeeds. Stopped after lly void kill or after an eviction. There is no paused state. A void is either taking traffic or it is gone.

Inactive voids are subject to eviction. The eviction policy is a fleet-wide knob set by operators, not a per-void setting, and it considers request rate, CPU time, and the age of the placement. You cannot opt out, but you can keep a void warm by sending it traffic. A killed or evicted void leaves the slug reserved to its owner for a short grace window so a redeploy lands on the same URL.

Listing and inspecting voids

lly void list shows every placement owned by the signed-in account across all CAPs. The slug is the only identifier you ever need; the underlying CAP, brick hash, and lease are bookkeeping.

Slugs, URLs, and ownership

Slugs are owned by the account that ran lly void deploy. Two accounts cannot hold the same slug, and a slug never resolves to a void you do not own. Custom domains and pinned slugs are handled by the platform dashboard, not the CLI.

TLS is terminated at the CAP. Certificates are issued automatically for*.app.lilylabs.io; the brick sees plain HTTP on the inside. Outbound traffic from the void uses the CAP's IP and is unrestricted.

Where to go next

See lly void for the full command surface, includingdeploy, logs, and kill with all their flags. Thearchitecture page walks through how Raptor decides which CAP runs your void, and Bricks covers the bundle that gets deployed in the first place.