The irritation
Access across multiple Delphi experiences becomes fragile when entitlements, tenants, and user mappings are maintained as disconnected manual lists.
ProductBuildingIn development · rolling out
Delphi Auth
A multi-tenant access-orchestration layer for giving the right users the right Delphi experiences without hand-maintained access lists.
- Current state
- Building — In development · rolling out
- Jack’s role
- Product architecture, Authentication design, Full-stack engineering
- Find it in the workshop
- Systems & Maps Lab · Access-routing console
Built because…
The real build story.
What I built
I built a Cloudflare-based orchestration layer with tenant-aware access rules, an administrative interface, and durable records for the identities it coordinates.
The hard part
Authentication work has to fail closed while keeping tenant boundaries, access changes, and recovery understandable to the people operating the system.
Under the casing
Proof, not decoration.
Build evidence02 items
- Tenant-aware access records and administrative workflows
- A Cloudflare Worker, Hono, React, Vite, and D1 application shape
- Cloudflare Workers
- Hono
- React
- Vite
- D1
- Multi-tenant access
Scope of work
What I owned.
- Product architecture
- Authentication design
- Full-stack engineering
No victory-lap math
Outcome and lesson.
Where it landed
Delphi Auth is in development and rolling out. Public demonstrations use synthetic tenants and records rather than client or account data.
What stayed
Identity systems should keep their authority narrow. Orchestration is safer when the application owns only the access decisions it truly needs to make.
This project has a physical address.
In the playable workshop, Delphi Auth lives in the Systems & Maps Lab as a access-routing console. You can inspect it without unlocking anything.