Mastodon

Garage + Storm Pulse = Storm Buckets

Simplicity is a security property. The foundation under Storm Buckets is two open-source projects and a small amount of glue: Garage for storage, Storm Pulse to manage the servers. Here's what each one does, and why that's the whole stack.


The web app is the front end. The product is the buckets, and the buckets do not depend on it. A download moves straight from the storage engine to you, and the dashboard you log into is never in that path. Shut the website off and your buckets keep serving.

Underneath are two open-source projects: Garage for storage, Storm Pulse to manage the servers. The dashboard sits on top of both as the control surface. Here's what each does.

Garage

image

Garage is an S3-compatible object storage engine written in Rust by Deuxfleurs, licensed AGPL-3.0. It is the thing that holds your data and answers S3 calls. We run Garage. We do not fork it, patch it, or wrap its source. We operate it over its own S3 and admin APIs, the same surfaces anyone running Garage would use.

That is a deliberate constraint. The storage engine is a published, auditable project with its own community and release cadence. The less of our own code sits between you and your bytes, the less there is to trust, audit, or get wrong.

Running on open source this way is a commitment as much as a convenience. It is the sustainability piece of the three we build on: sovereignty, sustainability, security. We have already contributed a fix upstream to Garage (garage#1450), and we intend to keep doing it. Depending on a project this directly means helping keep it healthy.

Storm Pulse

image

Storm Pulse is the agent that runs on every server we operate. It is open source (storm-pulse), AGPL-3.0, and ours. We built it because we needed a secure, simple way to manage a fleet of Garage nodes, clusters, and regions without ever crossing the privacy and trust boundaries our customers depend on.

Security is the first question in Pulse's design, and it shows in the layers. The agent opens no ports and accepts no inbound connections, so there is no door into it from outside, nothing to scan, nothing to reach. It dials out to us and waits. Every action we can ask it to take comes from a fixed whitelist baked into its own source, so the full list of what we can run on your machine is something you can read. These are independent layers of defense, and the complete threat model is in the repo.

The result is the part that matters most. The web app, the part of this that anyone on the internet can reach, holds no Garage admin credentials at all. They live on the cluster, in the agent's environment, because that is where the agent runs. There is no admin token anywhere in the Buckets database, so there is nothing there to steal.

The glue, and why it doesn't matter

image

So what is the web app for? It is the usual stack, Django and Channels, a Svelte single-page app, Postgres, etc. It does two jobs: the dashboard you log into, and the dispatcher that turns your clicks into signed Pulse commands. It maps Garage's internal identifiers to your account and draws the charts.

You work with your storage in two separate ways. Using it, the reads and writes on your objects, goes straight to Garage, and the web app is never in that path. You can point rclone, the AWS CLI, or Terraform at your bucket and never load the dashboard once, and if the website went down mid-afternoon your buckets would keep serving. Managing it, creating a bucket, rotating a key, deleting one, goes through the dashboard, because today that is the only thing that does it. Nothing in the architecture requires that: a management action is just a signed message to Pulse, so a CLI or an API could send the same ones. Neither exists yet, so for now the dashboard is the one control surface, and managing is the part that can wait if the site is briefly down.

The S3 storage is the core of the product, and it stands on its own. The dashboard is one interface in front of it, and that interface is interchangeable.

Why simplicity is the security claim

The web app is the most exposed piece of all this, and by design it is also the most ignorant. It does not know the storage internals, and it sits nowhere near your bytes. All it can do is ask Pulse. Pulse honors only a fixed list of requests, and every one is audit-logged end to end.

Be clear about the limit of that claim. This is internal hardening. It shrinks what a compromise on our side can reach. It is not a claim that we cannot see your data. Our operators have root on the machines, and the agent holds admin locally. If you need protection from us, encrypt your data on your own machine before it leaves it. That option is always open, and on this architecture it costs you nothing.

The whole stack

Garage stores your objects. Storm Pulse manages the servers they sit on. Both are open source, and both can be run by someone who never pays us a cent. The web app on top is convenience.

That is the entire foundation. Two projects and a small amount of glue, arranged so the glue can fall away and the product still stands.