Why We Self-Host Our Code on Storm Forge

Storm Developments tells Canadian organizations that their data should live on Canadian infrastructure. We mean it. We say it on the homepage, we say it in every product page, we say it in customer conversations.

So the question we had to answer, early on, was where we were going to host our own source code.

The honest options were the obvious ones. GitHub, owned by Microsoft. GitLab, headquartered in San Francisco. Bitbucket, owned by Atlassian. Every default in the developer ecosystem points at an American company operating American infrastructure under American jurisdiction.

We pick our own infrastructure. The Storm Cellar code, the Storm Pulse code, the Storm Drive code, every line of every product we sell, lives on Storm Forge. Storm Forge is our internal git forge, hosted on a Canadian server, run by us.

This was a deliberate choice. Here is what made it the only one we could live with.

You can't sell sovereignty on borrowed land

The argument for Storm exists because Canadian organizations are realizing they have given up too much control over their data. Email, documents, code, customer records, all of it sitting on infrastructure owned by companies headquartered elsewhere, governed by laws written elsewhere, subject to court orders issued elsewhere.

We are asking those organizations to trust us with their object storage, their managed services, their critical infrastructure. We are asking them to migrate from American defaults to Canadian alternatives.

That ask is impossible to make credibly while our own code, the code that defines what Storm is, lives on the same American servers we are telling them to leave.

This isn't a question of optics. It's a question of consistency. If sovereignty matters for a customer's database, it matters for our source. If Canadian jurisdiction is the right answer for their files, it's the right answer for our commits. Anything less makes the pitch hollow.

Practicing what we preach has to mean something

A lot of companies make sovereignty noises in their marketing while their actual operations tell a different story. The customer-facing site says "we believe in data sovereignty." The engineering team pushes to GitHub. The contradiction sits there quietly, unnamed, until someone notices.

We didn't want to be one of those companies.

Storm Forge is the answer to a specific test we set ourselves: every claim we make about sovereignty should apply to Storm itself first. If we wouldn't accept it from a vendor, we won't accept it from our own infrastructure choices. If we tell a Canadian co-op that their code shouldn't live in San Francisco, then ours shouldn't either.

The cost of holding ourselves to this standard is real. There are conveniences we give up. There is operational work we take on. Self-hosting is more demanding than letting GitHub handle everything. We accept that cost because the alternative is preaching one thing and practicing another.

What this commits us to

Choosing to self-host our code is also choosing to be accountable for it. Storm Forge is up because we keep it up. Storm Forge is secure because we made it secure. Storm Forge is backed up because we set up the backups. There is no third party to absorb the work or the blame.

This accountability is the part that matters most. Sovereignty is not a feature you turn on. It's a relationship between an organization and its infrastructure, and that relationship requires someone, specifically and identifiably, to be responsible for it.

For Storm, that someone is us. Every line of code we write is committed to a server we operate, in a country whose laws we live under, on hardware we are accountable for. That's the relationship we wanted with our own work, and it's the relationship we are building products to offer Canadian organizations who want the same thing for theirs.

What's coming next

Storm Forge is private. It hosts our company's code, our internal tools, our work-in-progress. That's the right scope for what it is.

But the broader Canadian developer community has the same problem we did. Every Canadian developer with a GitHub account is storing source code on American infrastructure. Every Canadian open-source project is reachable through an American URL. There is no Canadian Codeberg.

We're working on that. Soon, we'll be opening a public Canadian git forge at gitforge.ca. The idea is the same one Storm Forge is built on: code that stays in Canada.

More on that when it's live.