Skip to main content

​
The headline

Two services shipped to production today: AIRLOCK — the cross-org auth gateway. One BetterAuth backend. One sign-in page at airlock.devarno.cloud. One session cookie scoped to .devarno.cloud. Email-password, GitHub OAuth, and (when their env vars are set) Google/Discord — all from one place. Running on Railway inside the DEVARNO • CLOUD project with its own isolated Postgres database. HATCH — the airlock control console. Seven Mars-themed views covering users, sessions, audit log, organisations, API keys, agents, subscriptions. A dense ops dashboard with sparklines, area charts, donuts, and a 7×24 login heatmap — all pure server-rendered SVG, zero client-side chart library, 88 kB First Load JS. Running on Vercel at hatch.devarno.cloud with full SSO to airlock.

​
Why this is a platform moment

Before today: every devarno-cloud dashboard had to roll its own auth, or not have auth at all. Family-hub had its own BetterAuth instance. Hubble had a custom tier system. Casa was going to have yet another. Choco was building its own sub-auth. Five services, five auth setups, five places to update when something changes. After today: one place. Airlock is the identity provider for every *.devarno.cloud service that wants SSO. The integration cost is ~40 lines of middleware.ts — forward the cookie to /api/auth/get-session, read the user back, gate by role. No OAuth client registration. No user database. No login page. No session store. The consumer adds a subdomain on .devarno.cloud, wires the middleware, and ships. Hubble and hatch are the proof points — same pattern, different views. The next dashboard will take an afternoon.

​
The ecosystem model

  airlock.devarno.cloud    ← BetterAuth, Postgres, sign-in UI
         │
         │   .devarno.cloud session cookie
         │
    ┌────┼────────────┬─────────────┬──────────────┐
    ▼    ▼            ▼             ▼              ▼
  hatch hubble    casa (soon)    future-tool   future-dashboard
   /    /           /                /             /
  admin read-only  family         whatever      whatever
  ops   obs         hub            comes next    comes after
Every box on the bottom is a Next.js app with 40 lines of middleware and no auth code. Every new box that goes up is free to build.

​
Messaging angles

For the engineering audience:
  • “Auth is no longer a per-project concern. It’s a platform capability.”
  • “SSO in 40 lines of middleware, with no client registration and no user table.”
  • “The Mars theme goes with it — one copy-paste and your new dashboard looks like hubble and hatch on day one.”
  • “Seven distinct production blockers, all documented as findings. The next service pays the cost once, and it’s frozen.”
For the strategic audience:
  • “Platform capabilities compound. Five auth setups become one. Every new dashboard is a marginal cost, not a new project.”
  • “Cross-org is a moat. Every dashboard shares users, roles, audit logs, and sessions. The more we ship, the more valuable each becomes.”
  • “Hatch is the first admin console. The platform now triages itself.”
For the show-and-tell audience (LinkedIn / show HN / design journal):
  • “Built a full admin dashboard with 4 chart types, 0 chart libraries, 0 bytes of client JS.”
  • “Cross-subdomain SSO via a single cookie on .devarno.cloud — no OIDC redirect dance.”
  • “The entire deploy sequence, including 7 production blockers, is now an A2A prompt ops runbook. Next service ships in an afternoon.”

​
Design journal hooks

  1. “Why I wrote my charts instead of installing Recharts” — SVG primitives vs chart libraries, bundle impact, the bundle-size table from the learning. Includes the four chart component files as copy-pasteable snippets.
  2. “The Hono BetterAuth bug that cost me an hour and two learnings” — the Set-Cookie collapse + CORS loss story. Walkthrough of the broken pattern, the failure mode screenshots, and the one-line fix.
  3. “How I accidentally built my auth service inside the wrong repo” — airlock was born in choco-hq, spent a week there, then got surgically extracted into its own submodule. The migration doctrine. Includes the submodule add sequence.
  4. “7 blockers between a clean Dockerfile and a live Railway service” — each blocker as a mini-post with the symptom, the root cause, the fix, and the doctrine reference. Reads as a disaster checklist.

​
What to ship as follow-up content

  • Hatch screenshot — the /status page with all 8 hero cards, the area chart, the heatmap, and the event ticker populated. (Needs some traffic to be visually interesting.)
  • Before/after bundle table — the 0-byte chart library win, formatted as a comparison card.
  • Cross-subdomain SSO diagram — the box-and-arrow graphic showing airlock at the top and multiple dashboards consuming its cookie.
  • The airlock sign-in page — Mars theme, GitHub OAuth button, “cross-subdomain SSO” footer. Single screenshot, high signal.

​
Next moves

  1. Migrate family-hub’s auth onto airlock (casa campaign phase 3)
  2. Add the POST /api/auth/bootstrap-admin endpoint to skip the manual psql promotion step
  3. Wire the OAuth provider plugin for external app registration (MCP clients, partner apps)
  4. Build a keys admin view on hatch for managing the OAuth client registry
  5. Document the consumer integration as a one-page runbook: “How to add SSO to a new devarno-cloud subdomain”