NorthTube runs on Storm Buckets now
NorthTube's videos now upload, transcode, and play from Storm Buckets in Montreal. Moving a live PeerTube instance off Backblaze B2 took one rclone command and some configuration. Here is the config that matters if you want to do the same.
NorthTube is our video platform: a Canadian PeerTube instance, ad-free, federated, real users, real uploads. Until this week its videos lived on Backblaze B2 in a US region. As of June 12, every video NorthTube stores, transcodes, and plays comes out of Storm Buckets, on a Garage node in Montreal.
NorthTube is not an arms-length customer; we run it. Before asking anyone else to trust this platform with a production workload, we put our own on it first.
What moved and how
The transfer itself was the boring part, which is what you want from an S3-compatible target. One rclone remote pointed at B2, one pointed at Storm Buckets, one copy command:
rclone copy b2:northtube-videos storm:northtube -P
rclone check b2:northtube-videos storm:northtube --one-way
24 files, 1.7 GiB, done in under eight minutes, verification clean. One detail worth knowing if you are leaving B2: its panel reported 138 files and 5.9 GB for that bucket. The extra 114 files were old versions retained by a keep-all-versions lifecycle rule. Only the current files exist as far as a copy is concerned. If your B2 numbers look inflated, that is probably why.

Pointing PeerTube at Garage
PeerTube speaks S3, so the config is short, but two settings matter when the target is Garage rather than AWS.
object_storage:
enabled: true
endpoint: 'https://<your S3 endpoint>'
region: 'storm'
force_path_style: true
credentials:
access_key_id: '<bucket key id>'
secret_access_key: '<bucket key secret>'
web_videos:
bucket_name: 'northtube'
base_url: 'https://northtube.stormsites.ca'
streaming_playlists:
bucket_name: 'northtube'
base_url: 'https://northtube.stormsites.ca'
force_path_style: true, because Storm Buckets is path-style only for now. And a base_url on every browser-fetched category (web videos, streaming playlists, captions), because Garage does not serve anonymous S3 reads. Signed writes go to the S3 endpoint; public playback goes through the bucket's website endpoint, which on Storm Buckets is the Sites feature. B2 lets you skip the base_url by marking a bucket public. Garage makes the same boundary explicit, and after debugging both, we prefer explicit.
One warning that cost us some time: if you run PeerTube in Docker, PEERTUBE_OBJECT_STORAGE_* environment variables silently override production.yaml. Check the environment first, and remember a container picks up env changes on recreate, not restart.
404s on playback: the path-style bucket-prefix problem
After the cutover, old videos returned 404 on playback while everything looked correct in the config. The cause is how PeerTube builds object URLs under path-style addressing: the bucket name stays in the URL path, and applying base_url swaps only the origin. Requests arrived at the website endpoint as /northtube/web-videos/<file> while the endpoint served /web-videos/<file>.
The fix is server-side. Storm Buckets Sites endpoints now accept both forms, with or without the leading bucket segment, so PeerTube's URLs resolve without patching PeerTube. It shipped the same day and is recorded. If you front Garage's web endpoint with your own reverse proxy, the equivalent fix is stripping an optional leading /<bucket-name> segment before the request reaches Garage.
Tracing writes that went to the wrong backend
Mid-migration, new uploads were missing from the new bucket while reads served fine and nothing logged an error. The activity log settled it. Every S3 operation against an account appears in the dashboard as it happens: reads were flowing, PUTs were absent, and a hand-sent probe upload appeared the moment it was issued. That proved the storage path end to end and isolated the fault to PeerTube's write side, where stale PEERTUBE_OBJECT_STORAGE_* environment variables still pointed at B2.
When an application and its storage disagree, a live record of what the storage actually received settles the argument fast.
Current state
NorthTube runs in production on the Storm Buckets alpha: a single Montreal node, RAID6 disks underneath, the full upload, transcode, and playback path serving federated traffic. Multi-zone replication is on the roadmap as a separately priced durability class.
Frequently asked questions
Can PeerTube use Storm Buckets or Garage for object storage?
Yes. Set force_path_style: true, point the endpoint at your bucket's S3 endpoint, and set a base_url for each browser-fetched category to the bucket's public website endpoint. The config above is what NorthTube runs.
Why does PeerTube need a base_url with Garage?
Garage does not serve anonymous S3 GETs, so browsers cannot fetch objects from the S3 endpoint directly. Public playback goes through the bucket's website endpoint instead. On Storm Buckets that is the public access feature.
Do PEERTUBE_OBJECT_STORAGE environment variables override the yaml?
Yes. In Docker deployments, env vars win over production.yaml, and the container only re-reads them on recreate. If your config edits seem to change nothing, inspect the running container's environment.
The Storm Buckets alpha is invite-only while we harden the platform. Nine Founding Alpha slots are open: 100 GB on the Montreal node, free during alpha, yours for life. If you want your backups, your PeerTube instance, or your weird side project on Canadian, open, auditable storage,
100% Canadian Hosted.