sg-compute.sgit.ai / specs / podman

podman

A rootless container runtime alongside docker. One of the three specs create_node supports.

Stability
stable
Capabilities
container-runtime
Typical boot
120s — boot_seconds_typical, from the manifest
Size
1,199 lines — 2.0% of spec code
Family
runtime — alongside docker
create_node
yes
Measured
2026-08-24, against repo v0.2.71

Provisionable through the control-plane API. podman is one of the 3 specs EC2__Platform._service_for knows how to build, so POST /api/nodes and sg podman create both work.

The CLI, which nobody wrote

Per-spec CLIs are generated, not written. Spec__CLI__Builder registers the same verb set for every registered spec, so podman gets its command surface from the same code that gives every other spec theirs:

# the uniform verb set, for every registered spec
list · info · create · wait · health · connect · exec · delete · ami list|bake · cert

# so, for this one
sg podman create --max-hours 1
sg podman wait
sg podman health
sg podman delete

This is the strongest single argument that the thing is a platform rather than a service: adding a spec costs a manifest, a route class and a service — the CLI comes free. The three mechanisms →

What a node of this spec does

Every spec rides the same node lifecycle: a per-node API key minted and written to SSM before launch, composed user-data sections, EC2 tags as the registry, a two-phase health poll, then teardown. Teardown means terminate, not stop — systemd-run --on-active paired with InstanceInitiatedShutdownBehavior=terminate, on a default one-hour timer.

The full node lifecycle, step by step →