Architecture

You don't need this page to use OpenCrane — but if you'd like to see how the pieces fit together, here's the shape of the system in three pictures.

The big picture

You run one control plane. From it you hand out an isolated assistant to each person, and you configure the shared platform planes those assistants draw on.

One login, then a private connection

A person signs in once. From then on, the control plane's identity-routing proxy connects them to their own assistant: it checks the session and forwards the connection to that person's pod. There's no second login, no link to copy, and nothing for the browser to hold — revoke the session and the next connection stops.

Access is deny-by-default

A new assistant can chat, but it can't reach any skill, tool, or knowledge until you grant it — per person, team, or department.

→ Learn how in Control access, Share skills, Manage tools, and Organizational knowledge.

Built identity-first

Every arrow between these pieces is an authenticated, scoped, short-lived credential exchange — never a shared secret. People sign in with OIDC; assistants use audience-bound tokens that expire in minutes; a tool's real credentials are injected server-side and never reach an assistant or a browser. That's what makes instant, per-person revocation possible.

Isolation

Each assistant is walled off from every other — separate storage, separate identity, and default-deny networking keyed on cryptographic identity (Cilium + SPIFFE), so one customer's silo can never reach another's. See Identity & network isolation for the who-can-talk-to-whom rules. If you ever need to run completely separate OpenCrane instances in one cluster (say, several customers side by side), see Running multiple instances — most deployments never need it.