Guides

Connect your storage

A storage connection points Sidera at one disk, NAS, or server so a portal can serve and receive files from it. You do this once per machine, from a small program called the Sidera Storage Bridge — generate a token in the browser, paste it into the Bridge on that machine, and it takes care of the rest.

How it works

Nothing about the disk itself — its path, its operating system — ever needs to be typed into the browser. The control plane only ever hands out a short-lived token; the machine that actually has the disk uses that token to identify itself and register, then tells the control plane where its shared folder lives. This is deliberate: the workspace admin sitting in a browser rarely has any reason to know a remote machine's exact folder layout, and the control plane never touches that machine's filesystem directly at all.

The token round-trips once through the browser, then the Storage Bridge uses it directly with the control plane — the admin never re-types it anywhere.

1. Generate a token

Open the workspace admin console and start a new connection

Sign in at your workspace's config. address as a workspace admin, go to Storage, and choose Connect your storage.
Choose "On-premise disk or server"

Cloud storage (S3, Azure Blob, Google Cloud Storage) connects a different way and is marked "Coming soon" for now.
Name it, and generate a token

Give the storage a name people will recognize later — "Edit Suite RAID", "Archive NAS - 2nd floor" — and Sidera generates a one-time enrollment token. This name is just a label shown in the dashboard, not a path — the actual local folder is entered on the host machine itself in the next step, since this browser has no way to know what folders exist there.

Copy the token nowThe dialog shows it exactly once. If you close it before copying, generate a new one — the old one still works until it expires, it just won't be shown again.

2. Install the bridge on the host

Run this on the machine that actually has the disk — not necessarily the machine you're reading this on. It downloads the Sidera Storage Bridge and asks for the token above — that's the only thing it asks for; the name and path you just entered travel inside the token itself.

curl -fsSL https://relay-dev.cloud/downloads/install-storage.sh | sudo bash

Paste the token when asked

The installer looks the token up against the control plane and reads back the name, path, and storage ID you already entered — nothing else to type.
It installs itself as a background service

Survives closing the terminal, restarts after a reboot. Back in the dashboard, the storage flips from Waiting for host to Online within a few seconds.

Scripting an unattended install?--token, --name, and --root (-StorageToken/-StorageName/-StorageRoot on Windows) skip the token prompt entirely and override whatever it carries — for a token generated fresh each time, none of them are needed.

3. Assign it to a portal

A storage connection is just a registered host — it isn't attached to anything yet. Open (or create) a portal, and pick this storage from the dropdown as its root. One storage can back more than one portal at once, and one host can run more than one Bridge instance if it needs to serve more than one disk.

Security notes

What the token can and can't doA token identifies exactly one pre-registered storage slot and expires on its own — it can't be used to enroll a different storage, and it stops working once it's expired or once that storage is already registered. Every byte the Bridge later moves travels over a separate, mutually-authenticated connection issued at registration time, not the enrollment token itself.

Removing a storage

Removing a storage from the dashboard (storage list's remove action) only deletes its record on the control plane — the control plane has no way to reach out and stop the actual service on the host, since the Storage Bridge always initiates contact, never the reverse. Do both, in either order, or the service keeps running on the host, quietly heartbeating into a rejection every few seconds.

sudo systemctl disable --now sidera-storage
sudo rm /etc/systemd/system/sidera-storage.service /etc/sidera/storage.env
sudo systemctl daemon-reload

Running more than one Storage Bridge on the same machine? Add --instance <name> (Linux — matches the systemd unit's own suffix, e.g. sidera-storage-<name>) or -InstanceName <name> (Windows) to remove that specific one instead of the default — the firewall rule and downloaded binary are shared across instances and are left alone as long as another one still uses them.

Troubleshooting

The installer says it couldn't resolve the token

Double-check you're pasting the token exactly as copied (no trailing space); tokens expire, so generate a fresh one if it's been a while since you created it. If you passed --control-plane/-ControlPlaneUrl explicitly, make sure it ends in /api — the bare domain alone won't reach it.

The storage shows "Online" but uploads just sit at "Waiting" forever

This is almost always one of two things, both on the host itself: the storage bridge's QUIC data-plane port (e.g. 7443, or the next free one it prints when a second storage shares the machine) isn't reachable, or (Linux/macOS only) the folder you gave isn't actually writable by the account the storage bridge runs as — the dedicated sidera user; a bare mkdir as root leaves it owned by root. Fix either and any transfers already queued resume automatically — no need to retry them. On a machine reachable directly from the internet, "not reachable" usually means the port isn't open in that machine's own firewall. On Windows specifically, note that Windows Defender Firewall never shows its usual "allow this app?" prompt for a service (only for an app running in a logged-in desktop session) — install-storage.ps1 opens the port automatically now, but an install from before that fix needs the same rule added by hand (see its own troubleshooting entry below). On a machine behind a router/NAT — common for an office desktop rather than a rented server — the port also needs forwarding from the router's public IP to that machine's LAN IP, which install-storage.ps1/.sh cannot do for you since it has no access to your router.

(Windows) Still "Waiting" after confirming the storage is Online

Two things to check, in order. First, the Windows Firewall rule: Get-NetFirewallRule -DisplayName "Sidera Storage Bridge*" should list one — if not, re-run install-storage.ps1 (safe, it replaces the existing service in place) or add the rule directly: $svc = Get-CimInstance Win32_Service -Filter "Name='SideraStorage'"; $exePath = ($svc.PathName -split '"')[1]; New-NetFirewallRule -DisplayName "Sidera Storage Bridge ($exePath)" -Direction Inbound -Program $exePath -Action Allow. Second, if that machine sits behind a router (an office desktop, not a machine with its own public IP), that router needs to port-forward the storage bridge's QUIC port (UDP, shown in the install output — 7443 unless another storage on the same machine took it) to that machine's LAN IP (ipconfig → IPv4 Address). Also worth confirming the router's own WAN/public IP actually matches what the dashboard shows for this storage — a corporate VPN or proxy on the outbound path can make the control plane record a different address than the one the router itself is reachable at, in which case forwarding on "the" office router won't help and the real gateway needs identifying first.

The storage still shows "Waiting for host" after installing (never goes Online)

Confirm the service is actually running on the host (the installer prints how to check), and that machine can reach your control plane's address over HTTPS — a firewall or proxy blocking outbound traffic is the most common cause.

Can I connect a Mac?

Linux and Windows are supported for on-premise storage; macOS is not.