Supabase Self-Hosted vs Cloud: The Free Part Is Not the Expensive Part

Self-hosted Supabase is the same core software as the managed version, minus the parts that only make sense as a service — and minus the operations team. The software is free. Backups, upgrades, TLS, monitoring and being awake at 3am are the price.

The comparison usually gets framed as a price question, which is the least interesting part of it. A stack you run yourself and a stack somebody runs for you differ mostly in who absorbs the failures. That is worth deciding deliberately, because the answer changes as a project grows and it is much easier to choose at the start than to migrate later.

Table of contents

• What you actually get in each
• The cost comparison people run, and the one they should
• When self-hosting is the right call
• The unbundling question
• If you do self-host, do these five things first
• How this fits the rest of the stack
• FAQ

What you actually get in each

The self-hosted distribution ships as a Docker Compose stack, and it is not one thing. It is Postgres, plus a REST layer generated from your schema, plus an auth service, plus a storage service, plus a realtime server, plus an API gateway, plus a studio UI, plus a connection pooler, plus supporting pieces. Roughly a dozen containers that have to agree with each other.

The project’s own guidance is that self-hosted is close to the managed version but may lag on the newest features, and that everything essential is there. That is a fair summary.

What is genuinely absent or diminished when you self-host:

• Automated backups with point-in-time recovery. You get Postgres. You configure pg_dump, or WAL archiving, or a backup tool, and you test restores yourself.
• Managed upgrades. Component versions have to move together. A stack that has drifted six months behind is a stack where upgrading is a project.
• Read replicas and connection pooling at scale. Available, and now your problem to configure.
• Log retention and dashboards beyond what you set up.
• Email delivery. The bundled mail configuration is for development. Real auth emails need a real provider and correct SPF, DKIM and DMARC records, or your magic links land in spam.

None of that is unreasonable. It is simply the list of things a managed service is charging for, made explicit.

The cost comparison people run, and the one they should

The arithmetic that makes self-hosting look obvious goes: the managed plan is a monthly subscription, a virtual server with adequate memory is cheaper, therefore self-host and save the difference.

The arithmetic that survives contact with production adds:

• A second machine, or a plan to lose data. One server with one disk is a single point of failure holding your users’ data.
• Backup storage, somewhere other than that machine. A backup on the same disk as the database is not a backup.
• A staging environment, because upgrading a dozen coupled containers directly in production is not a strategy.
• Monitoring and alerting, so a full disk is a notification rather than an outage.
• Time. Initial setup, then a recurring maintenance cost — upgrades, certificate renewals, capacity, the occasional container that dies at an inconvenient hour.

That last line is the one that decides it. At a developer’s hourly rate, even two hours a month of maintenance usually exceeds the subscription being avoided. If those hours are yours and you would have spent them learning this anyway, the calculation is different — but count them rather than assuming they are free.

The honest version: self-hosting is cheaper in money and more expensive in attention. Which resource you have more of is a real question, and the answer changes when a project starts earning.

When self-hosting is the right call

There are good reasons, and they are mostly not about price.

• Data residency or regulatory constraints that a managed region does not satisfy. This one is not negotiable when it applies.
• Air-gapped or on-premise deployment, where an external service is not an option at all.
• You already operate Postgres in production. If you have backups, monitoring, an upgrade process and someone who knows what a WAL is, you are adding services to an existing competence rather than acquiring a new one.
• Development and CI environments. Running the stack locally for tests is genuinely useful and carries none of the production burden.
• Learning. Standing it up teaches you what the managed version is doing, which makes you better at using either.

And the reasons that look good and are not: wanting to avoid vendor lock-in (self-hosting the same software is the same software), expecting better performance from a single box (usually true until the first traffic spike), and wanting more control (you get it, along with the responsibility it implies).

The unbundling question

Underneath the packaging, the core of what you are running is Postgres. The rest is a REST layer over your schema, an auth service, a storage service and a realtime channel — each of which is a well-understood component with alternatives.

That prompts a question worth asking before committing to either side: do you want a bundle, or do you want the pieces?

The bundle wins when you are moving fast, the schema is the application, and generated APIs plus row-level security cover your authorisation needs. A prototype that needs auth, storage and a database by Friday is exactly the case it was designed for.

The pieces win when your business logic is substantial. Row-level security is expressive, and it is still SQL policies — complex multi-tenant authorisation, workflows with state, or anything requiring a transaction across several operations is easier to write, test and review as ordinary application code.

The realistic path for a lot of projects is both, in sequence: start with the bundle, and as the logic grows, move it into a backend service that talks to the same Postgres. The database does not have to move for that to happen, which is the good news — a Postgres is a Postgres, and your data is portable in a way that a proprietary datastore’s would not be.

If you do self-host, do these five things first

1. Change every default credential. The stack ships with defaults — the JWT secret, the anon and service keys, the database password, the studio login. A default JWT secret means anyone can mint a token that your API trusts completely. Regenerate all of them before the machine touches the internet.
2. Put Postgres behind a firewall. The database port should be reachable from your application and from nowhere else. This is the single most common way a self-hosted database ends up in a breach report.
3. Set up backups and restore one. A backup you have never restored is a hypothesis. Restore into a scratch environment and confirm the data is really there.
4. Configure real email. The bundled mail setup is for development. Auth emails need a provider plus SPF, DKIM and DMARC, or password resets silently fail for a fraction of your users.
5. Pin your versions and keep a staging copy. Upgrading a dozen coupled containers in production without rehearsal is how a maintenance window becomes an outage.

The first two are the ones that show up in incident write-ups. They take fifteen minutes and they are skipped constantly, because the stack works fine without them right up until it does not.

How this fits the rest of the stack

The pattern worth noticing is that most of the self-hosting burden is not the interesting software — it is Postgres operations, TLS, backups and a place for a process to run. Those are the parts that repay being handed off, and they are the parts that stay the same no matter which bundle sits on top.

RunxBuild covers exactly that layer. Managed MySQL and Postgres come with backups, user management, connection limits and private networking, so the database is not exposed to the internet and the backup story is not a script you wrote once. Web services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from your GitHub repository beside them, with environment variables, build and runtime logs in one place, rollback to the previous deploy, and autoscaling between a floor and ceiling plan you choose. Your application logic stays yours; the operating stops being your evening. To see what a service, a managed database and storage come to together, the RunxBuild hosting calculator lists them as separate line items.

Useful related references:

• Firebase vs Supabase: Document Store or Postgres, and What That Costs You Later
• Self-Host n8n on Hostinger: A Step-By-Step Runbook
• Railway n8n: What to Check Before You Self-Host Workflow Automation
• Services on RunxBuild

FAQ

Is self-hosted Supabase the same as the cloud version?

Close, but not identical. The core is the same open-source software and the project describes self-hosted as including everything you need, while noting it may lag on the newest features. What is genuinely missing is the managed layer: automated backups with point-in-time recovery, coordinated upgrades, log retention, and production email delivery.

Is self-hosting actually cheaper?

Cheaper in subscription, more expensive in attention. A realistic comparison has to include a second machine or accepted data-loss risk, off-host backup storage, a staging environment, monitoring, and recurring maintenance time. At a developer’s hourly rate, a couple of hours a month usually exceeds the plan you avoided.

When does self-hosting make sense?

When data residency or an air-gapped environment requires it, when you already operate Postgres in production and have backups and monitoring in place, or for development and CI environments where the production burden does not apply. Avoiding lock-in is not a good reason, since it is the same software either way.

What should I secure first on a self-hosted instance?

Regenerate every default credential — especially the JWT secret, since a default one lets anyone mint tokens your API will trust — and put the Postgres port behind a firewall so only your application can reach it. Those two steps take fifteen minutes and are the ones that show up in incident write-ups when skipped.

Can I move my data out later?

Yes, and this is the genuine advantage of a Postgres-based stack. Your tables are ordinary Postgres tables, so a dump and restore moves them anywhere Postgres runs. What does not travel is the generated API layer and the auth service, so plan for rewriting those against your own backend rather than for a lift-and-shift.