What Self-Hosting Supabase on a VPS Actually Involves
How to self-host Supabase on a VPS, in short: Supabase publishes an official Docker Compose stack of about 11 containers, and any virtual server with at least 4 GB of RAM and 2 CPU cores can run it. You get the same PostgreSQL database, authentication, auto-generated REST API, realtime subscriptions, file storage, and Studio dashboard as Supabase Cloud, on hardware you control, with no per-request billing.
Self-hosting is not one-click: you are the operations team, handling server updates, Supabase upgrades, backups, monitoring, and security hardening. The stack runs behind a Kong API gateway and expects Linux (Ubuntu 22.04 or 24.04 LTS), Docker Engine, and a domain pointed at your server for HTTPS. If that sounds fair, keep reading.
Know the limits: the self-hosted stack runs one project per deployment, and Studio has only basic HTTP authentication out of the box. The managed extras Supabase sells, point-in-time recovery, read replicas, database branching, hosted logs, are not included. The core, database, Auth, Storage, REST and Realtime APIs, Studio, is identical open-source code.
Choosing the Right VPS Size for a Self-Hosted Supabase Stack
RAM bites first. Supabase documents 4 GB of RAM and 2 CPU cores as the minimum, recommending 8 GB with 4 cores beyond toy usage. Studio, the dashboard, is the heaviest container; operators report a 4 GB server idles with little headroom once everything is up. A 2 GB server boots the stack but leaves nothing for traffic; 1 GB does not run it at all.
On a Hostinger VPS that maps cleanly: KVM 1 (1 vCPU, 4 GB RAM, 50 GB NVMe) meets the minimum for development or one low-traffic project. KVM 2 (2 vCPU, 8 GB RAM, 100 GB NVMe) hits the recommended spec, the sensible start for anything you depend on, including a server that also runs your frontend. KVM 4 exists if you outgrow that; most self-hosted deployments never need it.
Disk matters too: budget 40 GB SSD minimum, 80 GB+ for production, Postgres write-ahead logs, Docker images, and Storage files share one disk. Every Hostinger KVM plan includes the full root access you need; shared hosting cannot run Docker containers. See our Hostinger VPS hosting overview and KVM 2 price breakdown for current plan details.
Step 1: Prepare the VPS (Ubuntu, Docker, and DNS)
Start with a fresh Hostinger KVM VPS on Ubuntu 24.04 LTS (22.04 is equally fine) in the data centre closest to your users. Pick the location at setup from Hostinger’s VPS regions across Europe, Asia, North America, and South America. Connect over SSH as root, update the system, and install curl, git, and ca-certificates. Then install Docker Engine and the Compose plugin from Docker’s official repository, not the lagging distro packages.
Next, point a domain or subdomain (e.g. db.yourdomain.com) at your server IP with an A record. This is for HTTPS: Studio and the API gateway should never face the public internet over plain HTTP. While DNS propagates, lock down the firewall: Hostinger’s hPanel firewall plus UFW on the server. Open only 22 (SSH), 80, and 443 to the world; keep the database port and Studio behind SSH tunnels or a VPN.
Finally, decide your backup destination before installing anything. Cheapest reliable options: off-site object storage or a second cheap VPS in another region. Backups on the same disk as the database are not backups. Write the plan down now.
Step 2: Install Supabase with the Official Docker Setup
Two install paths end in the same place. The quick-start script is fastest on Ubuntu/Debian: one command installs Docker if missing, fetches the Compose config, generates all secrets (JWT keys, dashboard password), and prompts for your site URL. Inspect the script before piping it to sh; it is in the official supabase/supabase repository under docker/setup.sh. If you run automation on the same box, our n8n VPS guide covers a common companion workload.
Prefer control? Clone the repository, copy the example environment file, and generate secrets manually with openssl. Either way, the critical variables are your site URL, JWT secret, Postgres password, and the anon/service_role keys derived from it. Get these wrong and Auth misbehaves confusingly, so verify before the first boot.
Start the stack with docker compose up -d and watch the logs. The first pull downloads roughly a gigabyte of images; allow a few minutes. When every container reports healthy, open Studio and log in with the generated credentials. Create a test table in Studio, copy the anon key, and point your app’s client at your domain. If sign-up and a simple query work, the core install is done.
Step 3: Secure Your Self-Hosted Supabase (Do Not Skip This)
A default install is not production-ready, work through this checklist before storing real user data. First, replace every default secret: if you used the manual path with example values, rotate them now. Second, change the Studio password and put Studio behind a VPN or IP allow-list, not the public internet, it is an admin interface with direct SQL access.
Third, terminate HTTPS at a reverse proxy (Caddy or Nginx) in front of Kong with auto-renewing certificates. Studio, Auth callbacks, and the REST API all break subtly over plain HTTP. Fourth, review Row Level Security: the anon key is public by design, so any table without RLS policies is world-readable. Fifth, disable public sign-ups in GoTrue if unneeded, and configure SMTP so Auth emails arrive.
Finally, keep the host patched: enable unattended security upgrades on Ubuntu and follow Supabase release notes. Self-hosted does not auto-update; running a year-old Postgres with known CVEs is how breaches happen. Treat security as an ongoing process, not a one-time step.
Backups for Self-Hosted Supabase: What Actually Works
Supabase Cloud sells point-in-time recovery. Self-hosted, backups are your job, and the naive approach misses things. A complete backup has three parts. First, the database: nightly pg_dump in custom format via cron, at least 7 daily and 4 weekly copies off-site, and a tested restore every quarter. An untested backup is a hope, not a plan.
Second, the Docker volumes: Postgres data and Storage files live in bind mounts on the host. Copying them while Postgres runs risks inconsistency, so stop the stack briefly or rely on pg_dump and copy only the storage directory. Third, most often missed: Storage files carry metadata in extended attributes, archive with tar --xattrs or they restore broken.
Hostinger's VPS includes free weekly backups and one manual snapshot, good against host failure, but they cannot restore a single table. Use both: automated pg_dump to off-site storage for granular recovery, plus provider snapshots for disaster recovery. For plan details see our Hostinger pricing overview.
How to Self-Host Supabase on a VPS vs Using Supabase Cloud: Honest Trade-offs
Run the numbers honestly. Supabase Cloud Pro is a paid tier with managed backups, point-in-time recovery, and support. A KVM 2 VPS on a long term costs less per month (see the live deal cards; we never print prices in prose), plus your time for operations. If the server already exists for other workloads, the marginal cost of Supabase is near zero and self-hosting wins easily.
Time is the real price. Budget a few hours for setup and hardening, then ongoing attention: monthly updates, backup monitoring, the occasional incident managed hosting would have absorbed. If you would rather ship features than babysit Postgres, Cloud is the better deal. Need data residency in a specific country, predictable flat-rate billing at scale, or full control? Self-hosting earns its keep.
When not to self-host on a Hostinger VPS: if you need Windows (Linux-only), want a managed database with an SLA, or nobody on your team is comfortable on the Linux command line. In those cases, Supabase Cloud or a managed Postgres provider is the honest pick. Everyone else can follow the steps above and be running today.
| Option | vCPU / RAM | NVMe storage | Verdict for Supabase |
|---|---|---|---|
| Hostinger KVM 1 | 1 vCPU / 4 GB | 50 GB | Meets the official minimum. Fine for development or one quiet project. |
| Hostinger KVM 2 | 2 vCPU / 8 GB | 100 GB | Hits the recommended spec. The sensible pick for production use. |
| Hostinger KVM 4 | 4 vCPU / 16 GB | 200 GB | Headroom for heavy workloads or several services on one box. |
| Supabase Cloud Pro | Managed | Managed | $25/mo with backups, PITR, and support. Zero ops work. |
VPS KVM 1
24-month plan, paid upfront
Renews at $11.99/mo
- 1 vCPU + 4 GB RAM
- 50 GB NVMe storage
- 4 TB bandwidth
- Full root access
- Dedicated IPv4 + IPv6
FAQ
The official minimum is 4 GB of RAM with 2 CPU cores, and 8 GB with 4 cores is recommended for anything beyond development. Operators report the 11-container stack idles near 1.5 GB used on a 4 GB box, leaving limited headroom. A 2 GB VPS boots it but struggles under load, and 1 GB does not run it. Plan for 4 GB minimum, 8 GB for production.
It depends on your time. Supabase Cloud Pro costs $25 per month with managed backups and support included. A VPS meeting the recommended spec costs less per month on a long term, plus your hours for setup, updates, and incidents. If the server already exists for other workloads, the marginal cost is near zero and self-hosting wins. If you bill your own time, Cloud is usually cheaper.
No. Supabase requires Docker containers, persistent background processes, and root-level control over the server, none of which shared hosting provides. You need a VPS with full root access, such as Hostinger's KVM plans, or a dedicated server. Shared plans like Premium or Unlimited are built for websites, not containerized backends.
No. Postgres data and Storage files live in bind mounts on the host, so stopping the containers leaves your data on disk. However, that is not a backup strategy. You still need scheduled pg_dump exports and off-site copies of the storage directory, because a disk failure or an accidental volume removal would destroy everything.
The database, Auth, Storage, REST and Realtime APIs, and Studio are the same open-source code. What you lose are the managed extras: point-in-time recovery, read replicas, database branching, the hosted logs and analytics platform, and support. You also run one project per stack and handle upgrades, monitoring, and security patching yourself.