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. The control plane is a broker: it hands the browser a short-lived pairing link to that person's own assistant, then steps out of the way — it never sits in the middle of the conversation.

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, default-deny networking. 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.