s SuppyHQ

The stack.

What runs SuppyHQ, where it runs, and who can touch it.

Most software companies hide their stack. I'd rather show mine. If you're trusting your customer data with SuppyHQ, you should know exactly where it lives and how it's locked down.

Here it is, by layer, in plain language.

Where it runs

One dedicated server at Hetzner, in Germany. One box.

Cloudflare sits in front for DDoS protection and TLS. Public traffic hits Cloudflare first, then is forwarded to the origin over HTTPS. The origin's firewall only accepts traffic from Cloudflare's IP ranges. Anything else gets dropped at the door.

What it runs

Ruby on Rails 8. I've been writing Rails since 2010 and shipped a dozen apps in it. Nothing here is new to me.

SQLite for the database, on the same disk as the app. The data lives next to the code that reads it.

Hetzner Object Storage for attachments and backups.

Fusionaly for marketing-page analytics. I built it, I host it on the same box.

LogNorth for uptime, errors, alerts, and logs. Also mine, also self-hosted. When SuppyHQ pages me at 2 AM, the page comes from a box I run.

Who can touch it

Nobody from the internet. SSH on the public side is closed.

I get in through Tailscale, a private network that connects my laptop directly to the server.

The Tailscale network has exactly one human on it: me. If my laptop is stolen, the device is revoked from my phone in 30 seconds.

Backups

Backups every 6 hours, off-server, encrypted before they leave. Each tenant database runs through AES-256-GCM at the app layer before upload. Even with bucket credentials, the blobs are ciphertext.

Hetzner also runs server-level snapshots automatically. Two backup mechanisms, two failure modes covered.

If the primary box dies, I can restore from the last backup to a fresh box in under an hour. I've practiced it.

Live data sits on a disk-encrypted volume on the box itself. Column-level encryption of message bodies is on the roadmap.

Will this scale forever?

No, and I'm not pretending it will.

SQLite and one box are right for SuppyHQ at this size. The target customer is a solo founder with up to 5,000 customers, batched email, not real-time chat. The math works.

As traffic and users grow, I'll adapt. Postgres when SQLite's writes start to hurt. A second box when one isn't enough. Each move only when the math stops adding up, not before.

I won't over-engineer for traffic I don't have. That's how solo products burn the runway: three years on infrastructure no customer notices, then game over.

When something breaks

I email the customer when the fix ships. Same close-the-loop rule as the support code.


One server. One database. One person on the keys.

If you're trusting SuppyHQ with your customer data, this is the box it sits on and the door I use to reach it.

Get started

Read next: Privacy · The support code