Self-Hosted Supabase: What You Have to Operate

Running Supabase on your own server makes your team responsible for the database, authentication, file storage and supporting services. Decide who tests backups, applies updates, handles incidents and protects access keys. It can suit control or data-location requirements. Compare the operational workload with managed hosting before choosing it.

I've run self-hosted Supabase in production and migrated teams onto and off of it. This is the honest ledger.

Legitimate reasons to self-host

There are real ones. Data locality: in one healthcare deployment I built, patient-adjacent data wasn't allowed to leave the facility, full stop. The stack ran on a server inside the building, and no managed offering could satisfy that constraint. Regulated industries and government work in Indonesia raise the same wall more often each year.

On-prem mandates: some clients simply require that systems run on infrastructure they control. Cost at scale: at some sustained workloads, infrastructure you administer can cost less than a managed tier; include staffing and recovery costs in that comparison.

And there's the illegitimate reason: saving twenty-five dollars a month. If the motivation is a hobby-tier invoice, the ops time will cost more than the subscription ever would.

What the stack actually contains

"Supabase" is not one service. The self-hosted compose file brings up Postgres, GoTrue for auth, PostgREST for the instant API, the Realtime server, the Storage API with an image proxy, Kong as the gateway, Studio, an analytics service, and an edge-functions runtime. A dozen containers, each with its own configuration, logs, failure modes, and release cadence.

Think of self-hosting as building your own house — your own plumbing, wiring, and roof — instead of renting a move-in-ready apartment. You're not adopting a database. You're adopting a platform team's worth of services, minus the platform team.

Backups become your job — and buckets count

Managed hosting provides database backups according to the plan, but Supabase backups do not include Storage objects. Files need their own protection under either hosting choice. Self-hosting also makes you operate the entire backup process; the mistake I see most often is scoping it to Postgres alone.

Storage buckets don't live in the database. The Storage API keeps object metadata in Postgres but writes the actual files to a disk volume or an S3-compatible store. Back up only the database and your restore will come up with every bucket intact — as rows pointing at files that no longer exist. The file volume must join the backup scope, and it must be captured consistently with the database dump, or restored metadata and restored files drift apart.

And a backup that has never been restored is a rumor. Restore drills on a schedule are non-negotiable — I've written up the practice in verifying Postgres backups, and it applies doubly here because there are two stores to bring back in step.

Upgrades and monitoring are now yours too

On the managed platform, upgrades happen to you. Self-hosted, an upgrade is a project: a dozen images whose versions must stay mutually compatible, release notes to read, a maintenance window to schedule, and a rollback plan for when auth behaves differently afterwards. Pin every image version explicitly — latest in production is how surprise upgrades happen at 3 a.m.

Monitoring follows the same logic. Disk growth on the database and the file volume, connection-pool saturation, container restarts, certificate expiry — nobody is watching any of it unless you wired the watching yourself.

The security surface

The compose stack is a set of internal services fronted by Kong, and that topology is a security decision: only the gateway belongs on the network edge. Postgres, GoTrue, PostgREST, and Storage should be unreachable from outside — every port you expose beyond the gateway is attack surface you volunteered for.

With the legacy JWT-secret configuration, anon and service-role keys derive from that secret. Clients can use the anon key with appropriate data-access policies. The service-role key belongs only on a trusted backend: it can bypass Row Level Security (RLS), the rules restricting access to individual rows. Never expose it to browsers or user applications. Rehearse rotation for your signing-key mechanism and stack version; replacing a legacy JWT secret requires coordinating tokens and derived keys.

Keep secrets in an environment manager, never in a compose file that reaches git. The default secrets in the sample configuration exist to be replaced before the first deploy, not after the first incident.

When managed hosting is the honest recommendation

If nobody on the team will own this — genuinely own it, with backup drills and upgrade windows and monitoring on a dashboard someone actually looks at — the managed platform is the correct answer, and I say so in assessments even when a self-hosting contract would pay better.

The true cost of self-hosting is denominated in people, not servers. It can be the right call when data-location requirements, control, or scale justify the operational work. It's an expensive hobby when it's chosen for the compose file's one-command charm.

Either way, what you build on top doesn't change — the applications and dashboards that connect these systems neither know nor care where the stack runs. Choose with the ledger open: locality, control, and cost on one side; backups, upgrades, monitoring, and secret discipline on the other. Both sides are real.