Sidera HelpPlatform architecture

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.

Control plane auth · portals · policy Portal member's browser upload, download, browse Sidera Connect on the end user's machine Storage Bridge A e.g. the upload portal's disk Storage Bridge B e.g. a Send destination sign in · list portals heartbeat · authorize heartbeat · authorize loopback QUIC · file bytes Send · direct
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 — a Send never touches it at all once authorized.

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

sidera-storage — 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.relay-dev.cloud) 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 rosters are deliberately separate.

ConceptWhat it isWho manages it
WorkspaceThe tenant boundary. Owns storage connections and every portal underneath it.Workspace admins, via config.relay-dev.cloud
PortalA branded upload, download, or send destination on its own subdomain.Portal admins/managers
Portal memberSomeone with a role on ONE portal (Admin, Manager, or User) and a set of capabilities (upload, download, send, manage files).Assigned per portal
config.relay-dev.cloud → workspace admin consoleacme.relay-dev.cloud → 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.

Upload / Download Browser Sidera Connect same machine as Browser Storage Bridge loopback QUIC Two hops Send Storage Bridge A Storage Bridge B QUIC, direct One hop
Same transport, different topology: a browser-initiated transfer always detours through Sidera Connect; a bridge-to-bridge 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.