Sign in
You cannot. There is no sign-in here yet — no realm has issued a token, no portal holds a session, and no account has ever been created against this system.
A form on this page would work. It would take an address, show a spinner, and say something reassuring. It would also be the first lie on a site whose entire argument is that a claim carries the rung it actually stands on — so instead this page tells you what is missing, and the table below is generated from the same file the status page reads.
What a sign-in has to walk through
Signing in is not one thing. It is a realm that issues a token, a server that verifies it without trusting what the token says about itself, and a resolver that turns a subject into a principal and an organization. Three of those are built and tested on a developer machine. The two that would put a door on this page are not.
| Part | Rung | What that means here |
|---|---|---|
| Keycloak realm on Fly | spec | Ruled (R4) to Fly iad, database on PlanetScale. Not provisioned. |
| Portal sign-in (BFF, server session) | spec | No portal exists. |
| OIDC token verification (RS256, pinned) | local | Algorithm pinned, never read from the token; iat required, crit refused, forced JWKS refresh rate-capped. No realm has issued it a real token. |
| OIDC subject → principal → organization | local | Resolvers are implemented and tested, and idempotent under CONCURRENCY as well as in sequence. The mechanism CHANGED this round: 0013 used a PostgreSQL advisory lock, which Hyperdrive lists as unsupported — correct PostgreSQL that the production wire refuses. 0015 serializes on the unique partial index instead. No Keycloak has issued a real token to them. |
| Organizations resolved by stable IdP id | local | Alias is for selection only. A token carrying aliases without ids is refused as a realm misconfiguration. |
The full capability table · Why the subject, the tenant and the machine are three identities
Why the parts that exist are not enough
Token verification is implemented and pinned — the algorithm is fixed in code and never read from the token, which is the defect that has broken more JWT deployments than any other. The subject-to-principal resolver is implemented and idempotent under concurrency, so two simultaneous first logins resolve to one principal rather than two.
Both of those have been exercised only against tokens this repository minted for its own tests. No Keycloak has issued a real token to them. Code that verifies a signature correctly against a key it generated is code that has not yet met the internet, and calling that "sign-in works" is the exact move this site exists to refuse.
The missing pieces are a provisioned realm — ruled to Fly iad, not built — and the portal itself, which is the server that would hold your session so a token never reaches the browser. Until both exist, the honest rung is the one printed above.
What happens when this page becomes a door
Nothing on this page is hand-maintained. The rung beside Sign in in
the header, the note in the footer of every page, and the table above are
all written from status.json by
tools/render-status.mjs, and a release gate fails if any page
disagrees with it.
So the day the portal is real, this page changes because the capability changed — not because someone remembered to come back and edit seven files. That is the only version of this promise worth making.
In the meantime, the thing that does exist and does run is Super (CD) — the local-first cockpit, on hardware you already own. It needs no account here, which is rather the point: a machine we rent you proves nothing that a machine you own does not prove better.