Self-hosting your studio stack on a single server

TL;DR — We run our whole studio stack — password manager, file sync, automation, git, CRM, e-signatures, invoicing — on a single well-specced server. One Proxmox host, a dozen isolated VMs on a private network, everything reachable only through one reverse-proxy edge behind a Cloudflare tunnel. The payoff is data ownership, near-zero recurring cost, and a deep understanding of our own infrastructure. The price is real: it’s ops work, and you are now the on-call engineer.

Most small studios rent their entire toolchain. A subscription for passwords, another for file storage, another for automation, another for the CRM. It’s convenient, it’s metered to the seat, and it quietly scatters your clients’ data across a dozen vendors you’ll never audit. We went the other way. One server runs the lot, the data sits on hardware in a room we can point at, and the monthly bill rounds to the cost of electricity. This is the architecture, and the honest trade-offs.

One box, many walls

The host is a single workstation-class machine — a Xeon, a pile of RAM, mirrored disks — running Proxmox, a hypervisor that lets one physical box pretend to be many. Each service gets its own virtual machine or container, and that isolation is the whole point. Vaultwarden doesn’t share a filesystem with the CRM. The CI runner that executes untrusted build steps lives on its own VM, walled off from anything that matters.

Here’s roughly what runs on the box:

• Vaultwarden — self-hosted password manager (Bitwarden-compatible)
• Nextcloud — file sync and share, with the bulk data on a dedicated disk
• n8n — workflow automation, editor locked down, webhooks public on a separate hostname
• Forgejo + a CI runner — private git hosting and continuous integration
• A CRM, an e-signature service, and invoicing — the client-facing business layer
• Authentik — single sign-on and forward-auth gating with MFA
• Monitoring — uptime checks and per-host metrics

Everything sits on a private internal network — 10.10.10.0/24, invisible from the public internet. Nothing is port-forwarded. The only way in is through a single edge VM running a reverse proxy, and the only way that edge talks to the outside world is a Cloudflare tunnel: an outbound-only connection, so there’s no open inbound port to scan or attack.

The goal isn’t to make one impenetrable wall. It’s to make sure that when something does go wrong, the blast radius is one service — not the whole studio.

Least privilege, everywhere

Segmentation only helps if the rules between segments are tight. A few principles we hold to:

Auth at the edge, scoped to the service. Admin surfaces — the Vaultwarden admin panel, the automation editor — are reachable only over our private mesh VPN, never over the public tunnel. Business apps sit behind single sign-on with MFA enforced. Public-facing endpoints get an explicit allowlist of routes at the proxy; everything else returns a 404 before it ever reaches the application.

Scoped credentials, not root. When a service needs object storage, it gets a credential scoped to its own bucket — not the storage admin key. When backups need to read the disk, the token has exactly one permission: read for backup. The blast radius of a leaked secret should be a single bucket, not the estate.

Secrets live in exactly two places. On the VM that needs them (file permissions locked down) and in the password manager. Never in git. A .gitignore doesn’t protect what you already committed, so the rule is upstream of the mistake: secrets never enter the repo in the first place.

Backups, monitoring, and being on call

Self-hosting without backups isn’t self-hosting; it’s a countdown. The rule we never break: no backup, no change. Before touching anything in production, there’s a snapshot and a logical database dump, and a written-down way to roll back.

The backup strategy is two-tier. A local backup server keeps full retention and fast restores. A separate offsite copy goes to cloud object storage, encrypted, so a fire or a theft doesn’t take the data with it. The offsite tier is deliberately small — it holds the latest snapshot only — because a restore you’ve never tested is just a hope. We’ve run the drill.

A one-line manual trigger sits next to the nightly cron, for when we want a fresh copy before a risky change:

ssh host "/root/restic-b2-backup.sh"   # encrypted offsite snapshot

Monitoring is the other half. Every host reports metrics; uptime checks watch the public endpoints. An intrusion-detection layer reads the proxy logs and bans hosts that misbehave. None of this is exotic — it’s just the difference between learning a service is down from a dashboard versus learning it from a client.

And that’s the real trade-off. Renting your stack means someone else is on call at 3 a.m. Owning it means you are. You’ll do upgrades one major version at a time, with a rollback ready, because the alternative is discovering a breaking change on a Saturday. You’ll pin image versions instead of chasing latest. You’ll keep a runbook for each service so that future-you, or an assistant, can fix it without re-deriving everything from scratch.

Is it worth it?

For us, yes — but the calculus is specific. We’re a design and automation studio; understanding infrastructure is adjacent to the work, not a distraction from it. The data sovereignty matters because we hold clients’ files and contacts, and we’d rather not explain a third-party breach. And the recurring cost of a dozen SaaS seats, compounded over years, buys a lot of server.

If you bill by the hour and never want to think about a kernel update, rent your stack and move on. But if you want to actually understand the systems your business runs on — and keep your clients’ data on hardware you control — one server goes remarkably far.

Takeaway: Start with one service you already pay for, put it on one box behind one reverse proxy, and get backups working before you migrate anything real. The architecture scales from there. The discipline — backup first, least privilege, secrets out of git — is what makes it sustainable.