[{"data":1,"prerenderedAt":16},["ShallowReactive",2],{"$fSkghC2CbCbmanHl2JNNYk4od3MT4xnBgVERUPX4zj8Y":3},{"slug":4,"title":5,"description":6,"date":7,"tags":8,"draft":13,"readingMinutes":14,"html":15},"self-host-supabase","Self-Host Supabase: What You Take On","How to self-host Supabase with Docker in 2026: server size, the one-command setup, what you lose (PITR, branching, backups) and when it's worth it.","2026-10-20",[9,10,11,12],"supabase","self-hosting","postgres","devops",false,4,"\u003Cp>To self-host Supabase, you run its Docker Compose stack on a Linux server: Supabase's docs ask for at least 4 GB of RAM, 2 cores and 40 GB of SSD (8 GB and 4 cores recommended), and a quick-start script, \u003Ccode>curl -fsSL https://supabase.link/setup.sh | sh\u003C/code>, installs Docker, generates every secret and pulls the images. What you give up is the managed platform: no branching, no managed backups or point-in-time recovery, one project per install, and you're on call for the database.\u003C/p>\n\u003Cp>That second sentence is the one people skip. Getting self-hosted Supabase running takes an afternoon. Keeping it running for two years is the actual job.\u003C/p>\n\u003Ch2>What you get when you run it yourself\u003C/h2>\n\u003Cp>The stack is the same open-source pieces that power supabase.com: Postgres, Auth (GoTrue), PostgREST for the auto-generated API, Realtime, Storage with imgproxy, the Edge Runtime for functions, Supavisor for connection pooling and Studio as the dashboard. An API gateway (Envoy, in the current compose file) sits in front and listens on port 8000, so your app talks to \u003Ccode>https://your-domain/rest/v1/\u003C/code>, \u003Ccode>/auth/v1/\u003C/code>, \u003Ccode>/storage/v1/\u003C/code> and so on, exactly like it talks to a hosted project. Swap the URL and keys in your client and most apps don't notice the difference.\u003C/p>\n\u003Cimg src=\"/blog/self-host-supabase/self-hosted-supabase-stack.webp\" alt=\"Self-hosted Supabase stack on one server: the Envoy gateway in front of Auth, PostgREST, Realtime, Storage, Edge Runtime and Studio, all on one Postgres, with the jobs you now own marked\" width=\"1600\" height=\"900\" loading=\"lazy\">\u003Cp>The setup script is genuinely good now. It asks for your public URLs (\u003Ccode>SUPABASE_PUBLIC_URL\u003C/code>, \u003Ccode>API_EXTERNAL_URL\u003C/code>, \u003Ccode>SITE_URL\u003C/code>), writes them into \u003Ccode>.env\u003C/code>, generates the JWT signing keys and a random \u003Ccode>DASHBOARD_PASSWORD\u003C/code>, and leaves you with \u003Ccode>sh run.sh start\u003C/code>. It records the release in \u003Ccode>.supabase-version\u003C/code> so \u003Ccode>update.sh\u003C/code> can upgrade you later. If you'd rather see every step, the \u003Ca href=\"https://supabase.com/docs/guides/self-hosting/docker\">Docker guide\u003C/a> has the manual path, pinned to a release tag (\u003Ccode>self-hosted/v0.8.3\u003C/code> when I checked on October 20, 2026).\u003C/p>\n\u003Cp>One thing I'd do on day one that the quick start doesn't force on you: put the stack behind a reverse proxy with TLS and keep Studio off the public internet. Studio is protected by a username and password from \u003Ccode>.env\u003C/code>. That's fine on a private network and a bad idea on a public IP.\u003C/p>\n\u003Ch2>What you lose\u003C/h2>\n\u003Cp>Supabase's own \u003Ca href=\"https://supabase.com/docs/guides/self-hosting\">self-hosting page\u003C/a> is honest about it. Not available when self-hosting: branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL and the Management API. Studio runs a single project, with no organizations. Logs and analytics are off by default and come back with an optional compose override that needs more memory.\u003C/p>\n\u003Cp>The list of things that become yours is longer than the list of features you lose: server patching, Postgres upgrades, backups and restores you've actually tested, monitoring, uptime, scaling. Self-hosted Supabase is community-supported, so when an upgrade goes sideways at midnight there's no support ticket to open.\u003C/p>\n\u003Cp>Backups are where I'd spend the most time. On the hosted platform, point-in-time recovery is an add-on at about $100 a month for 7 days of retention. Self-hosted, you build it: WAL archiving with something like pgBackRest or WAL-G to object storage in another provider, plus a nightly \u003Ccode>pg_dump\u003C/code> you restore somewhere every week to prove it works. A backup you've never restored is a guess.\u003C/p>\n\u003Ch2>Does it save money?\u003C/h2>\n\u003Cp>Sometimes a lot, sometimes nothing. Supabase Pro is $25 a month with $10 of compute credit, so a single small project costs about $30. A server that meets the recommended spec (8 GB, 4 cores) costs around €10 to €35 a month at Hetzner after their June 2026 price changes. On a single small project the saving is a few dollars, and you just took on a job.\u003C/p>\n\u003Cp>It changes when the hosted bill grows: several projects each paying for their own compute, a Large or XL instance at $111 to $210 a month, PITR, heavy egress. Then one well-sized server can be far cheaper. My rule of thumb: if the hosted bill is under about $100 a month, stay hosted and spend the time on your product. Over a few hundred, self-hosting is worth a serious look, as long as somebody on the team is happy to own Postgres.\u003C/p>\n\u003Ch2>When I'd self-host anyway\u003C/h2>\n\u003Cp>Money isn't the only reason. Data that legally has to stay in one country or on hardware you control. A client who doesn't want to depend on a US provider at all. An internal tool on a private network with no public endpoint. An app that's moving to European infrastructure, where the database can sit next to everything else on the same box.\u003C/p>\n\u003Cp>And when I wouldn't: an early-stage product with real users, no ops person and a founder who'd rather sleep. Supabase's hosted platform is good at exactly the boring things that hurt most when they fail.\u003C/p>\n\u003Cp>If your Supabase bill is the reason you're reading this, I'd look at what's driving it first. The usual suspects are spare projects and add-ons, and fixing those is cheaper than moving. If you want a second pair of eyes on a self-hosting plan or the migration itself, \u003Ca href=\"https://calendly.com/director-norsky/meeting\">book a free call\u003C/a>.\u003C/p>\n",1792539613588]