Supabase Self-Hosting 2026: The Real Cost Is Not the Server

Supabase self-hosting is easy to start and expensive to own, and most of what it costs you is not money. You can have the full stack running on a server in an afternoon. Keeping it running in production is a different job, and it is the one nobody prices for you.

If you are reading this, you have probably already made up your mind about Supabase Cloud. The reason is usually one of three: the bill, where the data sits, or the fact that every new project is another billed project. This is not a setup tutorial. Supabase’s docs handle that.

We build Selfhost.dev, which runs the open-source Supabase stack on servers we provision, for teams that want self-hosting without the server. That puts us on the far side of this decision. We see what people were escaping when they left Cloud, and what they ran into when they tried Docker Compose first. The numbers below come from that. Everything else is sourced from Supabase’s own GitHub discussion on self-hosting, which their maintainers run and which was still being added to this month.

By the end, you will know what the server actually costs, what the self-hosted dashboard cannot do, and which of the two ways to run Supabase fits your situation.

Self-hosting Supabase is not the same as running it locally

supabase start is not self-hosting. That command runs the Supabase CLI’s local development stack, which exists for building and testing on your own machine, is not hardened for production, and must never be exposed to external traffic. Self-hosting means something else entirely: the open-source Supabase stack running through Docker Compose on a server you own and maintain.

The two are configured in completely different places. The CLI reads config.toml. A self-hosted deployment reads .env and the Docker Compose files, and neither the CLI nor Studio gives you an API to change those settings for you. Supabase’s maintainers correct this confusion regularly in their own self-hosting discussion, most recently this month, which tells you how often people arrive at it the hard way.

What you actually run when you self-host is the whole open-source Firebase alternative, not just a database: Postgres, Auth (GoTrue), PostgREST for the auto-generated API, Realtime, Storage, the Studio dashboard, and an API gateway in front of all of it.

That gateway changed in August 2026. Envoy is now the default in docker-compose.yml, with Kong kept as a legacy option. If a guide you are following still describes Kong as the gateway, it was written before this month.

That is seven services to run one product, which is worth holding onto as a benchmark. When we ranked eight open source CRMs by what each needs underneath it, the heaviest one on the list was the one that asks for this entire Supabase stack just to run a sales pipeline.

Supabase self-hosting requirements for production

Getting Supabase running takes minutes. Running it in production is a different job, and it is the one you are signing up for. Self-hosting Supabase makes you responsible for six things: the server, Docker and Docker Compose, your own secrets, a reverse proxy with TLS, patching, and every upgrade from here on.

In order:

1. A server, provisioned, hardened, and yours to keep alive.
2. Docker and Docker Compose, installed and kept current.
3. The cloned repo and a real .env: your own JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, and POSTGRES_PASSWORD, not the example values.
4. A reverse proxy with TLS in front of it, NGINX, Caddy, or Traefik.
5. OS and container image patching, on a schedule you set.
6. Every version upgrade, including the breaking ones.

Supabase’s own Docker documentation says this should take under fifteen minutes. That is true, and it is also the wrong measurement. Fifteen minutes is docker compose up -d on a laptop.

The production version reads differently. In Supabase’s own GitHub discussion in November 2025, an infrastructure architect described spending two weeks on CloudFormation and shell scripting to run the stack against AWS RDS. A Supabase maintainer replied that this was “really true, unfortunately” and “a very tedious process indeed.” Two weeks is the hard case, an RDS-backed deployment rather than the standard Compose file.

Nobody in that thread is putting it at fifteen minutes either. Two other reports in the same November 2025 thread: a full day of debugging, and two deployments that crashed and burned.

The recurring complaint there is not setup at all. It is upgrades. Postgres 17 became the default in June 2026, with an explicit warning not to start it on an existing Postgres 15 data directory. Envoy replaced Kong as the default gateway in August 2026. A one-command update.sh only arrived recently. Each of those is manageable on its own, and each one lands on you.

To be fair to Supabase, they hired an engineer dedicated to self-hosting in October 2025 and have shipped steadily since. The burden here is operational, not neglect.

Most guides stop before the part that decides your bill: what does the server need? The figure quoted most often, including in Google’s AI summary of this question, is 4 GB of RAM. Practitioners in Supabase’s own forum are less generous. One runs seventeen containers on a 2 vCPU, 4 GB box and reports Realtime idling near 200 MB and the gateway near 230 MB. A production team runs 4 vCPU and 16 GB.

So there are three answers, not one, and here is what each costs on Selfhost.dev:

Those are Selfhost.dev’s prices, billed by the hour with no plan fee on top. If your workload sits between two of those sizes, the calculator will price both on your own hours.
Price both sizes on your own hours →
No signup, no card.

Supabase self-hosting cost: server, time and maintenance

Self-hosting Supabase does not save money on a small project. It starts saving when you need more than one project, when usage-based billing outruns a flat server, or when the data has to sit somewhere specific. Below that line, you are trading dollars for hours, and the hours cost more.

Supabase Cloud starts at $25 a month (₹2,190) on the Pro tier. What that figure actually buys you is a longer conversation, and we have written it up separately: what Supabase Cloud’s $25 tier really includes.

The self-hosted number has two halves. The server is the easy half, $14 to $43 a month, depending on which of the three sizes above your workload needs. The other half is engineer time, and it never appears on an invoice. The two weeks in the last section was one architect on one deployment. Even a clean install is a day, and upgrades come round several times a year.

Put those together and the arithmetic does not favour self-hosting at the small end. A twenty-something-dollar monthly bill is not worth the support burden that replaces it. One developer, one project, no particular constraint: the DIY route costs you more than it saves.

A developer who rebuilt the stack from scratch reached the same place in Supabase’s GitHub discussion this March. He had wanted, in his words, to “understand what the managed service actually does before paying for it.” His conclusion was two words: “Turns out: a lot.”

Supabase Cloud vs self-hosting: which one fits you

Three things flip the calculus, and it only takes one of them. Google’s own summary of this question asks readers those same three, which is a fair sign they are the ones that matter.

Scale and project count. Supabase Cloud bills the plan once per organisation and compute per project, and the Pro plan’s $10 credit covers only one instance. The second and third projects add about $10 a month (₹877) each. One server holds several. The moment you need staging, a client build, and something of your own, the flat-server maths starts winning.

Compliance and data residency. If the data has to stay inside the EU, a European server answers that directly. If it has to sit in a specific region elsewhere, that is a managed database question rather than a Supabase-template question, and it is worth separating the two early.

DevOps capacity. Not whether someone on the team can run upgrades, but whether anyone wants to. Postgres 17 and the Envoy switch both landed in the last three months. Somebody owns the next one.

None of that is a technical judgement, though. It comes down to which of these two readers you happen to be.

Self-hosting is probably right for you if:

• You are running more than one project, or staging alongside production.
• Your data has to stay in a particular jurisdiction.
• Somebody on the team already maintains infrastructure and does not mind maintaining more of it.

Supabase Cloud is probably right for you if:

• You are building your first product, and shipping speed matters more than control.
• Nobody on the team wants to own upgrades and patching.
• Your bill is not yet large enough to be worth a weekend of work.

If you landed in the second list, stop here. Cloud is doing its job, and moving would cost you more than it saves.

If you landed in the first, you have already settled the interesting part. What remains is who runs the server, and there is a third answer: the same open-source stack, on a machine somebody else provisions, patches and keeps alive. Your Postgres, your .env, and no Compose file to maintain.

Limitations of the self-hosted Supabase UI (Studio)

Self-hosted Supabase Studio has no role-based access control. Anyone who can reach the dashboard URL has full admin access to your database, and the accepted fix is not user permissions but network-level restriction: a VPN or an IP allowlist.

Studio ships inside the Docker Compose stack and answers on port 8000 by default, behind HTTP basic auth. The credentials in .env.example are, verbatim:

DASHBOARD_USERNAME=supabase
DASHBOARD_PASSWORD=this_password_is_insecure_and_should_be_updated

Change both before that server sees public traffic. Worth noting that Google’s AI summary of this question currently prints that password incorrectly, so if you copied it from a search result rather than the repo, check it.

The deeper problem is not the password, though. It is that there is only one of them. In Supabase’s GitHub discussion this April, a developer running multi-tenant backends put it plainly: self-hosted Studio has no RBAC, so anyone with the URL has admin access, and you defend it with network controls instead. Six months ago, r/netsec carried another exposed Supabase database with full write access.

The dashboard also cannot configure connection pooling. That is on record in the same discussion in November 2025, where the settings simply are not present in current self-hosted Studio, and you change them in files instead. It matters sooner than people expect because the stack consumes more than fifty Postgres connections before your application opens its first one. Point the stack at a managed Postgres with PgBouncer pooling included and it becomes a console setting instead of a file edit.

The full list of what a self-hosted dashboard will not change for you:

• Connection pooling. Not in the UI.
• Auth providers. Google, GitHub, and the rest are environment variables.
• SMTP and email templates. Environment variables and container files.
• Storage bucket limits. Environment variables.
• Anything about the server. Size, patching, backups, restores.

Those split into two groups, and the distinction matters. Auth providers, SMTP templates, and bucket sizes are Supabase application configuration, and they stay file edits on any platform, ours included. What a managed console changes is the other half: the instance itself, pooling, backups, database users and their roles, scaling, and team access with real permissions.

A screenshot only proves it exists. The quicker test is to open the permissions screen and the PgBouncer settings yourself and change something.
See the screens Studio doesn’t have →
Fully interactive, no signup and no card.

Can you run multiple projects on one self-hosted Supabase?

No. Self-hosted Supabase runs as a single project, and Studio does not support multiple organisations or projects. There are three ways around that, and which one is right depends on whether you have several distinct projects or one product with many tenants.

Separate Docker stacks. One directory per project, each with its own API_GW_HTTP_PORT and matching SUPABASE_PUBLIC_URL so the ports do not collide, its own JWT_SECRET and POSTGRES_PASSWORD, its own volume paths, and a reverse proxy routing each domain to the right port. Complete isolation, and complete duplication of the work.

A managed control plane. Something that provisions those isolated stacks for you, assigns the networks, issues the certificates, and routes the domains. The per-project work does not disappear. It stops being yours.

Multi-tenant schemas in one instance. Separate Postgres schemas, Row Level Security, and a tenant_id on every table. If you are building one SaaS product with many customers, this is the right answer and the cheapest one because the compute is shared. It is not the right answer for three unrelated projects.

If the middle column is the one you want, that is self-hosted Supabase on a managed server.

Do the arithmetic before you choose. On Supabase Cloud, three environments is one subscription plus three compute bills, about $45 a month on Micro instances.

Three stacks on one server is still one server until you outgrow it, and that difference is where per-project billing stops being predictable and starts being something you have to forecast.

Managed self-hosting: how to run Supabase without managing the server

You can run the full open-source Supabase stack on a server you never have to provision, patch, or keep alive. The stack is still yours, and the data is still yours. The Docker Compose file, the reverse proxy, and the TLS renewals become somebody else’s problem.

Five steps, none of which involve Docker:

1. Create a project, and a dedicated server is ready in minutes.
2. Add the Supabase template in one click.
3. Set your environment variables or paste the .env you already have.
4. Point a domain and get HTTPS automatically.
5. Connect your app.

You get the whole stack, Postgres, Auth, Storage, Realtime, and the API gateway with auto-generated REST APIs, not just the database.

From $0.02/hr (₹2/hr), about $14 a month (₹1,228) on the smallest server, roughly $0.48 a day.

Two things people ask at this point, both fairly.

Is this just lock-in again? It is the open-source Supabase stack, not a fork and not a wrapper. Your data sits in a Postgres you can dump, your configuration is an .env you already hold, and the server is dedicated, with full logs and metrics rather than a shared black box. All of it travels if you leave.

Why not a free self-managed panel? A panel gets you the same one-click install. It does not get you out of the upgrades, the patching, or the incident at three in the morning. That is the line you are choosing across.

One honest limit: project servers sit in three EU locations today, Germany and Finland, and the platform places you in an available one rather than letting you pick. If your data has to sit in a specific region elsewhere, that is the managed PostgreSQL product rather than this template.

A developer in Supabase’s GitHub discussion this May summed up why people arrive here. He got a self-hosted stack running and still “wasn’t confident enough to use it for production.”

If you are already running a DIY stack, the move is the part nobody should do alone. Send us what you have today and an engineer will plan the migration with you, free whether or not you go ahead. If you would rather just start, deploy the template. No card, billed by the hour, and stopping the server stops the bill.

So should you self-host Supabase?

Self-hosting Supabase is worth it when you need control over the stack, more than one project, or your data in a particular place. That part is settled by your situation rather than by anyone’s opinion. The only genuinely open question is whether you also want to own the server.

Own it yourself if you have real DevOps capacity, want your hands on every container, and treat the upgrades and patching as a fair price for that. Plenty of teams make that choice and make it well.

Take the managed path if you want that control without also owning the machine it runs on.

The choice was never self-hosted or cloud, though. It is control versus operational ownership, two different things that tend to get bought together by accident. Supabase’s open-source stack hands you the control. Whether you also take on the operations is a separate decision, and it deserves to be made deliberately rather than discovered in month four.

Not sure which side of that line you are on? Describe what you run today and we will cost out both paths for you, at no charge.

Frequently asked questions