What ships today
A lot ships. This page lists the working surface first, then applies the platform's own governing rule — “briefs are aspirations, not facts” — to name what is not built yet. Both halves matter: the first tells you what you can use today, the second tells you exactly where a contribution lands.
Code wins. Where the README, capabilities.json, the reality document and the tree disagree, the tree is right. Every claim on this page was measured from the tree on 24 August 2026 at repo version v0.2.71, not read from documentation.
The working surface
What you can drive today, all of it in the tree and under test:
| Area | Shipped |
|---|---|
| Specs | Sixteen registered specs across seven families — browsers, vaults, container runtimes, LLM inference, observability, network, tools — each a working package with a typed manifest, routes, a service, tests and often a UI. Nine stable, seven experimental, boot times from 15 seconds. |
| Lifecycle | One-command node launch with a per-node API key minted to SSM before boot, composed user-data, a two-phase health poll, and guaranteed teardown — systemd-run self-destruct plus InstanceInitiatedShutdownBehavior=terminate. Measured ~16s EC2 boot to SSM-ready; ~50s end to end. |
| CLI | A generated, uniform ten-verb CLI for every spec (list · info · create · wait · health · connect · exec · delete · ami · cert), plus a 71,000-line operator toolkit — AWS provisioning, IAM and credentials, fleet sentinel commands, and an interactive REPL/TUI. |
| API | Two FastAPI applications: a browser-automation data plane (navigate, click, fill, screenshot, inspect, a 25-verb declarative sequence language, stateful sessions) and an SG/Compute control plane (specs, nodes, pods, logs, stats) with per-spec routes discovered by convention. |
| Isolation | Six boundaries, each with a mechanism: fresh browser per request, dedicated thread per session, per-node keys never reused, a deny-by-default JS allowlist, sidecar-only networking, per-request cookie scope. |
| Observability | Prometheus metrics on every node, per-call timing blocks, a capability-driven HTML console, an agentic admin surface, and GET /health/capabilities built live at runtime. |
| Quality | 4,785 tests passing in 81 seconds, digest-first multi-arch CI, an AMI bake-and-verify design, and 1.27 million words of documentation under a formal reality discipline. |
The ledger: not built yet — and where you come in
Eight things this platform is described as having, or is assumed to have, and does not have yet. Published unsoftened, because a contributor deserves a precise map — every item below is a well-scoped piece of work with the design already argued for.
1. There are no warm pools
Warm pools are central to the serverless pitch — they are the rung of the cold-start ladder that takes a node from 30–60 seconds to 5–15. They are specified in a 1,729-word brief with worked economics (“a pool of 3–5 t3.small instances at ~$0.02/hour each is roughly $1–3/day”).
Zero implementation. Grep across the tree finds IDLE_TEARDOWN_THRESHOLD in the edge reconciler and nothing else. The ladder rung is a design, not a feature.
2. There are no multi-node stacks
The taxonomy is explicit: a Node is one compute instance, a Pod is a container on a node, a Spec is a workload definition, and a Stack is 2+ coordinated Nodes. That last definition is the whole point of having the word.
Routes__Compute__Stacks returns a list. Cli__Compute__Stack is unwired. There is no multi-node orchestration anywhere in the tree.
And the word is used anyway: thirteen CLI help strings in one file say “Ephemeral X EC2 stacks” about a single instance — against a naming brief that said, in bold, “Reserve ‘stack’ for this. Do not use it for single nodes.” Either build the thing or retire the word: Q5.
3. create_node covers 3 of 16 specs
EC2__Platform._service_for raises NotImplementedError for anything but docker, podman and vnc. The other thirteen specs create nodes through their own CLI and service paths, not the control-plane API.
The uniform CLI is real; the uniform API is not. Every spec page states this for itself — here it is on ollama, for instance — because three of sixteen is a real limitation and hiding it produces support questions rather than preventing them.
4. Artefact sinks: two of four
Enum__Artefact__Sink declares VAULT, INLINE, LOCAL_FILE, S3. Both write_bytes_to_vault and write_bytes_to_s3 raise NotImplementedError.
Today, an artefact comes back as base64 inline in the JSON body (20 MB cap), as raw PNG bytes from the screenshot endpoint, or as a local file path in development. No S3. No presigned URLs. No vault writes.
This one is worth naming loudly because two specs exist whose declared capability is literally vault-writes. The capability is implemented twice at the spec layer and missing at the platform layer — Q4.
5. Non-EC2 platforms do not exist
'ec2' | 'k8s' | 'gcp' | 'local' is a comment in the Platform ABC. Only EC2__Platform is implemented. An abstract base class with one implementation has not been tested as an abstraction — Q3, where the honest observation is that local would be the cheapest proof and would also make the test suite runnable without AWS.
6. There is no cost model
The only cost artefact in the tree is a dashboard tracker whose own header says it: “placeholder cost tracker. Shows mocked cost estimate… Real cost calculation is its own brief.” Its rate table is five hardcoded t3 prices. That brief does not exist.
So this site publishes no cost figure from it. What can honestly be said about cost is: here is what a node costs to start (measured), here is what it costs to hold (the teardown defaults), and the per-workload model is not built.
7. Throughput has never been measured
“A single container can serve hundreds of parallel requests trivially” is a load-bearing claim in the Lambda comparison. It is argued and never measured. There are no load tests anywhere in the repository, and no aggregated latency dataset either — /sequence/execute emits a full timings block per call and nothing aggregates them, so there is no p50 or p95 to publish.
It is also the claim most likely to be wrong in an interesting way: every browser request launches a fresh Chromium process, so the ceiling here is memory, not the web framework. Q2.
8. The AMI bake pipeline is dead
bake-ami.yml is a genuinely good two-phase process — install from scratch, health and smoke checks, clean, snapshot, relaunch from the baked AMI and re-verify, then tag healthy or unhealthy. That is a better AMI process than most infrastructure teams run, and it is cited as a maturity signal.
It invokes a binary called sg-play sixteen times. sg-play is defined nowhere — not in pyproject.toml, not in scripts/. The whole workflow is currently not runnable as written. It is a one-line problem hiding an entire pipeline, and it is fix F3.
And one number this site will not print
Image sizes. They are not recorded anywhere in either repository and not derivable without a build, so there is no honest number to give. One docker images line would close it; until someone runs it, the field stays empty rather than estimated.
| Image | Base | Role | Size |
|---|---|---|---|
diniscruz/sg-playwright | mcr.microsoft.com/playwright/python:v1.58.0-noble | the data plane, port 8000 | not measured |
diniscruz/sg-playwright-vnc | the above, by digest | adds Xvfb, openbox, x11vnc, novnc, websockify, supervisord | not measured |
diniscruz/sg-host-control | python:3.12-alpine | the pod sidecar | not measured |
The four sources of truth that disagree with the code
Every one of these went stale for the same reason: it was written once, by hand. That is why this site generates every page that describes the code from data, and why CI fails if a generated page drifts. A documentation site for this platform that is hand-maintained would be the fifth.
| Artefact | Says | Reality |
|---|---|---|
capabilities.json | v0.1.29 | v0.2.71 — 42 minor versions behind. COPY'd into the image and served at /admin/capabilities. The repo's own docs say not to read it |
| The reality-document index | v0.2.30, 17 May 2026 | v0.2.71. The discipline is right and the maintenance did not happen — 41 versions behind |
README.md | “Phase 0 in progress — repo skeleton, Dockerfile, CI workflow scaffolding” | 217,266 lines of Python, 7,110 tests. It also documents a package directory that does not exist, cites a base image tag the Dockerfile does not pin, and claims a Lambda Web Adapter the Dockerfile header explicitly says is absent |
sg_compute/version | v0.1.162 | Read by nothing. Grep for any code reading it returns zero hits |
The README is the single most misleading artefact in the repository, and no word of this site was written from it. It is fix F6: half a day to rewrite from the tree.
The maturity claim, and the four places it is overstated
The claim being audited is “a VERY mature ephemeral compute platform.” It holds — the measurements are here — and a site that repeats it without these four qualifications would be caught by anyone who clones the repository.
There is no static analysis. None.
No mypy, ruff, flake8, pylint, black, isort, setup.cfg or tox.ini anywhere, and no such configuration in pyproject.toml. Type safety is enforced at runtime via Type_Safe, present in 1,333 of 3,127 package files (42.6%). That is a real and defensible architectural choice — runtime validation catches things static analysis cannot — but it is not a substitute, and 57% of files have neither.
tests/ci/. One of them has never worked — the four-character bug.CI runs 67.4% of the tests
4,793 of 7,110 collectible tests. The 2,317 outside CI include 1,952 that test the new sg_compute and sg_compute_specs trees — which is to say, the parts the rename is building.
And it shows. Six of the seven collection errors are in the un-CI'd suites: four genuine circular imports, one missing module, one stale import path. Adding those two suites to CI would surface all six immediately, and it is one workflow edit. The full breakdown by path →
This is the highest-value change available in the repository — fix F2.There is no infrastructure-as-code
No Terraform, CloudFormation, CDK or SAM templates anywhere. Provisioning is imperative Python over osbot-aws. Defensible for a platform whose whole point is programmatic provisioning — but it means no declarative description of the AWS footprint, no plan/apply, and no drift detection.
Four sources of truth disagree with the code
Named above. The site's stated policy is the one the repo's own dev pack already reached: code wins.
The verdict, published as written
Mature where it counts, thin where the repo has not looked.
4,785 tests passing in 81 seconds, digest-first multi-arch CI, AMI bake-and-verify, 1.27 million words of documentation with a formal reality discipline, and operational hardening written from real incidents.
And: no linter, no type-checker, a third of the tests outside CI hiding six real breakages, no IaC, and four sources of truth that disagree with the code.
That paragraph is worth more to this platform's credibility than any feature list. It is also about five days of work away from being a much better paragraph: the seven fixes are listed, in order of value, and the first one is four characters.