This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.
If you’re weighing whether to self-host Supabase on Vultr VPS, the real decision isn’t “should I self-host” — it’s which of the two deployment routes actually fits your project. Vultr gives you a 1-click Marketplace App that has the whole stack running in a few minutes, and a manual Docker Compose path that takes longer but hands you full control over versions and services. Most guides only cover one or the other. Here’s what each actually gets you, what size VPS you need, and how the ongoing cost compares to just paying for Supabase Cloud.

Two Ways to Self-Host Supabase on Vultr
| Marketplace App | Manual Docker Compose | |
|---|---|---|
| Setup time | Minutes — pick plan, click deploy | 20-40 minutes — clone repo, edit .env, run compose |
| Control over stack version | Low — Vultr manages the default image | High — you pin exact Supabase/Postgres versions |
| Best for | Prototyping, quick backend for a frontend project | Production apps needing specific versions or a trimmed container set |
| Reverse proxy / HTTPS | Still your responsibility either way | Still your responsibility either way |
| Minimum viable plan | 4 GB RAM (High Frequency $24/mo) | 4 GB RAM (High Frequency $24/mo) |
Vultr’s official Marketplace App pre-installs the Supabase Docker stack — Postgres, Auth (GoTrue), Storage, Realtime, PostgREST, Studio, and the Kong API gateway — the moment the instance finishes booting, so the Studio dashboard and REST API are reachable shortly after deployment. Vultr even publishes a companion guide for wiring a Next.js frontend directly to a Marketplace App instance. The tradeoff is that Vultr controls which container versions ship by default, which matters if your app depends on a specific Supabase release or a feature still in beta.
The manual route follows Supabase’s own self-hosting documentation: clone the docker example repo, edit environment variables for JWT secrets and the Postgres password, then run docker compose up -d. It’s more setup work, but you decide exactly which of the roughly 12 containers run — and you can strip out services you don’t need (Realtime, Storage, imgproxy, Edge Runtime) to cut resource usage on a smaller instance.
Option 1: Deploy the Vultr Supabase Marketplace App
This is the fastest path if you just need a working Postgres + Auth + Storage backend behind a frontend project and don’t need to pin a specific Supabase version.
- Log into the Vultr Console and go to Products → Compute → Deploy Server.
- Under Marketplace Apps, search for “Supabase” and select it.
- Choose a High Frequency plan — 4 GB RAM minimum (see plan sizing below) — and a region close to your users.
- Click Deploy Now. Vultr provisions the instance and runs the Supabase stack’s first-boot configuration automatically.
- Once the instance shows as active, the Supabase Studio dashboard and API endpoint are reachable at the server’s IP — from there you set your project’s URL and anon/service keys in your app’s environment variables.
New Vultr accounts get $300 in free credit, valid for 30 days Vultr
— enough to run even the largest plan below for a full month while you decide if self-hosting is worth sticking with. If you’re also planning to run n8n or another automation layer alongside Supabase on the same account, our n8n self-hosting guide walks through a similar Docker + Nginx setup pattern.

Option 2: Manual Docker Compose Setup on a Vultr VPS
Choose this route if you need to pin a specific Supabase version, want to trim unused services before they ever start, or you’re already comfortable managing Docker Compose stacks by hand.
- Deploy a plain Ubuntu instance on Vultr (not the Marketplace App) sized at 4 GB RAM minimum — 8 GB recommended for production, per Supabase’s own sizing guidance.
- Install Docker and Docker Compose on the instance.
- Clone Supabase’s official
dockerexample repository and copy.env.exampleto.env. - Edit
.envto set your Postgres password, JWT secret, anon key, and service role key — never leave the example placeholder values in a publicly reachable instance. - If you don’t need Realtime, Storage, imgproxy, or Edge Functions, remove those service blocks from
docker-compose.ymlbefore starting the stack — this directly reduces the idle memory footprint, which independent tuning guides put around 1.5-4 GB depending on which services stay enabled. - Run
docker compose up -dand confirm all containers report healthy withdocker compose ps. - Put Nginx or Caddy in front of Kong (Supabase’s API gateway) to terminate HTTPS — you can generate the reverse-proxy block with our free Nginx config generator if you haven’t set one up before.
Because the stack runs as ordinary Docker containers, you can also use our Docker RAM calculator to sanity-check per-container memory limits before you commit to a plan size, especially if you’re trimming the container list from the default 12. If you’re running Postgres itself outside the bundled containers — some teams prefer managing the database independently — our self-hosted Postgres on Vultr guide covers backup and hardening steps that apply directly to Supabase’s underlying database.

Choosing the Right Vultr Plan Size for Supabase
Supabase’s self-hosting documentation states a practical minimum of 4 GB RAM / 2 vCPU, with 8 GB RAM / 4 vCPU recommended once you’re past prototyping. Vultr’s High Frequency compute tier maps onto those tiers cleanly:
| Vultr Plan | Specs | Monthly Price | Fits |
|---|---|---|---|
| High Frequency Entry | 1 vCPU / 2 GB RAM / 64 GB NVMe | $12/mo | Below Supabase’s stated minimum — only workable for a barebones dev instance with non-essential services stripped out |
| High Frequency Standard | 2 vCPU / 4 GB RAM / 128 GB NVMe | $24/mo | Matches Supabase’s practical minimum — staging or a low-traffic production app |
| High Frequency Plus | 3 vCPU / 8 GB RAM / 256 GB NVMe | $48/mo | Matches Supabase’s recommended production baseline |
Prices last checked: 2026-07-27
All Vultr Cloud Compute and High Frequency plans bill hourly but are capped at 672 hours per month, so the listed price is a hard monthly ceiling regardless of how many days are in the billing cycle. If you’re unsure which tier your specific app needs, our server spec recommender can help translate expected traffic and container count into a plan size before you deploy. For a broader look at where these prices sit across Vultr’s full lineup, our Vultr pricing breakdown covers hidden costs like bandwidth overage that also apply here.
The $24/mo tier is the one most indie projects should start on — it’s the exact number where Supabase’s own documented minimum and Vultr’s plan tiers line up, so you’re not paying for headroom you don’t need yet, but you’re also not running below spec on day one.
Self-Hosted Supabase vs Supabase Cloud: What It Actually Costs
Supabase Cloud’s Pro plan starts at $25/month, but that price only covers $10 of compute credit (a Micro instance), 8 GB of disk per project, 100,000 monthly active users, and 250 GB of egress — anything past those limits bills separately. In practice, real-world Supabase Cloud costs for small-to-medium apps commonly land between $35 and $75/month once overages are factored in, and apps in the 100K-200K MAU range often pay $100-200/month.
Self-hosting on a $24-48/mo Vultr VPS Vultr removes MAU-based and egress-based billing entirely — your cost is fixed no matter how much traffic you get. That’s a meaningful difference for a bootstrapped SaaS with unpredictable usage spikes, but it’s not free: you take on patching, scaling, backups, and Supabase version upgrades yourself, which is why cost-analysis writeups on the topic consistently frame self-hosting as worthwhile mainly for teams that already have some DevOps capacity, not as a default choice for every solo project.
Who should self-host: indie developers and small teams comfortable running a few Docker commands, projects with unpredictable or high MAU counts where Cloud’s usage-based billing would get expensive, and anyone who needs data residency control that a managed platform can’t guarantee.
Who should stay on Supabase Cloud: teams without spare time for server maintenance, projects still validating product-market fit where $25/month buys back weeks of engineering time, and anyone who needs Supabase’s managed upgrade path and support included by default.

Securing and Maintaining Your Self-Hosted Instance
Whichever deployment method you pick, a publicly reachable Supabase instance needs the same baseline hardening as any other production VPS. Lock down SSH and only expose the ports Kong and your reverse proxy actually need — our Vultr firewall setup guide walks through the exact ufw/iptables rules, and you can generate the rule set directly with our firewall rule builder instead of hand-writing it.
Rotate the JWT secret and service role key if they were ever exposed in a public repo, and schedule regular Postgres backups — the underlying database is the one piece of this stack you genuinely cannot afford to lose. A community-sourced experience report on GitHub Discussions (#8004 on the supabase/supabase repo) collects practitioner notes on keeping a self-hosted Docker Compose config in sync with upstream changes, which is worth a read before you commit to running this long-term without a managed upgrade path.
Final Verdict: Which Setup Should You Use
If you want to self-host Supabase on Vultr VPS with the least friction, start with the Marketplace App on a $24/mo High Frequency plan — it gets Postgres, Auth, Storage, and the API gateway running within minutes, and $300 in free Vultr credit Vultr covers your first month while you evaluate it. Move to the manual Docker Compose route only once you know you need a specific Supabase version pinned or want to strip the container list down for a leaner production footprint.
Either way, self-hosting only pays off if your traffic or MAU count would otherwise push you well past Supabase Cloud’s $25/month starting tier — for an early-stage project still validating an idea, the $25/month Cloud plan is genuinely the better use of your time.

