Mastodon

Introducing Storm Pulse: How We Manage Our Servers

Every server management platform ships with an agent you can't read, phoning home to servers you don't control. For our vision of Canadian Digital Sovereignty, that wasn't good enough.

We run many servers internally - the Storm Developments site, a Forgejo git forge, a Mastodon instance, and a PeerTube node. More are coming as we bring Storm Drive and Storm Cellar online, plus the Garage storage nodes behind them.

The problem was simple:

I wanted to see what my servers were
doing without having to SSH into each one.

CPU, memory, disk, containers - the basics. And when something needed a restart, a deploy, or just a log check, I wanted to do it from one place.

I wasn't going to build something insecure to save myself some convenience. Security couldn't be an afterthought bolted on later - it had to be the architecture itself.

So we built Storm Pulse.

What it does

The dashboard shows live metrics for every connected server - CPU, memory, disk usage, running containers, uptime. The agent pushes updates every 15 seconds over a persistent WebSocket connection. No polling, no refreshing.

Storm Pulse Internal Dashboard Screen 1

Commands are whitelisted per-server. You define what the agent is allowed to do - nothing more. Git pull, docker logs, restart a service - each one is a button on the dashboard with confirmation prompts and parameter inputs based on what the agent reports it can run.

Storm Pulse Internal Dashboard 2

From there, you build sequences. Drag commands into an order, name it whatever you want, and run it with one click. "Deploy" might be git pull, docker build, containers down, containers up. "Backup" might be something else entirely. Each step reports back in real time, and if a step fails, the sequence stops before it makes things worse.

ℹ️

The agent is ~30 MB in memory with three dependencies. The full protocol is documented in the Protocol Specification.

Security is the architecture

Storm Pulse opens zero ports on your server.

The agent connects outbound to the dashboard - the dashboard never reaches into your servers. Port scanners find nothing. There's no attack surface to probe.

From there, it's layers: mutual TLS with per-agent certificates, HMAC-signed commands with replay protection, a strict command whitelist with no arbitrary execution, and OS-level sandboxing. Each layer is independent - compromising one doesn't give you the next.

ℹ️

The full design is documented in the Security Architecture wiki.

Where it's at

The agent is at v0.1.1. The dashboard is functional but built for our team, not customers yet.

The next milestone includes getting the setup experience tight enough that we could hand it to someone and walk away.

Every time we onboard a new server internally, we refine the documentation. Every rough edge in the enrollment flow gets smoothed. The goal is a setup process so simple it hurts to think about how complicated it used to be.

Once that's solid, we automate it. Spinning up a new server with Storm Pulse pre-configured - enrolled, monitored, ready for deploys - should take minutes.

After that, it ships with managed hosting. Every Storm Developments customer gets monitoring, deploys, and logs out of the box. No SSH required.

The agent is MIT licensed. The thing running on your server is fully open, always.