Reference

Sidera architecture

Sidera is built around one rule: the control plane decides who is allowed to do what, but it never touches a file's actual bytes. Every byte that moves, moves directly between the machine that has it and the machine that wants it — over a separate, mutually-authenticated connection the control plane merely authorized.

The big picture

Four kinds of process make up a working Sidera deployment, and only one of them ever stores or forwards file content.

Purple lines carry actual file bytes; black lines carry only authorization and metadata. The control plane sits on every black line and none of the purple ones.

Control plane

Go service backed by Postgres. Owns identity, workspaces, portals, roles, and every transfer's authorization record. Never opens a file.

Sidera Storage Bridge

relay-agent — runs on the machine that has the disk. Serves and receives bytes for whichever portals point at it.

Sidera Connect

A small tray app on the END USER's own computer. Bridges a browser tab's upload/download to the mTLS data plane, since a browser can't speak raw QUIC.

Web app

Next.js. Every portal and the workspace admin console are the same app, branded and routed by hostname.

Workspaces & portals

A workspace is the top-level tenant — a company or team. Inside it, a portal is a branded, subdomain-based destination (acme.your-domain) with its own members and roles, independent of who belongs to the workspace itself. A portal member can hold access to a portal without ever being a workspace member at all — the two roster are deliberately separate.

Concept	What it is	Who manages it
Workspace	The tenant boundary. Owns storage connections and every portal underneath it.	Workspace admins, via `config.your-domain`
Portal	A branded upload, download, or send destination on its own subdomain.	Portal admins/managers
Portal member	Someone with a role on ONE portal (Admin, Manager, or User) and a set of capabilities (upload, download, send, manage files).	Assigned per portal

config.your-domain → workspace admin consoleacme.your-domain → a portal

Storage & the Storage Bridge

Every portal points at exactly one registered storage connection — see Connect your storage for how one gets registered. Once online, the Storage Bridge reports its own file listing on a schedule; the control plane never scans the disk itself, it only ever relays what the Bridge last reported.

Moving bytes: two shapes

Every real transfer moves over the same underlying mTLS QUIC data plane, authenticated by a short-lived, control-plane-issued certificate — but who's on the other end of that connection differs by operation.

Same transport, different topology: a browser-initiated transfer always detours through Sidera Connect; an agent-to-agent Send never does.

File management is a queue, not a transfer

Deleting a file, creating a folder, or renaming something doesn't move any bytes, so it doesn't use the transfer/QUIC path at all. The control plane just queues a lightweight operation; the Storage Bridge picks it up on its next poll, executes it locally, and reports back whether it succeeded.

Why a queue instead of a direct callThe control plane has no standing connection to a Storage Bridge to call INTO — Bridges only ever poll outward. Queuing means every management action still works even if the Bridge is briefly offline when it's requested; it just runs on the next poll.

Security model, in short

mTLS everywhere on the data plane

Every QUIC connection is mutually authenticated with short-lived, control-plane-issued certificates — never a shared static secret.

Capability-gated actions

Upload, Download, Send, and Manage files are each their own capability, assigned per portal member, checked on every request.

Virtual roots

A member's allowedRoot confines every path they can touch to one subtree of a portal, even if the Bridge's real disk root is larger.

One-time enrollment tokens

A Storage Bridge token is shown once, expires on its own, and only ever resolves to the one storage slot it was generated for.