Self-hosting Supabase: what the paid plan was quietly doing for you

Supabase gives you a lot for very little effort: Postgres, auth, storage, realtime, an admin dashboard. The managed version also gives you something you don’t notice until it’s gone: someone else doing operations.

I moved a healthcare platform from managed Supabase to a self-hosted setup on a dedicated server. It was the right decision for that client. It was also a reminder that “self-hosted” really means “you are now the platform team”.

Why you might self-host

There are good reasons:

• Data residency. Your data must live in a specific country, or regulations say you can’t use certain providers.
• Cost at scale. Usage-based plans grow with you. If you’re upgrading every few months as data and traffic grow, a fixed-price server can be cheaper.
• Control. You decide versions, upgrade timing, network layout and who can reach what.

For the healthcare client, the first reason decided it: everything had to be hosted in the UK, on a provider that wasn’t US-headquartered. The second reason was a welcome side effect, since they’d been upgrading plans every two or three months.

What the managed plan was doing for you

Before you move, list every job the platform was doing silently. On paid plans that usually includes:

Job	Managed	Self-hosted
Database backups	Automatic	You script, schedule and test them
Point-in-time recovery	Option on the plan	You set it up, or you don’t have it
Upgrades and security patches	Handled	You track releases and apply them
SSL certificates	Handled	You issue and renew them
Monitoring and alerts	Dashboard included	You build it
Server hardening	Not your problem	Firewall, SSH, users, updates
Uptime	Their on-call team	Your on-call team

None of these are hard on their own. Together they’re a real workload, and every one of them fails quietly if nobody owns it.

How I approached the migration

Docker to Docker. Supabase’s self-hosted stack runs as containers, so the move was container to container rather than a rebuild. That keeps the services the app depends on the same.

Locked down the admin side. The dashboard and database are reachable only by the developers who need them, not by the internet.

Configured every module the app uses. Auth, storage, the chat module and anything else the app relied on had to be set up and tested on the new stack. It’s easy to migrate the database and forget a module until a user hits it.

Checked row-level security, then checked again. RLS policies are your data access rules. After a migration, verify that every table that should have policies still does, and that they behave the same.

Rebuilt the paid extras as scripts. Backups, restores, monitoring, SSL renewal and hardening each became a script or Make recipe that runs on a schedule and can also be run by hand. That second part matters: when something goes wrong at 2 a.m., you want one command, not a wiki page.

What you get in return

After the move, the platform was faster for users: API responses and page loads both improved compared to the managed setup. The client stopped paying for plan upgrades every few months. And compliance was satisfied, because every byte lived where it needed to.

Should you do it?

Self-host Supabase if:

• A compliance or residency rule requires it, or
• Your managed bill is growing faster than your revenue, and
• Someone on your team, or someone you hire, will own operations

Stay managed if none of those apply. Managed Supabase is a great product. Leaving it only makes sense when the reasons are real and you’re ready to take on the work it was doing.