If you already run a Proxmox node in your home lab, it's natural to wonder whether your side project's backend belongs there too. The answer is yes — self-hosted Supabase runs well on Proxmox, and for development, staging, and personal projects it's one of the cheapest ways to get a full Postgres + Auth + Storage stack. The hardware you own is the hardware you've already paid for, and the system requirements are modest enough that even a mini PC handles it.
But there are Proxmox-specific decisions that trip people up: VM or LXC container? How much RAM does the stack really need? And the big one — does a Proxmox VM snapshot count as a backup? (Spoiler: not for Postgres, and treating it like one will eventually cost you data.)
This guide walks through the whole setup: choosing the virtualization layer, sizing the VM, deploying the stack, exposing it safely without opening ports, and backing it up correctly.
VM or LXC? (Use a VM)
This is the first question in every Proxmox thread on the topic, and the community has largely converged on an answer: run Docker inside a full VM, not an LXC container. There's even a long-standing request for a Supabase LXC helper script that never landed, partly for this reason.
LXC containers are tempting because they're lighter, but Docker-in-LXC requires nesting, keyctl workarounds, and occasionally breaks after Proxmox kernel updates. Postgres inside Docker inside an unprivileged LXC adds another layer of UID mapping complexity for volume permissions. It can be made to work — but "can be made to work" is exactly the property you don't want in the layer holding your database.
A VM gives you:
- Clean isolation — kernel updates on the host don't break your containers
- Live migration — move the whole guest to another node without touching the stack
- Predictable Docker behavior — no nesting flags, no AppArmor surprises
The overhead of a VM versus LXC on modern hardware is a few hundred MB of RAM. For a database, that's a fair price for not debugging cgroup issues at 11pm.
Sizing the VM
A recent walkthrough of Supabase on a Proxmox Docker VM used Debian with 4 vCPU and 12 GB RAM on Proxmox VE 9.x, which is a comfortable allocation. The practical floor is lower:
| Resource | Minimum | Comfortable |
|---|---|---|
| vCPU | 2 | 4 |
| RAM | 4 GB | 8–12 GB |
| Disk | 40 GB SSD | 100 GB+ SSD/NVMe |
A few Proxmox-specific notes:
- Use VirtIO SCSI for the disk and enable
discardif you're on thin-provisioned storage. Postgres write patterns will grow the disk image; discard lets space return to the pool. - Don't over-commit memory with ballooning on the database VM. Postgres and the ballooning driver both assume they own the RAM. Set min = max.
- Install
qemu-guest-agentin the guest so Proxmox can cleanly shut the VM down — an unclean stop mid-checkpoint is how you end up testing your recovery procedure involuntarily. - ZFS users: consider
volblocksizeand note that Postgres on ZFS on a zvol double-journals. It works fine for home lab loads; just don't chase benchmark numbers.
If your node is tight on RAM, the full stack is not mandatory — you can run a trimmed deployment with only the services you actually use. We covered which containers are safe to drop in our guides to running Supabase on low-memory servers and selective service deployment.
Deploying the Stack
Inside the VM, the setup is standard: Debian 12/13, Docker Engine, and the Supabase Docker Compose stack. The official Docker guide gets you a running instance in under 30 minutes; our own installation docs cover the Supascale-managed path, which automates the parts below.
If you deploy manually, three things are non-negotiable before you put anything real in the database:
- Replace the demo JWT secret and API keys. The compose file ships with publicly known defaults. Anyone who can reach your instance can mint a service-role token from them.
- Set a real Studio dashboard password.
- Put HTTPS in front before any traffic leaves your LAN.
One 2026-specific change worth knowing: as of August 2026, self-hosted Supabase uses Envoy as its default API gateway instead of Kong. Fresh deployments get Envoy automatically; if you're following an older tutorial that edits kong.yml, it no longer applies. We covered what changed and how to opt back into Kong in our Kong-to-Envoy migration prep guide.
Reaching It From Outside (Without Port Forwarding)
A home lab behind a residential connection should not port-forward 443 to a database stack. You have two good options, and both avoid touching your router:
- Tailscale — if the instance only needs to be reachable by you and your devices, a mesh VPN is the simplest and safest answer. Studio, the API, and Postgres itself stay entirely off the public internet. Setup details in our Tailscale for self-hosted Supabase guide.
- Cloudflare Tunnel — if a deployed app needs to reach the API publicly, a tunnel gives you TLS and a stable hostname without exposing your home IP or opening a single port. See Cloudflare Tunnel for self-hosted Supabase.
A common hybrid: Tailscale for Studio and Postgres, tunnel for the public API. Your attack surface is then the tunnel endpoint only.
Why a VM Snapshot Is Not a Database Backup
This is the most important section of this post, because Proxmox makes snapshots so easy that they feel like a backup strategy.
A Proxmox snapshot (or a scheduled vzdump to Proxmox Backup Server) captures the disk at a moment in time. For a running Postgres, that moment is crash-consistent at best: the restore behaves like the server lost power. Usually Postgres recovers from WAL and you're fine. Sometimes — under write load, with fsync-related edge cases on certain storage stacks — you get a database that starts but is subtly wrong, and you discover it weeks later.
There are also failure modes snapshots can't help with at all:
- Logical corruption — a bad migration or a
DELETEwithout aWHEREis faithfully preserved in every snapshot after it happened - Whole-node loss — snapshots stored on the same ZFS pool die with the pool
- House-level events — fire, flood, theft; a home lab's backups must leave the house
The correct layering:
- Keep vzdump/PBS backups — they're excellent for restoring the machine quickly
- Add logical database backups (
pg_dumpor WAL-based) on a schedule — they're the only thing that restores data reliably and portably - Ship them off-site to S3-compatible storage — B2, R2, or any provider
This is exactly the layer Supascale handles: scheduled backups shipped to your own S3-compatible storage, with one-click restore — including the Storage files that pg_dump alone silently misses. And critically, restores you can actually test, which is the difference between having backups and hoping you do. If you've never done a test restore, our guide to testing backup and restore procedures is worth the afternoon.
Honest Trade-Offs: When the Home Lab Isn't Enough
Supabase itself is investing in self-hosting — a recent community discussion notes a team member now dedicated to the self-hosted experience — but no amount of software fixes residential infrastructure:
- Your ISP and your power grid are your SLA. A multi-hour outage takes your app down with it. UPS units help; they don't make it a datacenter.
- Upload bandwidth on residential connections can make Storage-heavy apps sluggish for remote users.
- You're on call. When the node reboots for a kernel update at 2am, nobody else notices before your users do.
The pragmatic pattern we see most: home lab for dev and staging, a small VPS for production. The Proxmox node gives you free, disposable environments; production lives somewhere with redundant power and a real network. Because self-hosted Supabase is just Docker Compose, promoting a project from home lab to a €5 Hetzner instance is a backup-and-restore away — and if you manage both through Supascale, it's the same dashboard either side. A one-time license covers unlimited projects on both, so the home lab environments cost you nothing extra.
Conclusion
Proxmox is a genuinely good place to run self-hosted Supabase — as long as you make three decisions correctly: a VM rather than an LXC, no ballooning and honest RAM for Postgres, and logical backups shipped off-site rather than trusting snapshots. Combine Tailscale or a Cloudflare Tunnel for access and you get a full backend stack on hardware you already own, with a clean promotion path to a VPS when a project graduates to production.