The Best VPS for Self-Hosted Supabase of 2026
Self-hosting Supabase means running about fifteen Docker containers, not one application. PostgreSQL, GoTrue for auth, PostgREST for the API, Realtime for WebSocket subscriptions, Storage, Kong as the gateway, Studio for the dashboard, plus supporting services. It’s a platform, and the sizing follows from that.
Which is why the guidance you’ll see ranges from “2GB works” to “16GB minimum” — both are true, for different deployments:
- 2GB and 1–2 vCPU runs a development or throwaway staging instance. It will work and it will feel tight.
- 4GB and 2 vCPU is the realistic production floor. PostgreSQL alone wants 1–2GB before the other fourteen containers start.
- 8–16GB is where a production app with real traffic belongs, with room for the database to grow into memory.
- Disk I/O matters more than CPU. Supabase is Postgres underneath, and poor IOPS shows up directly as slow API responses.
Quick comparison
| Provider | From | NVMe | Best for |
|---|---|---|---|
| Hostinger | ~$5.84/mo | ✅ Yes | Best price-to-performance |
| DigitalOcean | ~$4/mo | ✅ Yes | Developer experience |
| Vultr | ~$6/mo | ✅ Yes | Global reach, edge latency |
| AWS (EC2) | Variable | ✅ Yes | Enterprise and compliance |
| Railway | Usage-based | ✅ Yes | Instant deployment |
| Hetzner | ~$4.49/mo | ✅ Yes | RAM per dollar |
| Liquid Web | ~$3.50/mo | ✅ Yes | Managed option |
Sizing a fifteen-container stack
The individual services are mostly modest. The problem is that there are a lot of them, and one of them is a database.
| Deployment | vCPU | RAM | Storage |
|---|---|---|---|
| Development / throwaway staging | 1–2 | 2GB | 40GB |
| Small production app | 2 | 4GB | 80GB |
| Production with real traffic | 4 | 8GB | 160GB |
| Larger production | 4+ | 16GB+ | 160GB+ |
Why 2GB fails in production. PostgreSQL wants 1–2GB on its own to hold a useful working set in shared buffers. Add GoTrue, PostgREST, Realtime, Storage, Kong, Studio and the rest, plus operating-system and Docker overhead, and a 2GB box is running everything with nothing spare. It works until traffic arrives, then Postgres starts hitting disk for everything and the whole API slows down at once.
Storage grows in three directions. The base installation is around 10GB. Then your actual data, then logs, then backups. Starting at 80GB and planning for 160GB is sensible — running out of disk on a database server is a considerably worse afternoon than running out on a web server.
IOPS deserve more weight than they usually get. Everything a Supabase app does goes through Postgres. Slow disk means slow queries means slow API responses, and no amount of CPU fixes it. This is the main reason NVMe is non-negotiable for this workload while it’s merely nice-to-have for many others.
What to actually evaluate
Four criteria matter more for Supabase than for a general web host:
Database IOPS and latency. Read and write throughput, and P95/P99 latency rather than averages. Storage type first, everything else second.
Network stability for Realtime. Supabase pushes database changes over WebSockets. Connections held open for hours are unforgiving of flaky networking in a way that ordinary HTTP request-response traffic isn’t, so consistent latency and generous connection limits matter.
Scaling without migration. Databases are the worst thing to migrate. A host where you can add RAM and CPU in place, rather than rebuilding on a bigger instance and moving data, is worth a premium here specifically.
Deployment and teardown speed. You will rebuild this stack several times while getting the environment variables right. Fast provisioning and template or IaC support turn that from an afternoon into a few minutes.
The 7 best VPS providers for self-hosted Supabase
1. Hostinger — best price-to-performance
Hostinger leads on the specification that matters most here: 8GB of RAM at the tier most people buy, on NVMe storage. For a fifteen-container stack with PostgreSQL at its centre, that combination is the whole game — enough memory for Postgres to keep a real working set in buffers, and fast enough disk that the queries which do hit storage don’t stall the API.
Its Docker tooling handles the Compose stack cleanly, and you keep root access for the configuration work self-hosted Supabase inevitably needs. Free weekly backups matter more than usual when the thing you’re backing up is a database.
The KVM virtualisation with dedicated resources is the other requirement being quietly met — a fifteen-container stack on oversold shared virtualisation is a bad time.
Pros: 8GB at the practical tier; NVMe with strong measured IOPS; KVM with dedicated resources; Docker tooling; free weekly backups; firewall included; 30-day money-back guarantee.
Cons: promotional pricing needs a long prepay term and renews higher; scaling beyond the plan ladder means a migration eventually.
Who it’s for: most self-hosted Supabase deployments, from staging through small production.
Check Hostinger’s current VPS pricing →
2. DigitalOcean — best developer experience
DigitalOcean is the choice when the surrounding tooling matters as much as the box. The documentation on running containerised Postgres workloads is genuinely good, the API and CLI make the environment reproducible, and snapshots let you checkpoint a working stack before a Supabase version upgrade — which, given how many moving parts are involved, you will want at least once.
It also offers managed PostgreSQL separately, which is worth knowing about: a legitimate middle path is self-hosting the Supabase services while pointing them at a managed database, so somebody else owns backups, failover and version upgrades for the part that matters most.
Value per gigabyte is the weakest here, and this is a memory-hungry workload.
Pros: excellent documentation and API; strong snapshots; managed Postgres available as a middle path; private networking; 99.99% SLA; global regions.
Cons: most expensive RAM on this list; backups add ~20%; no money-back guarantee.
Who it’s for: teams who want reproducible infrastructure and might split the database out.
Check DigitalOcean’s current pricing →
3. Vultr — best global reach
Vultr’s relevance to Supabase is Realtime. If your users are geographically spread and holding WebSocket connections, sitting close to them measurably improves the experience — and Vultr has one of the widest region lists available.
High Frequency instances with NVMe also help on the database side, since faster cores and fast storage together reduce query latency at the margins.
No template, no money-back guarantee, and the console assumes competence.
Pros: very wide region choice for latency-sensitive Realtime; High Frequency NVMe instances; competitive pricing; good scaling range.
Cons: no Supabase template; no money-back guarantee; utilitarian tooling.
Who it’s for: apps with geographically distributed users relying on Realtime.
4. AWS (EC2) — best for enterprise and compliance
AWS is here for the cases where the requirement isn’t technical. Compliance regimes, procurement standards, existing enterprise agreements, or an organisation that already runs everything else on AWS — those are real constraints, and EC2 answers them.
The technical benefits follow: RDS if you want the database managed and separated, EBS volumes you can resize without rebuilding, and effectively unlimited scaling headroom.
The cost is complexity and price. EC2 pricing is genuinely hard to predict for a workload like this once you count storage, transfer and support, and the console is an ongoing tax on your attention. For a small self-hosted Supabase instance it’s substantially more platform than the job requires.
Pros: every compliance certification; RDS for a managed database; resizable EBS storage; unlimited scale; fits existing AWS estates.
Cons: hardest pricing to predict here; significant operational complexity; overkill for small deployments.
Who it’s for: enterprises, regulated environments, and teams already standardised on AWS.
5. Railway — best for instant deployment
Railway is the fastest path from nothing to a running Supabase-like stack. It’s a platform rather than a server: you deploy services, it handles the infrastructure, and there’s no operating system to patch.
For prototyping, internal tools and projects where developer time costs more than compute, that’s a strong trade. Usage-based pricing means a quiet project costs very little.
The trade-offs are the usual PaaS ones. Less low-level control, usage-based billing that’s harder to predict as traffic grows, and you’re building on their abstractions rather than plain Docker. For a fifteen-container stack you’d typically deploy the services individually rather than lifting the standard Compose file wholesale.
Pros: fastest deployment; no server administration; usage-based pricing suits quiet projects; clean developer experience.
Cons: less control than a VPS; costs less predictable at scale; not a drop-in for the standard Compose stack.
Who it’s for: prototypes, internal tools, and teams who’d rather not run servers.
Check Railway’s current pricing →
6. Hetzner — best RAM per dollar
On a workload this memory-hungry, cost per gigabyte is close to the whole decision, and Hetzner wins it. Around €13.99 gets 4 vCPU and 8GB — the production-with-real-traffic tier — for roughly what a 4GB instance costs at the premium end.
Attachable volumes are particularly relevant here: database storage grows, and being able to add disk without migrating the server is exactly the “scale without migration” property Supabase deployments need.
No template, no published SLA, backups extra, and signup verification can be slow. For a production database, the missing SLA deserves genuine thought rather than a shrug.
Pros: by far the best RAM per dollar; attachable volumes for growing databases; NVMe; hourly billing with a spend cap; GDPR-compliant locations.
Cons: no published SLA, which matters more for a database than a web server; no template; backups extra; signup friction.
Who it’s for: cost-conscious deployments that need real memory, where no SLA is acceptable.
Check Hetzner’s current pricing →
7. Liquid Web — best managed option
Liquid Web is the answer for teams who want self-hosted Supabase’s economics without owning the server layer. Its managed tiers put OS patching, monitoring and incident response with someone else, which for a stack containing your production database is a defensible purchase rather than an indulgence.
Self-managed plans start low and give full root access if you’d rather do it yourself.
No Supabase-specific tooling, no money-back guarantee, and managed tiers cost considerably more than the entry price implies.
Pros: genuine managed option; strong support reputation; solid hardware and NVMe; full root access on self-managed.
Cons: no Supabase template; no money-back guarantee; managed tiers a significant price step.
Who it’s for: teams running Supabase in production without a dedicated ops person.
Check Liquid Web’s current pricing →
Self-hosted or managed?
Self-hosting Supabase gives you the same core functionality — Postgres, Auth, Storage, Realtime, Edge Functions — at a fraction of managed pricing, with fixed costs instead of usage-based billing and no limits on database growth.
What you give up is dashboard convenience and, more significantly, operational responsibility. You configure through files and environment variables rather than a UI, you handle upgrades manually across fifteen containers, and community support replaces a support contract.
Self-host when: costs at your usage level are meaningful, you need data residency or full control, you’re comfortable with Docker and basic server administration, or predictable fixed pricing matters more than convenience.
Use managed when: the dashboard workflow matters to your team, nobody wants to own database operations, or your usage is low enough that managed pricing is genuinely cheap. For a small project, managed Supabase’s free and low tiers are hard to beat on total cost once you price your own time.
The honest middle path is worth repeating: self-host the Supabase services, but point them at a managed PostgreSQL instance. You keep the cost control and lose the part of the job with the worst failure modes.
How we picked
We weighted the criteria that matter for a database-centred, multi-container stack: memory at realistic price points, storage type and IOPS, whether you can scale RAM and disk without migrating, network consistency for long-lived WebSocket connections, and backup handling. Memory and disk are weighted hardest because PostgreSQL is the component that determines whether the whole platform feels fast.
Requirement figures reflect published guidance for self-hosted Supabase rather than our own load testing, and we’ve given the range rather than a single number because development and production genuinely differ by a factor of four or more. Pricing is each provider’s published rate at the time of writing. Two of the seven providers here earn us nothing.
How to choose
- Development or production? 2GB genuinely works for the former and genuinely fails for the latter.
- Prioritise NVMe and IOPS over CPU. Everything goes through Postgres.
- Can you add RAM and disk in place? Migrating a database is the thing you most want to avoid.
- Does Realtime matter? If users hold WebSocket connections, region proximity and network consistency move up the list.
- Price it against managed before committing — including your own time on upgrades and backups.
For most people it’s Hostinger — 8GB on NVMe at the tier you’d actually buy is the correct shape for this stack. Hetzner if cost per gigabyte dominates and no SLA is acceptable, DigitalOcean for tooling and the managed-database middle path, Vultr for globally distributed Realtime, Railway to skip servers entirely, Liquid Web if you want it managed, and AWS when compliance or an existing estate decides it for you.
FAQ
What are the minimum requirements for self-hosted Supabase?
A development or minimal staging instance runs on 2GB of RAM and 1–2 vCPUs. For production, 4GB and 2 vCPUs is the realistic floor, and 8–16GB is where an app with real traffic belongs. NVMe storage matters more than CPU because everything routes through PostgreSQL. Start at 80GB of disk and plan for 160GB once data, logs and backups accumulate.
Why does Supabase need so much RAM?
Because it isn’t one application — self-hosted Supabase runs roughly fifteen Docker containers: PostgreSQL, GoTrue for auth, PostgREST for the API, Realtime, Storage, Kong as the gateway, Studio for the dashboard, and supporting services. PostgreSQL alone wants 1–2GB for a useful working set, and the remaining containers plus OS and Docker overhead consume the rest of a small box.
Is self-hosting Supabase cheaper than the managed service?
At meaningful usage, substantially — you swap usage-based pricing for a fixed monthly server cost with no limits on database size. At small scale, managed is often cheaper once you value your own time, since you take on upgrades across fifteen containers, backup verification and incident response. The middle path is self-hosting the services against a managed PostgreSQL instance.
Can I run self-hosted Supabase on a 2GB VPS?
For development, yes. For production, no — PostgreSQL needs 1–2GB before the other containers start, so a 2GB box has nothing spare. It will appear to work in testing and then degrade as soon as real traffic arrives, because Postgres will be reading from disk for queries it should be serving from memory. 4GB is the honest production minimum.
Related Blog Posts
