Self-hosting Supabase in production: what are you signing up to run?
Supabase makes it possible to run its stack on your own infrastructure. That can be exactly right when you need control over the deployment and have the people to operate it. But a Docker Compose file is the start of a production system, not the end of the job. We built Lathe for a different choice: an app, Postgres and auth on one machine, with the machine operated for you. These are not identical products. This guide helps you decide which work you want to own.
What "self-hosted Supabase" actually means
Supabase's self-hosting guide recommends Docker as the fastest route. Its Docker guide gives you the stack and a quick start, with minimum requirements of 2 CPU cores, 4 GB RAM and 40 GB SSD for all components. Those are minimums, not a capacity promise for your particular workload.
The self-hosted project isn't the hosted Supabase platform copied onto your server. Supabase says it runs as a single project, with most settings in environment variables. Managed backups and point-in-time recovery, branching, some advanced metrics, analytics, vector buckets, ETL and the platform management API are not included. Supabase also warns that the local CLI stack is for development, not a production deployment exposed to the internet.
That distinction matters if your plan is "we'll keep everything we use in hosted Supabase, only on our server." Make an inventory first: database, auth, storage API, Realtime, edge functions, dashboard workflows, backups and recovery targets. Do not assume moving the database moves the entire product.
The work after docker compose up
Self-hosting gives you control, including control of when and how you update. It also gives you the operational queue. Supabase lists server maintenance, security hardening, service configuration, database maintenance, high availability, backups, disaster recovery and monitoring as your responsibilities. Its self-hosted route is community-supported rather than managed support.
A useful pre-launch test is to ask who will do each of these things:
- Secure the public endpoints. Set real secrets, configure the public URLs, put HTTPS in front of the services and restrict the dashboard. Supabase has a separate reverse-proxy and HTTPS guide; the quick start alone is not a security review.
- Prove recovery. Schedule database and file backups, keep them away from the machine, then restore into a clean environment. Write down the maximum data loss and downtime your product can tolerate. Supabase's self-hosted edition does not include its managed backups or PITR.
- Own upgrades. Track which Docker configuration version you deployed and test changes before production. Supabase's update guide calls out configuration merge conflicts and notes that its update tool's configuration backup does not back up your database.
- Watch capacity and failures. The components share resources. Decide what happens when a disk fills, a service stops or the server disappears. A second machine, failover and off-site recovery are your design, not automatic properties of Compose.
If your team already runs this kind of system well, that control may be worth it. If this reads like an unpaid second product, compare the actual operating work, not just the server bill.
Where Lathe fits instead
Lathe doesn't host the full Supabase stack for you. We take the pieces many small products need together: your app, Postgres and sign-in on one dedicated machine, at one plan price. The underlying physical hardware is not yours. The app is a container deployed beside its database; the Auth engine uses the open-source server behind Supabase Auth, with users in the database's auth schema. The Auth endpoint follows the Supabase Auth path, so existing supabase-js sign-in calls can be pointed to its URL and anon key. Treat that as API compatibility, not a migration guarantee: existing users, OAuth provider settings, redirect URLs and tokens need testing before cutover.
You can work from the portal, REST API or MCP. We handle the machine operations, TLS, monitoring, updates and backups. The machine size bounds the workload. A larger workload may require a larger plan; "flat" is about the billing model, not unlimited capacity. We use Lathe ourselves to run lathe.live, so the deployment path is one we live with too.
The limits are as important as the convenience. One Lathe instance is one machine: no automatic failover, standby, multi-region deployment or autoscaling. The published backup policy is one daily disk backup with seven retained; a scheduled verification restores the latest backup to a temporary machine and checks the data engines. The public reliability page reports 11 passed and 2 failed restore tests in its last 90-day window, not a guarantee that every backup succeeds. A daily backup can mean losing up to a day of writes. If your product needs a tighter recovery point or high availability, do not choose this architecture merely to avoid running Compose.
We also aren't a drop-in replacement for Supabase Storage's API and policies, Realtime or Edge Functions. An app on Lathe can replace some server-side functions; it does not make those APIs equivalent. Plan each dependency separately before moving.
Choose the operating model, then test it
| Question | Self-hosted Supabase | Lathe |
|---|---|---|
| Who controls the stack? | You run and configure the Supabase services on your infrastructure. | You choose the machine size and engines; Lathe operates the machine. |
| Who owns updates, monitoring and recovery? | Your team. | Lathe handles routine machine operations and daily backups within its published limits. |
| Are the product surfaces identical? | You get the self-hosted Supabase subset, not every hosted feature. | No: app, Postgres and compatible sign-in, not the full Supabase API suite. |
| Can it meet strict availability or recovery targets? | Only if you design and operate them. | Not if you require HA or less than a day's possible data loss. |
| How does billing work? | Infrastructure and operating effort are yours to budget. | One plan price by machine size; capacity still has limits. |
For a real migration, start in staging. List every Supabase feature your app calls, including code paths you rarely test. Export a database sample, check extensions and roles, move a test user through sign-in, verify OAuth redirects and email delivery, deploy your app, and run a restore drill. Keep the old environment available through your cutover and rollback window. If you only need Postgres and would rather keep Supabase Auth, that split is possible too: your app can keep calling its existing sign-in service while Postgres moves.
The honest answer may be to stay on hosted Supabase: its managed platform has more features and less setup. Or self-host it because control matters and you are ready to operate it. If the thing you want is an app, database and sign-in on one machine without becoming the machine's operator, try Lathe. The trial is 14 days without a card; use it to test your own app, not a toy benchmark.