The catalogue: sixteen ready-to-launch environments
The 30 April naming brief called it “the simulated AWS Marketplace: a catalogue of pre-configured, ready-to-launch environments.” That is what this is. Seventeen directories, 16 registered — 9 stable, 7 experimental — each a working package with a typed manifest, its own routes, service, CLI, schemas and tests. This page is generated from data/specs.json and CI fails if it drifts.
Surveyed 2026-08-24 against repo v0.2.71, from sg_compute_specs/*/manifest.py. Every total on this page is computed from the per-spec rows and cross-checked against the survey's own summary blocks — a disagreement fails the build rather than publishing a number nobody can reproduce.
Why this page justifies the rename
Playwright is 1 of 16 registered specs and 16.8% of spec code. Counting the generic compute core alongside the specs, 71.5% of the new codebase is not browser code. The repository is named after one row in this table. The rename, scored against its own nine acceptance criteria →
By family — read this one first
The alphabetical list is below, but the family view is the one that carries the argument. It is a single row that makes the case:
| Family | Specs | Lines |
|---|---|---|
| browser | playwright, content_proxy, firefox, vnc, neko | 20,199 |
| vault | vault_publish, vault_app | 19,943 |
| observability | elastic, prometheus, opensearch | 3,904 |
| runtime | docker, podman | 2,757 |
| llm | local_claude, ollama | 2,437 |
| network | mitmproxy | 1,448 |
| tool | open_design | 773 |
| infra | sg_edge | 9,108 |
Vault specs are within 300 lines of browser specs. That row is the clearest possible statement that this is not a browser service — and it points at the integration the rest of the estate wants. It also explains why the artefact-sink gap matters more than it looks: two specs exist whose declared capability is vault-writes, while the platform's own generic vault sink raises NotImplementedError. The capability exists at the spec layer and not at the platform layer.
browser — 5 specs, 20,199 lines
Browsers and the proxies in front of them — the family the repository is named after, and 28.5% of the new codebase.
playwright
The spec the repository is named after, and 1 of 16. A stateless browser data plane: every call launches a fresh Playwright subprocess and Chromium, r…
stablecontent_proxy
A content-inspecting proxy in front of the browser. Ten-minute typical boot — joint slowest in the catalogue with docker.
experimentalfirefox
A second browser engine behind the same proxy surface.
experimentalvnc
A headed browser on an X display, reachable over VNC. One of only three specs create_node can provision through the control-plane API.
stableneko
A browser you can embed in an iframe and share — the collaborative end of the browser family.
stablevault — 2 specs, 19,943 lines
Vault publishing and vault applications. Within 300 lines of the browser family, which is the single clearest statement that this is not a browser service.
vault_publish
The largest spec in the tree. Publishes vault content and routes it on a subdomain — one of the two specs whose declared capability is literally vault…
experimentalvault_app
Runs a vault as an application. The one spec that supports fractional teardown (max_hours = 0.1, six minutes) and defaults to spot instances.
experimentalobservability — 3 specs, 3,904 lines
Metrics and search backends for the platform's own telemetry.
elastic
An Elasticsearch node for the observability family.
stableprometheus
Prometheus, paired with the /metrics endpoint every data-plane node already exposes.
stableopensearch
OpenSearch, the third of the observability family and a remote-write target for the observability service.
stableruntime — 2 specs, 2,757 lines
General container runtimes — and, with vnc, the only specs the control-plane API can provision.
docker
A general container runtime node. One of the three specs create_node supports.
stablepodman
A rootless container runtime alongside docker. One of the three specs create_node supports.
stablellm — 2 specs, 2,437 lines
Model inference, local and hosted-on-your-own-node.
local_claude
A node that runs Claude Code locally against a workspace, provisioned by the Claude_Code__Firstboot user-data section.
experimentalollama
Local model inference, provisioned by the Ollama and NVIDIA_Container_Toolkit user-data sections on a GPU instance.
experimentalnetwork — 1 spec, 1,448 lines
The proxy sidecar the browser family routes through.
tool — 1 spec, 773 lines
Application specs that are neither browser nor runtime.
infra — 1 spec, 9,108 lines
Platform infrastructure that lives in the spec tree without being a registered spec.
All 17, alphabetically
| Spec | Stability | Capabilities | Boot | Lines | Family | create_node |
|---|---|---|---|---|---|---|
| content_proxy | experimental | mitm-proxy | 600s | 4,971 | browser | no |
| docker | stable | container-runtime | 600s | 1,558 | runtime | yes |
| elastic | stable | metrics | 180s | 1,372 | observability | no |
| firefox | experimental | mitm-proxy | 90s | 1,992 | browser | no |
| local_claude | experimental | llm-inference | 180s | 1,498 | llm | no |
| mitmproxy | stable | mitm-proxy | 15s | 1,448 | network | no |
| neko | stable | iframe-embed | 120s | 1,180 | browser | no |
| ollama | experimental | llm-inference | 120s | 939 | llm | no |
| open_design | experimental | design-tool | 480s | 773 | tool | no |
| opensearch | stable | metrics | 180s | 1,221 | observability | no |
| playwright | stable | browser-automation | 30s | 10,180 | browser | no |
| podman | stable | container-runtime | 120s | 1,199 | runtime | yes |
| prometheus | stable | metrics | 120s | 1,311 | observability | no |
| sg_edge | unregistered | — unregistered — | — | 9,108 | infra | n/a |
| vault_app | experimental | vault-writes | 45s | 8,261 | vault | no |
| vault_publish | experimental | vault-writes, subdomain-routing | 45s | 11,682 | vault | no |
| vnc | stable | mitm-proxy | 120s | 1,876 | browser | yes |
Boot is boot_seconds_typical from each manifest — 15 seconds to 600 seconds, a 40× range, which is itself the argument for carrying it as a manifest field rather than a footnote. Spec ids are API identifiers and are not prettified.
The uniform CLI is real; the uniform API is not. create_node covers 3 of 16 specs — EC2__Platform._service_for raises NotImplementedError for anything but docker, podman and vnc. The other thirteen create nodes through their own CLI and service paths, not the control-plane API. Every spec page below states this for itself.
Three mechanisms, and none of them is capabilities.json
What makes this a platform rather than a service is that adding a spec costs a manifest, a route class and a service — and the CLI comes free.
manifest.py per spec
typed Schema__Spec__Manifest__Entry — the registry
Spec__Routes__Loader
convention-based route discovery: spec_id 'docker' -> sg_compute_specs.docker.api.routes.Routes__Docker__Stack. 'Specs without a route class are silently skipped.'
Spec__CLI__Builder
generates the same 10 verbs for every spec: list, info, create, wait, health, connect, exec, delete, ami list|bake, cert
Spec__Loader entry points
PEP 621 entry-point discovery, group 'sg_compute.specs' — third-party specs architecturally supported, untested in the wild
What is not the mechanism. Frozen at v0.1.29 while the repo is at v0.2.71 (42 minor versions). COPY'd into the image and served at /admin/capabilities. The repo's own docs say not to read it: 'The UI reads GET /health/capabilities (the live Schema__Service__Capabilities, populated by Capability__Detector) — never the stale capabilities.json.'
The live mechanism is Capability__Detector, which detects the deployment target from env vars (laptop | ci | claude_web | container | lambda) and builds capabilities at runtime. The three axioms that stale file names — statelessness, least-privilege-by-declaration, self-description — are good, and unlike the file that names them they are actually implemented. They are rescued onto the front page.
Specs that live in your repository
Spec__Loader already supports PEP 621 entry-point discovery under the group sg_compute.specs, alongside the in-repo walk. A spec in your own package, declaring that entry point, joins this catalogue with no change to this repository.
Stated as a claim, not a feature. Third-party specs are architecturally supported and untested in the wild — nobody outside the repository has published one. That is an invitation rather than a guarantee, and if you try it we would like to hear what broke.
One design note worth publishing because it cuts both ways: “specs without a route class are silently skipped.” Convenient during development; a silent-failure mode in production. A spec that loses its route class disappears from the API with no error.