Where we lose
This site is published by the sgit project, which builds the platform it documents. That is a conflict of interest and it is stated at the top of every page rather than in a footer nobody reads. Here is what it means for how to read this, and where our approach is the wrong choice.
The conflict, plainly
We wrote the platform, commissioned the audit, and published the audit. That is three roles that would normally be three parties.
What makes it checkable rather than merely asserted:
- The repository is public. Every claim on this site can be verified against the tree, and several of them are claims about the tree being worse than its documentation says.
- The audit is published in full, as raw source documents, not summarised into a page we control the framing of.
- The numbers carry their provenance. Each one names what it was measured from and when. The measured page →
- The site's build fails if a generated page drifts from the data it was generated from. How →
None of that removes the conflict. It makes the conflict cheap to check, which is the most a participant can offer.
Where this approach loses
If you want a managed platform, use Lambda or Fargate
The trade here is explicitly more control, longer cold start. If your workload fits in a function and you do not want to think about substrate, a platform that hands you a whole EC2 instance and a self-terminate timer is strictly worse for you. The trade, in its own words →
If you need multi-node coordination today, this does not have it
Not partially. At all. A Stack is a defined concept with no implementation behind it.
If you need declarative infrastructure, there is none
No Terraform, no CloudFormation, no CDK, no drift detection. Provisioning is imperative Python. Defensible for programmatic provisioning; not defensible if your organisation's answer to “what is running” is a state file.
If you need artefacts in S3 or a vault, they do not arrive
Two of four sinks raise NotImplementedError. Today it is base64 inline with a 20 MB cap, or a local file.
If you need a cost model, we do not have one
We can tell you what a node costs to start and what the teardown defaults are. We cannot tell you what a workload costs, and the only artefact that looks like it can is a self-declared placeholder.
If active development matters to you, check the date
No commit since 24 July 2026. We do not know yet whether that is paused, finished or between phases, and we would rather say so than imply momentum we cannot evidence.
What would change our mind
- A measured throughput number that contradicts the container argument. Q2 is open precisely because we expect the answer to be more interesting than the claim.
- A second
Platformimplementation that turns out not to fit the ABC. That would mean the abstraction is an aspiration, and we would say so. - A third-party spec. The entry-point mechanism is architecturally supported and untested in the wild. If yours does not work, that is a finding and we want it.
How to argue with this site
Every source document is published raw at a stable path, every number names what it came from, and the whole site is in a public repository. If something here is wrong, the fastest route is an issue against the site repository naming the page and the claim. Open requests and their state are on the comms page, in public, updated every release.