Mastodon

Public access

Serve a bucket's files over public HTTP. This is the feature behind Storm
Sites: once enabled, any object in the bucket is fetchable at its full path,
no credentials required:

https://<your-subdomain>.stormsites.ca/<path/to/file>

The Storm Sites example site served straight from a bucket at a stormsites.ca subdomain, with no web server or build pipeline behind it

That one URL grammar covers three different jobs:

  • Static site. Upload HTML, get a website. index.html and 404.html
    are served at the root and on missing paths if you add them. Neither is
    required.

  • App media. PeerTube, Mastodon, and similar apps upload over S3 with
    an access key; viewers stream from the bucket's public URL.

  • File and image sharing. Every upload becomes a stable public link.
    Upload photos/cat.jpg, share
    https://<your-subdomain>.stormsites.ca/photos/cat.jpg, done.

Want your own domain instead of the Buckets-assigned subdomain? See
Custom Domains.

Enabling

Open the bucket and switch to the Public access tab. While it's off, the
tab explains the three jobs above and shows a single Enable button.

The Public access tab in its disabled state, with the Enable button and the three-jobs explainer

Click Enable and the setup dialog opens. Pick a subdomain or accept the
one Buckets suggests; the refresh button rolls a new suggestion. Names use
lowercase letters, numbers, and hyphens, and reserved names like admin or
api are rejected. Your public URL is shown live as you type. The index and
error documents default to index.html and 404.html; leave them as-is
unless your files are named differently.

The Enable public access dialog, showing the subdomain field, the live public URL, and the index and error document fields

Once it's on, the tab shows how your files are served: the public base URL
with a Copy button, the path grammar, and the app-hookup note. Everything you
need to change later lives behind Configure, and Disable takes it back
offline.

The Public access tab in its enabled state, showing the serving URL, the app note, and the Custom domains section

Hooking up an app (PeerTube and friends)

The setup is always the same pairing: the app writes over S3 with
credentials, the public reads over plain HTTP without them.

  1. Create an access key for the bucket. See
    Managing Access Keys.

  2. Point the app's S3 storage config at the bucket: endpoint
    https://alpha.buckets.stormdevelopments.ca, region storm, your bucket
    name, the key id and secret. The full value list is in
    Connecting S3 Tooling.

  3. Enable public access on the bucket and note the stormsites.ca URL.

  4. Set the app's public / CDN base URL setting to that URL. In PeerTube
    this is object_storage.*.base_url; other apps call it "CDN URL" or
    "asset host".

The app keeps uploading over S3. Viewers fetch directly from the public
URL. Nothing proxies through the app server.

An image-sharing or download bucket is the same shape minus step 4: upload
with any S3 client, hand out the public links.

Uploading files

Use any S3 client with the bucket's key. The endpoint is
https://alpha.buckets.stormdevelopments.ca and the region is storm:

# AWS CLI
aws s3 cp ./public/ s3://<your-bucket>/ --recursive \
  --endpoint-url https://alpha.buckets.stormdevelopments.ca

# MinIO client
mc alias set buckets https://alpha.buckets.stormdevelopments.ca <key-id> <secret>
mc mirror ./public buckets/<your-bucket>

# Hugo (configure an s3 deployment target pointing at the same endpoint)
hugo deploy

Path-style is required. If your client has a "force path style" option, turn
it on. Full client setup lives in
Connecting S3 Tooling.

Whatever you upload is what gets served, at its exact path. There's no
intermediate build step and no manifest to keep in sync: the bucket listing
is the site.

The example site's own page listing the objects that make it up: index.html, style.css, 404.html, and an image, each fetchable at its full path

Index and error documents (optional)

Defaults are index.html and 404.html. If these files exist in your
bucket, they're served at the root and on missing paths. If they don't,
nothing breaks: every file is still served at its full path. A missing path
returns HTTP 404 either way; the error document only customizes the body.
Override either filename in the enable dialog or later under Configure.

Changing the subdomain

Click Configure on a public bucket and pick a new name. Buckets swaps the
Garage alias add-before-remove, so a failed swap leaves your old URL working,
and both URLs resolve to the same bucket for a brief window. The rename is
captured in the bucket's audit log.

What persists when you disable

Disabling takes the public URL offline but keeps your subdomain reserved,
so the URL is stable across a disable-then-re-enable cycle. The reservation
is released only when the bucket itself is deleted. Your objects are
untouched either way; they just stop being publicly fetchable.

No lock-in

It's standard object storage over a standard S3 API. Point any S3 tool at
the bucket and copy everything out whenever you want; nothing proprietary
holds your files.

rclone copy storm:<your-bucket> ./backup

The example site's footer: an rclone copy pulling every object out, and a Served from a Storm Bucket in Montreal, 100% Canadian Hosted line

Limits

No CDN. The Montreal node serves Canadian traffic well; international
visitors will see higher latency.

Bandwidth is fine for normal traffic patterns. If you expect sustained high
traffic, talk to Storm before you launch so we can plan capacity together.