Ephemeral compute · sixteen ready-to-launch specs · built for agents

Ephemeral environments in AWS,
one command away

SG/Compute launches an isolated EC2 environment, runs your work, and terminates it — by design, every time. Sixteen ready-to-launch specs — browsers, encrypted vaults, container runtimes, LLM inference, observability — each a typed manifest away from a running node, with a measured ~16-second boot, a generated CLI, and a self-destruct timer built in. Open source, early access, and looking for users and contributors.

Browse the sixteen specs → How it works → Get involved →

Launch, work, terminate

One command gives you a dedicated, isolated environment: a per-node API key is minted and written to SSM before launch (never reused), the instance boots with composed user-data, a two-phase health poll tells you the moment it is ready, and a self-destruct timer is armed from the start — halt means terminate, not stop. Around 50 seconds end to end, and you never have to remember to clean up.

# every spec gets the same generated CLI — sixteen specs, one surface
sg <spec> list · info · create · wait · health · connect · exec · delete · ami list|bake · cert

# the node terminates itself — default one hour, fractional supported
systemd-run --on-active={seconds}s /sbin/shutdown -h now
InstanceInitiatedShutdownBehavior=terminate   # halt means terminate

Adding a spec costs a manifest, a route class and a service — the CLI comes free, generated by Spec__CLI__Builder. The full lifecycle → · why 50 seconds is a fair trade for the isolation →

Two ephemeral layers, so nothing outlives its purpose

Ephemerality is the product, and it operates at two different lifetimes. Everything you run gets a fresh start, and everything you start gets torn down — enforced by mechanism, not by convention.

Layer 1 · per HTTP request

An ephemeral browser

Every call launches a fresh Playwright subprocess and a fresh Chromium, runs the declared step list, and tears both down in try/finally before returning. Zero cross-request state — and a CI guard fails the build if any raw browser.new_context( appears outside the one sanctioned factory.

lifetime: one request · milliseconds to seconds
Layer 2 · per node

An ephemeral EC2 instance

A per-node API key minted and written to SSM before launch, composed user-data, EC2 tags as the registry, a two-phase health poll — then systemd-run --on-active paired with InstanceInitiatedShutdownBehavior=terminate. Halt means terminate, not stop. Default one hour, everywhere.

lifetime: one hour by default · 0.1h to unbounded

Both layers in full, with stateful sessions, the watchdog, and the isolation table →

Batteries included: the CLI, the REPL, the sequence language, the UIs

This platform grew out of real operational need, and it shows in the tooling. Some of it is still rough around the edges — all of it is working code you can drive today.

generated CLIs

Sixteen specs, one CLI surface

Per-spec CLIs are generated, not written: the same ten verbs — list, create, wait, connect, exec, delete and friends — for every spec in the catalogue. Written once, uniform everywhere.

The spec system →
AWS toolkit

A deep AWS command surface

Over 71,000 lines of operator tooling: EC2 provisioning, IAM and credential management, AMI bake-and-verify, fleet sentinel commands — plus an interactive REPL/TUI for driving your environments live from the terminal.

Measured from the tree →
for agents

A 25-verb sequence language

Declare a step list, get back COMPLETED / FAILED / PARTIAL with every skipped step named and a full timings block. Plus stateful sessions, Prometheus metrics, and a self-describing /health/capabilities endpoint.

The machine surface →
built-in UIs

Web consoles out of the box

A capability-driven HTML console on every node, per-spec UIs, an agentic admin surface at /admin/*, and live VNC desktops for the headed-browser specs. Launch a node, open a browser, start working.

What you get on a node →

Sixteen ready-to-launch environments

A catalogue of pre-configured environments — the design brief called it “the simulated AWS Marketplace”. Nine stable and seven experimental specs, boot times from 15 seconds, every one a typed manifest with a stability rating and a measured boot time. Grouped by what they do for you:

FamilySpecsLines
browserplaywright, content_proxy, firefox, vnc, neko20,199
vaultvault_publish, vault_app19,943
observabilityelastic, prometheus, opensearch3,904
runtimedocker, podman2,757
llmlocal_claude, ollama2,437
networkmitmproxy1,448
toolopen_design773

Each spec is a working package — manifest, routes, service, CLI, tests, often a UI. And the catalogue is open: third-party specs can join via a PEP 621 entry point, no fork required. The full catalogue, one page per spec, generated from the data →

Three axioms, implemented with mechanisms behind them

Not aspirations — each one is enforced by working code you can point at.

axiom 1

Statelessness

Fresh browser process, fresh context, fresh page, per request — torn down in try/finally whatever happens. Cookies apply to the per-request context and are discarded with it.

How it is enforced →
axiom 2

Least privilege by declaration

The JavaScript allowlist is deny by default, exact match. An agent cannot evaluate anything until an operator populates the list. Nothing is permitted by omission.

The isolation boundaries →
axiom 3

Self-description

GET /health/capabilities is built at runtime by a detector that works out its own deployment target — laptop, CI, container, Lambda. The service tells you what it can do, live.

The machine surface →

Built fast, tested hard, measured honestly

Every number here was measured from the tree on 24 August 2026, at repo version v0.2.71 — that is the house rule: every number on this site is generated from data or carries the date it was measured.

4,785
tests passing, in 81 seconds
pytest tests/ci tests/unit
2,777
commits and 245 tags, in 100 days
16 Apr – 24 Jul 2026
~16s
measured EC2 boot to SSM-ready
24 runs, 11 May 2026
~50s
end to end: click to a dedicated environment with its own DNS name
the number that matters
16
registered specs — 9 stable, 7 experimental
from the manifests
1.27M
words of documentation, with a formal reality discipline
team/ + library/
25
verbs in the declarative sequence language
/sequence/execute
6
isolation boundaries, each with a mechanism behind it
per request, session, node

Every measured number, with its provenance → · and because measured means all of it, the full audit is published alongside →

The rough edges are published — and they are the way in

This is an early-access platform, and we publish exactly where it is thin rather than letting you find out. If you want to contribute, these are well-scoped, high-value places to start — each one is specified, argued for, and waiting for code.

up for grabs

Warm pools

Take the cold start from ~50 seconds to 5–15 by keeping a small pool ready. Specified in a 1,729-word brief with worked economics — the design is done and the code is yours to write.

The spec →
up for grabs

S3 and vault artefact sinks

The sink enum and the interfaces exist; inline and local-file already work. Wiring S3 with presigned URLs — and vault writes, already implemented twice at the spec layer — is a clean, contained contribution.

The gap, precisely →
up for grabs

Uniform create_node

The uniform CLI covers all sixteen specs; the control-plane API covers three so far. Extending EC2__Platform to the rest is repetitive, satisfying work with a working pattern to copy.

Where it stands →
quick wins

Seven fixes, in order of value

The roadmap lists seven concrete fixes — the first one is literally four characters — plus eight open questions we publish unresolved, because honest unknowns attract better collaborators than false certainty.

The roadmap →

Use it, break it, build on it

If you need ephemeral environments in AWS — for browser automation, agent workloads, container experiments, or LLM inference that cleans up after itself — pick a spec and read the machine surface: the whole platform is driven over a documented HTTP API and a generated CLI, so an agent can use it as easily as a person.

If you want to contribute — the platform is Apache-2.0, the specs are extensible from your own repository via entry points, and the roadmap names exactly what is wanted next. Say hello on the comms page or via GitHub, and tell us what you would launch.

One thing to know before you discover it

sg-compute.sgit.ai is this site: documentation. sg-compute.sgraph.ai is a live Route 53 zone serving per-node DNS as <stack-name>.sg-compute.<zone> — every node you launch gets a stable DNS name under it. Same label, different TLD, stated here deliberately. The decision in full →

Where to go next

Eight pages, in reading order.

start here

What it actually is

The two ephemeral layers, sessions and the engineering that shaped them, the watchdog, and how artefacts come back.

Read →
the platform

The spec catalogue

Sixteen specs, three generalisation mechanisms, and the entry-point contract for specs that live in your repository.

Read →
the argument

Serverless for agents

“We are competing for the agent-deployment market.” The cold-start ladder against the measured benchmarks.

Read →
for machines

The machine surface

Two API surfaces, the 25-verb sequence language, and how auth actually works, documented precisely.

Read →
boundaries

Isolation, stated precisely

Six isolation boundaries with the mechanism behind each, and the one trade-off published rather than hidden.

Read →
credibility

The measured numbers

Boot benchmarks including the capacity failures, test counts, and the commit history — everything checkable.

Read →
honesty

What ships today

The shipped surface in full — and the gaps, published unsoftened, because that is how this family of sites earns trust.

Read →
get involved

Roadmap & how to help

Seven fixes in order of value, eight build-fresh items, and eight open questions — the contributor's map of the territory.

Read →