Supabase
Replies: 43 comments 91 replies
-
|
Great topic! Why do people give up on Supabase for certain projects? In France, we have a lot of companies that prefer to have their data at home. Sometimes for the wrong reason, but somtimes for the right reason. For example, because of GDPR issues or because they host health data and need HDS hosting (equivalent to HIPPAA). Today, I don't do these projects with Supabase. Because maintaining and updating the selft hosted version is way too complicated. An idea that would help would be to make it easier to use a postgresql exeterne, so that you can use existing skills in your organization, or take a managed version of postgresql somewhere. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the feedback! This has been a fairly common notion with regard to matching regulatory requirements. By an external Postgresql - do you mean your own existing instance, managed by your team? A managed Postgres elsewhere (e.g., Aurora)? |
Beta Was this translation helpful? Give feedback.
-
|
I'm actually thinking of a managed instance elsewhere: it means you don't have to worry about database security, backups and snapshots. These things are pretty well mastered by others.... |
Beta Was this translation helpful? Give feedback.
-
|
Please open source or provide access to exactly same Supabase MCP experience, I was just pointed out to your post after bringing this up on discord. While Supabase currently onboards a ton of people via AI/vibe coding, you left us completely drowned when we moved to hosting our own instance. There is no a single MCP server on the market that supports the same set of commands or even as basic as your token usage. "The MCP execute_sql tool appears to only support SELECT queries and basic DML (INSERT/UPDATE/DELETE), not DDL statements." is basically what Cloude constantly points out when I'm trying to do anything via Google's toolbox and after spending multiple days searching even this gives a complete headache when doing anything now. Please do something for us here. 
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for asking! Some recent notes here -#39849 |
Beta Was this translation helpful? Give feedback.
-
|
Small note, my self hosted supabase is not running on local host, it's running on remote server. So the dev workflow works on on localhost while I use toolbox mcp to have AI work with the remote DB. Issue is that the toolcalls of postgres mcp does not match what your closed source mcp server offers that gives a better usability for AI to work with supabase. |
Beta Was this translation helpful? Give feedback.
-
|
Hello and thanks for all your hard work! Tell us about your setup: I deploy on Railway, with a Railway template I built myself. The template config automates almost all the self-hosting headache; networking, new DB passwords for each role, encryption keys, etc. At first, around January 2025, I was building a small digital product with a friend. This was on the Supabase hosted platform. We ended up scrapping our startup. However, I couldn't forget about the pain points I experienced with local dev during that time. Now, the main project is the Railway template itself for now. There is an example NextJS app included, which is a rough imitation of Trello. The goal was to test almost every Supabase feature; auth, studio, meta, storage, realtime, etc. How long have you been self-hosting? About one year. How would you describe yourself? I'm a solo dev, with a full-stack background. I consulted for years for a large financial company in Canada. My focus is growing towards "full-stack++", working towards some approximation of the competencies of a principal engineer. I strive to work across all layers of software delivery. This has gradually taken me to the infra space. I'm happy gaining competence in TCP/IP, Docker, shell scripting, systems-level programming, resilient multi-container architectures. This is all relatively new for me and self-hosting Supabase has been a great way to grow as a developer. What's actually working well for you? What's working well is the feeling that the Supabase stack is the endgame for product development. The last tech stack we'll need for quite some time. Almost everything you could ever need functionality-wise is here. That's a huge testament to how much thought went into designing the stack. So, if we can continue to improve the developer experience with Supabase, our productivity and ability to deliver value to the world will only improve from here. What made you choose self-hosted?
What parts of the experience have been smooth or even straightforward? Updating environment config per-service has been incredibly smooth. I've updated the Any unexpected wins? Figuring out how to version my email templates in code and integrate that into building the Auth image, was surprisingly easy once I took ownership for self-hosting. A few lines were added to a Dockerfile that bases from Supabase's official Auth image: FROM supabase/gotrue:v2.180.0
# Copy email templates into the container
COPY ./templates /home/mailer/templates
# Install lightweight file server for email templates
USER root
RUN apk add darkhttpd
USER supabase
# Run file server and auth server in parallel
ENTRYPOINT darkhttpd /home/mailer/templates --port 8080 --addr 127.0.0.1 & authWhat's the top thing that would make your life with self-hosted Supabase easier? The biggest pain point that still remains, based on my current experience, is that new migrations added to the Postgres image don't run in a continuously deployed setting. The running Postgres container has a volume mounted, with a data directory and an entire database, pages of data etc. When I update the Postgres image version in my GitHub repo, a new deployment starts. A container is spun up, the previous one is shut down, the new one is placed onto the infra node with the volume mounted, and it starts. I see the following message logged: The official Postgres Docker image is designed to only run the scripts in the entrypoint folder one time if there's no data directory. Because that's how the Supabase Postgres image manages those migrations, this presents a great challenge to keeping self-hosted Postgres services up-to-date. It doesn't have to be that way though, and Supabase could choose to manage those migrations in another way. They do all need to be idempotent though obviously. I still have no solution at this time, it would take a thoughtful and considerable effort to change how this is implemented in the Supabase Postgres image. If you could wave a magic wand and improve one thing, what would it be? Convince Supabase to use a monorepo strategy in their self-hosting example. I've written a few comments about why this is great for modern cloud CI/CD (watch paths, each service builds from a sub-directory). An example that might serve as inspiration: https://github.com/BenIsenstein/pgonrails |
Beta Was this translation helpful? Give feedback.
-
This is truly essential in a business environment. This is one of the reasons why I haven't used Supabase in several apps I've developed. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
In my framework for self hosting, PG On Rails, the email templates update instantly in local dev. No need to restart containers 😉> > - Add minimal tweaks at the container level, where useful, without disrupting the fundamental stack. (hosting email templates within the Auth container itself via httpd, tweaking Kong routing, etc)
|
Beta Was this translation helpful? Give feedback.
-
|
@aantti I want to recommend that you can think of everything that supabase releases as "building blocks" toward self-hosted successful outcome. Then, you can create an image release and docs etc around a profile that works for self-hosting while finding a way to resolve with the release cycles of the supabase product components. Then you can manage a stability and release cycle that focuses on what the self-hosting community is asking for. |
Beta Was this translation helpful? Give feedback.
-
|
...for instance, if the existing dockerfiles (which are geared toward use in https://github.com/supabase/cli) are not a good fit for self-hosting, then a set could be created somewhere that inherits what works from releases, and makes the changes needed based on consensus from self hosting. It can become a branch in the tree of supported release, and we already are set up to support that. |
Beta Was this translation helpful? Give feedback.
-
|
As promised on X here is my feedback how I use the supabase. Tell us about your setup: What does your deployment look like (infrastructure, deployment method)? We use Hetzner VPS with Coolify and the supabase template. What kind of project or team are you running it for? I work for different projects and companies. We use it as backend for financial asset overview, here we host a supabase for testing ourself. Prod is managed by supabase. Engineering Company , here we use supabase as backend for realtime car tracking. And here we host it self also in prod. How long have you been self-hosting? How would you describe yourself? Are you a solo indie dev, a small agency, a bigger company? Is application infrastructure your main focus, or are you a full-stack developer in need of an "open source Firebase"? What made you choose self-hosted? What parts of the experience have been smooth or even straightforward? Any unexpected wins? What's the top thing that would make your life with self-hosted Supabase easier? If you could wave a magic wand and improve one thing, what would it be? Something different than the basic auth for the dashboard (user with roles like in the hosted version) Happy to hear that things starts rolling :) |
Beta Was this translation helpful? Give feedback.
-
|
@aantti we have high hopes :-) !
Kubernetes, started with the now-abandoned Bitnami chart, added the missing bits and evolved it.
Open source and (recently) proprietary education products
3 years
Currently "solo indie dev", moving to a startup, postgres fanatic
Both! I do from server provisioning up to (very poor) CSS.
My previous main project was intended to be an open/research platform for low-budget/free/government education providers, so freedom/independence and cost were paramount... Also, need to host (amongst others) in China and other "air gapped" environments.
None that really stand out unfortunately.
Up-to-date, relatively comprehensive ops and release documentation. "We changed X so you need to Y, Breaking change ABC, etc."
Coherent engineering leadership across all the component apps. There are obviously some very talented coders amongst the bunch but it very much feels like a bunch of stuff hacked together with no cohesion. If you look at the git history of the There are marketing/design people that seem to put a nice polish on the outside of everything but the same care is not afforded for the individual projects at the technical/docs level. Supabase has always tried to portray the company as a "good open source citizen" but I haven't seen any of that really. The code is available but there is basically no community around the components, nor any desire to foster one... And again the docs/community around the "black-box" SAAS product is a COMPLETELY different thing. Firebase (Photoshop, MSOffice, ...) has a great community for it too - it's just not an open source community. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed feedback, @AntonOfTheWoods. Building a platform like Supabase and the organization around it involves a lot of complexity and tradeoffs. Self-hosted deserves better tooling and documentation - no argument there, and that's what I'm focused on improving. That said, there aren't many similar open-source platform stacks for the data layer that come with a truly permissive license. We're working to do better on all fronts, while maintaining that openness. I'm keeping your notes - there's a lot of work ahead regarding our community efforts (which includes all-things-self-hosted). |
Beta Was this translation helpful? Give feedback.
-
|
Hey, and welcome to the team! It's fantastic to see a dedicated focus on improving the self-hosting experience. Thanks for opening up this discussion. Here's a rundown of our experience in the wild. Our Setup
About UsWe're a small company of two. My role is a full-stack developer. We absolutely fit the profile of a team needing an "open-source Firebase" that gives us more control and flexibility. What's Actually Working Well
The Top Thing That Would Make Life EasierIf I could wave a magic wand, my top request would be to radically improve the update/upgrade process and its related communication. This is where we've hit our biggest hurdles:
Other SuggestionsA feature we'd love to see more guidance or tooling for is high-availability and replication. I know Postgres replication is a well-trodden path, but a holistic guide or solution that also covers Storage replication would be incredibly valuable for scaling and resilience. Thanks again for reaching out to the community. Despite the maintenance challenges, self-hosting Supabase has been a huge win for us. Looking forward to seeing how the experience evolves |
Beta Was this translation helpful? Give feedback.
-
|
Whoa, thanks so much for a very thorough feedback here! Let me digest :) Re changelogs - very true, and also I've just started some experimental lightweight process for CHANGELOG and image version updates. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @aantti, Thanks for starting this thread. As a new user trying to self-host on a UGREEN NAS, I just went through a very painful, full-day debugging session. I wanted to share my findings and a complete guide for what I had to do to get it working. P.S. I am very new to this, so my solution might not be ideal, but it does work and directly addresses several problems (Secrets, Permissions, DB roles) all at once. Here is my guide, which I hope can help you and the team improve the official docs. Title: [GUIDE] The Fix for 'permission denied for schema public' on Self-Hosted (UGREEN NAS)I finally found the solution. It's a three-part problem:
Here are the complete steps I used to deploy, and the final fix for anyone else who gets stuck. Part 1: Get Code and Create Project DirectoryThis is the standard first step. # Get the code (if you don't already have it)
git clone --depth 1 https://github.com/supabase/supabase
# Make your new supabase project directory
mkdir supabase-project
# Copy the compose files over to a project
cp -rf supabase/docker/* supabase-project
# Copy the fake env vars
cp supabase/docker/.env.example supabase-project/.env
# Switch to your project directory
cd supabase-projectPart 2: Prepare Your
|
Beta Was this translation helpful? Give feedback.
-
|
Ouch, a lot of work here! Will keep this as a bookmark for a guide related to UGREEN NAS for sure. Will also review as part of my ongoing effort to make the self-hosted docs more detailed. Curious, why do people use a "NAS" to self-host Supabase? :) Is that because there's some nice compute power? Because of storage capacity directly available? What's your actual "use case" if I may? |
Beta Was this translation helpful? Give feedback.
-
I jump right in because i do also host on my (Synology) NAS, or at least that was my dream until i managed it today.
In the end, with todays version of supabase, hosting on my NAS system required only a few changes in the .env (thanks to the auto generate script to skip the tedious secrets) and the docker-compose. |
Beta Was this translation helpful? Give feedback.
-
|
I really like Supabase, but my experiences with self-hosted have been nothing short of painful. Our infrastructure is on GCP. Our two attempted deployments crashed and burned. Both deployments utilized Google’s Cloud SQL and their global load balancer. One attempt was with Cloud Run, the other with a managed instance group. I felt like I got close with both, but ultimately bailed because the time investment was too much If I could pick an ideal setup, it would be Supabase managed (functions, auth, advisors, storage, etc) with my own Cloud SQL. This would allow us to do processing on GCP with our data for increased privacy, lower latency, and reduced egress fees. Having the ability to right-size my Superbase functions and backend database separately would be immensely beneficial. My app’s database is memory intensive — separate right-sizing gives me the ability to tune my system where it’s needed and prevents shared resourcing. Google Cloud SQL lets to take advantage of CUDs that makes the pricing more palatable. I’ll probably wrestle with self-hosting again at some point to make it work. I really don’t want to move everything. Help! In all seriousness, it’s great to see that you care so much about self-hosted as an option. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, this is fair. Running Supabase on a managed Postgres is somewhat non-trivial at the moment (although achievable). It's got some immediate limitations, though. This is definitely a valuable signal you're sending here. |
Beta Was this translation helpful? Give feedback.
-
|
First of all, as other mentioned, big thank you to see a dedicated focus on improving the self-hosting experience and for all your great work so far! About UsWe work in life sciences/research and health care. Our products range from management dashboards for health professionals and patient portals to workflow and tooling for researchers. Our SetupWe host everything self hosted on AWS through cloud formation IaC, mostly for compliance reasons but also for reduced legal complexity and talent competence. Our Criteriaself hosted, full code control with ability and competence to contribute, no outbound telemetry to external, white label-able and IP transferrable licenses of our products, all Infrastructure as Code with no console UI clicking, Modern tech stack without lock in, least amount of code to maintain ourselves, low complexity, MVP fast -> scale ready later What's Actually Working WellAll together we use supabase auth, client and server side sdks, storage (through s3), vector, studio, rest, very happily and successfully. Most happy i am about the amount of custom endpoints and backend/types code i do NOT have to write and maintain anymore by heavily making use of one Postgres DB as the single source of truth for data structure (-> types), permissions, auth and many RPC functions (love them). As much as possible is maintained through the declarative db schemas and that makes it feel a lot like the "single file backend" which is working pretty well for me for AI coding and context management. Very important is also to use this setup from across languages, we have different applications and backends using typescript or python and the supabase sdks make it very easy here to port code and patterns The Top Thing That Would Make Life EasierThe one thing i wished to have was an easier path to self host supabase with AWS RDS as the postgres DB, that was a real pain to setup and took me 2 weeks of custom cloud formation and shell scripting to alter the supabase/postgres migration files and align extensions, role grants and migration order to fit the RDS constraints (which suck, but for a reason i guess) The community AWS self hosting is to complex/costly/resource intensive for smaller scale products or MVPs, we wanted to "just" self host on an EC2 and "just" use RDS instead of a postgres DB inside of the EC2 and to be able to connect to our other AWS hosted projects/IAM setup etc. |
Beta Was this translation helpful? Give feedback.
-
|
First of all, thanks a lot for the kind words - and for being so specific about your environment and the role. Super nice that self-hosted Supabase option (although, modified :) has been that much useful. Regarding "AWS RDS as the postgres DB, that was a real pain to setup" - that's really true, unfortunately. I've done a similar experiment a few months ago, and it's a very tedious process indeed, which then comes with certain limitations (here, if you'd like to ever compare notes). |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, thanks for the linked resource, i wasn't aware of that. Sure, happy to compare. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I went through the same. |
Beta Was this translation helpful? Give feedback.
-
|
Did you get it working to use pg_net? |
Beta Was this translation helpful? Give feedback.
-
|
No, it's not available on AWS Aurora. I think I put a note about the limitations somewhere in that branch :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the amazing product! Setup:
About us:
Working well for us:
Nice to haves:
|
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the feedback! This is noice - "self-hosting for about 2 years now"!! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @aantti for asking!
Supabase running on several geographically-dispersed bare metal servers running NixOS, deployed using docker-compose
B2C product supporting both web and mobile apps
2 years
Solo indie
Full stack
Avoiding vendor lock-in at the data center level. Desire to understand what's going on beneath the hood
My app was postgres-based already, and migrating it into Supabase was easy peasy
Stripe integration, while not totally seamless, was easier than I expected. I ended up writing some MVs and cron jobs to sync them to fix some issues and then it was great. I think Supabase recently released something that makes this work better but I'm good with my solution :-)
Align versions here https://raw.githubusercontent.com/supabase/supabase/master/docker/docker-compose.yml with whatever you have running in hosted Supabase to keep things consistent
I'd love to be able to do active-active replication among my supabase servers, particularly the Some kind of built-in scheduled backup facility in Studio (maybe it's there and I missed it!) with ability to restore to point in time etc Let me set the OpenAI base URL using environment variable when running supabase using Docker so I can use other OpenAI-compatible LLMs including locally hosted LLMs. (ref. https://github.com/orgs/supabase/discussions/33205) (Sorry that was three LOL) |
Beta Was this translation helpful? Give feedback.
-
|
This is great, exactly what I've been trying to understand & collect as various opinions and feedback. Specific feature suggestions are much appreciated. The last two in particular have been definitely adding more barriers than necessary. |
Beta Was this translation helpful? Give feedback.
-
|
First of all, congrats to the team, Supabase is a great product and amazing evolution. For the same reasons shared by others, compliance and full data control and sovereignty is the key reason for self hosting. We are in the middle of the deployment on AWS, and we noticed that the github Cloudformation is outdated, with older versions of postgres and too broad permissions/security issues, so we are now trying to rewrite/build our own version, which goes against my will, and is a hassle I would have preferred not to take on. So I was happy to read you guys are open to soften that pain. The ideal version for me would be a fully aligned Cloudformation template with one click deploy resulting in the same stack as your online version and that is easy to update aligned with a transparent change log. Simply provide a domain name, and the rest is magic coded and secured by your team. We would be happy to pay a license for this like we do in the cloud on top of the infra cost we carry. Please let me know asap if we can expect some important improvements soon, so we can hopefully avoid our own rewrite attempts. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting :) This looks more like a paid "onprem" option, though? |
Beta Was this translation helpful? Give feedback.
-
|
What kind of project or team are you running it for? How long have you been self-hosting? How would you describe yourself? What made you choose self-hosted? What's the top thing that would make your life with self-hosted Supabase easier? At the moment, it doesn’t feel like Supabase is actively promoting or supporting self-hosting: some templates are outdated, community examples are sparse, and GitHub issues often show people struggling to get production-grade setups running. If you could wave a magic wand and improve one thing, what would it be? Ideally, self-hosting would support all core features we rely on — including Edge Functions, automated database backups, replication, and other reliability features that are currently much easier to use in the managed service. |
Beta Was this translation helpful? Give feedback.
-
|
Echoes the previous comment somewhat :) I can't say much about possible paid options for advanced self-hosted configurations like the above, but your comments regarding K8s are definitely very useful to me. |
Beta Was this translation helpful? Give feedback.
-
my own product
appr. 2 years
full stack developer
use supabase as solo developer
full stack developer in need of an "open source Firebase" but based on a SQL DB
everything like realtime usage, auth service, rest api, storage. Just the setup of self-hosted supabase took alot of effort with adjusted DB images
cost efficiency, gaining practice in running a self managed kubernetes cluster, and the ability to create and delete full instances for automated test runs
Supabase as backend with devspace and nuxtJS make app development very smooth and I experience less bugs as with other tech stacks. the automatically generated typescript types and the generated rest API create a very solid base. In-cloud E2E testing works also great with a supabase instance as testing environment with seeding that gets freshly created for every test run
With cloudnativePG as Kubernetes Postgres manager I can even reach high availability and DB backups quite easily
A kubernetes helm chart that uses cloudnativePG as Postgres DB
To have this helm chart ready to run |
Beta Was this translation helpful? Give feedback.
-
|
Looks like a very nice example of starting smaller then making it more advanced :) Glad to hear the product stack works overall quite well for you as a solo fullstack developer! The nice-to-haves above make sense. |
Beta Was this translation helpful? Give feedback.
-
|
As an interim note - I'm reading all the comments here and I'm grateful that everyone has taken the time to provide detailed, specific feedback. This means a lot. I can’t promise immediate improvements on everything, but this input is extremely insightful and very valuable as open feedback. |
Beta Was this translation helpful? Give feedback.
-
|
A quick interim update on the state of self-hosted Supabase :) First of all, the main goal so far has been to bring self-hosted configuration up to speed, make it more predictable as the "upstream" repo, collect feedback and ideas, identify & validate the gaps, and plan for enhancements. What's happened lately:
Next steps would be along the lines of working on major component updates (Postgres 17, Envoy as API gateway, further enhancements for Studio, support for new API keys, more work on the Helm chart, etc.) Appreciate everyone's feedback here, and thanks, much, for being a Supabase user :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, I'll leave this recap here; we're doing pretty well! Thanks, @aantti The most important points so far: ✅ MCP Server ✅ Token Generator (Web Docs) ✅ SQL Snippets 🔼 Documentation (Improving... Improving... 👌I definitely believe it is necessary to document processes like the ones I mentioned above.) 🧐 Analytics and Logs (I think it's much more stable lately; however, many have reported instability. This will need to be verified, as those who reported it should check with the latest versions. For me it would be a 🔼) 🫤 DB Migration (Schema Updates) 🫤 Backups 🫤 DENO Update 🫤 Postgres Update 🫤 Replications (I'm really not sure about this... From my perspective, I think [I'm sure] that it's better to use the Cloud service) 🤔 ❓ Other Fixes (Please mention them in the comments) Thanks again to @aantti, the supabase team, and all the contributors! Lets Goooo! |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward the DENO Update part.. 2.1 is really antique at this point. |
Beta Was this translation helpful? Give feedback.
-
|
Hey! Thank you for taking feedback. This is all probably going to sound quite spirited, so I want to preface it all by stating how much I enjoy of what I can get working out of Supabase. I truly think you have something special here, which is why it hurts so much when things don't quite work out. I'm a hobbyist with ambitions to learn and use these things for fun, not profit. I've been doing self-hosting in general for probably a decade now in some form or other. Unfortunately, I've found the self-hosting experience for Supabase to be unusually frustrating. The rest of my system uses a Traefik reverse-proxy as a unified entry-point / router to direct direct incoming requests to different applications most often based on the Host in the request. I rarely if ever run into issues slotting in most anything behind this system, but Supabase unfortunately happens to've been a particularly prickly outlier for me.
To sum it up things up:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm a solo dev looking to master a good modern tech stack to start building and shipping various web applications. I laid my eyes on Supabase because it keeps coming up in LLM recommendations and is the go-to option when you use Figma's automatic mode for instance. I would like to self-host to avoid any vendor lock-in and also to be compatible with very strict data sovereignty rules that certain fields have (e.g. medical data). For development and testing purposes I simply use Terraform to provision a compute instance on a cloud provider (that offers an OpenStack service) and then I deploy the app to that instance using Ansible. On paper Supabase seems to be the "open source Firebase" that any full-stack developers would want. So I started following the self-hosting docker guide (Kubernetes and Traefik being listed as "maintainer needed"). I encountered issues after only about 10 minutes of writing the playbook file. The first few steps are very straight forward: clone the repo and start setting values in an The first real problem one is asked to solve is setting various secrets for the multiple services to talk to each other. There is a script called You can see here it just does a massive sed (e.g. for But that secret is nowhere to be found in It's actually nowhere in the whole So now I'm not sure what to do. I don't really want to trust that script, especially since bash scripting with functions is not my cup of tea. Either I automate the secret setting part away by creating my own python script (and maybe even have it store the secrets in an Infisical project). Or I look at other ways of deploying it to an instance. If I do automate the secrets step in the self-hosting guide and replace I see a couple other efforts out there such as the ones below, but they have their own problems.
That's a summary of my experience self-hosting supabase: 10 minutes in following the main guide, I'm already seeing something that is far from being polished. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! Current self-hosted configuration is both "interactive" (i.e. manual) install option, and an upstream for any 3rd party deployment options such as the ones you've mentioned. You can definitely just generate all keys and secrets your own way following the notes in the guide. I'd be certainly interested in any PRs that might improve the current configuration. Regarding shell (specifically it's not Bash, btw :) I'd like to avoid any additional [language] dependencies, though. Having a POSIX shell script might not be ideal these days because many people are less familiar, however it still seems to be the most portable option. I have to add something like |
Beta Was this translation helpful? Give feedback.
-
|
You can also add an issue, @xapple :) |
Beta Was this translation helpful? Give feedback.
-
|
OK cool I'll add an issue to the main repo! |
Beta Was this translation helpful? Give feedback.
-
|
I have finished the work I think people are expected over the years in the project: https://github.com/webysther/supabase-docker Hope helps, this allow deploy in seconds of a project, easy to maintain, clean, and can be deployed in many platforms w/o problem. |
Beta Was this translation helpful? Give feedback.
-
|
@YukiAttano Indeed, that's a good way to describe it. Also - oftend deployed on k8s.
@webysther Packaging all of the Supabase components into one gigantic Docker image won't really help to reduce the CPU/memory footprint either in my subjective PoV - while will increase complexity of building and maintaining it even more. That said, a lightweight package for tiny projects might be a good option. |
Beta Was this translation helpful? Give feedback.
-
For my projects, that's exactly all I need.
|
Beta Was this translation helpful? Give feedback.
-
sure, the point here is to make easy to maintain and getting started. |
Beta Was this translation helpful? Give feedback.
-
The project already use only kong, auth, s3 (minio) and pg-rest, here is the setup today: https://github.com/readest/readest/blob/main/docker/compose.yaml |
Beta Was this translation helpful? Give feedback.
-
|
@aantti tell me more about "lightweight package for tiny projects" |
Beta Was this translation helpful? Give feedback.
-
|
Upgrade anxiety is real, I've been there. Spent too long manually diffing docker compose files between releases and doing backup-then-pray upgrades. Built something to scratch my own itch: you connect your VPS over SSH, it deploys the full Supabase stack (Postgres, Auth, Storage, Realtime, Studio), then handles future upgrades with auto-rollback and automated backups to your S3/R2. Your servers, your data, instances keep running even if you cancel. Just launched the beta yesterday. Happy to give free access to anyone in this thread who wants to try it and share feedback. Sign up at supabyoi.com or reply here. |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious about this, do you enable customization of Deno version? Currently Supabase runs on 2.1.4 which is antique. |
Beta Was this translation helpful? Give feedback.
-
|
One thing that bit me when self-hosting: cron jobs (backups, cleanups, replication) can fail silently and you do not find out for days. I added heartbeat monitoring to all my scheduled tasks using Gabe. Each cron job pings a URL after running — if the ping stops, I get a Slack alert within 2 minutes. # Example: daily Supabase backup
0 3 * * * pg_dump $DATABASE_URL | gzip > /backups/daily.sql.gz && curl -fsS https://gabe.usegabe.workers.dev/ping/IDFree, open source, self-hostable on Cloudflare Workers. Might help others running similar self-hosted stacks. |
Beta Was this translation helpful? Give feedback.
-
|
For self-hosting stability, what helped us most was treating Supabase like a platform stack, not a single container:
Operational checklist we use:
If useful, I can share a minimal self-hosting smoke-test script structure (curl + SQL probes) that catches most regressions early. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds great, but for me, I have a homelab with ~50 stacks, no one need this, a few the upgrade need a careful consideration. All take around 20GB of memory, really few use a good amount of memory, mostly are insane great, low memory, low amount of containers or are good integrated. Imagine a person have to manage OnlyOffice all containers? No need, they have a AIO. Let's imagine OpenProject which is a workhorse for project management, multiple containers but all from same image and diferent command only. I don't know, even if you ask a GPT he know based on amount of people talking about the terrible image offering how hard is keep this up. Finally, no single of my stacks need a build or start-up script or files to put in place. Add this to the image is no-brainer and they decide to delegate this to us, how convenient 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
That would be great! |
Beta Was this translation helpful? Give feedback.
-
|
Would also appreciate the script :) thanks |
Beta Was this translation helpful? Give feedback.
-
|
Fwiw, a short while ago I've added a few tests of that kind in |
Beta Was this translation helpful? Give feedback.
-
|
Setup: Solo dev, learning project. Single Hetzner CX22 (2 vCPU, 4 GB RAM), two isolated Supabase projects on Docker Swarm + Traefik v3 + HashiCorp Vault. Self-hosting for about 3 months. Why self-hosted: Wanted to understand what the managed service actually does before paying for it. Turns out: a lot. What worked well: Once everything is wired up, the core stack is solid. PostgreSQL, GoTrue, PostgREST, and Realtime all behave predictably under load (load tested to 50 VUs, PostgreSQL sat at under 1% CPU with realistic session behaviour). Pain points / what would help most:
First, thank you to the Supabase team, going through this made me realise how much work goes into the managed service, and I have a new appreciation for what the free tier provides. I documented the full experience (setup, security hardening, Vault, Falco IDS, load testing) as a 7-part series if useful: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing! A massive writeup and very detailed :) |
Beta Was this translation helpful? Give feedback.
-
|
This is a very thorough exploration you've gone through :) A note on With some great help from our contributors I've also recently added a few more how-to guides to https://supabase.com/docs/guides/self-hosting - might be useful to check for explanations on various env vars and configuration tasks. This is WIP, will continue. There's, e.g., now two options for using either Caddy or nginx via Docker Compose overlays for an easier/illustrative path regarding an external HTTPS proxy. The configuration is probably worth checking - notably, Storage is worth proxying directly and it also requires an extra header. Last but not least - I've also amended |
Beta Was this translation helpful? Give feedback.
-
|
Oh great, thank you for the pointers, I will update my notes! |
Beta Was this translation helpful? Give feedback.
-
|
Would be nice if you could work together with some (opensource) Supabase selfhost providers, like coolify! ex coollabsio/coolify#8316 |
Beta Was this translation helpful? Give feedback.
-
|
I believe dokploy is also one |
Beta Was this translation helpful? Give feedback.
-
|
Self-hosting Supabase for AI agent backends has some specific challenges beyond the standard self-hosting pain points: Row-level security for multi-tenant agents. Each agent in a multi-agent system should only see its own data — even when multiple agents share a Supabase project. Supabase RLS + JWT claims (agent_id in the token) makes this manageable, but you need to be consistent about including agent_id in every INSERT and filtering on it in every SELECT. Missed RLS policies are invisible failures — agents silently read each other's data. Real-time subscriptions for agent coordination. Supabase realtime is excellent for event-driven agent patterns — Agent A writes a record, Agent B's subscription fires and processes it. This works well at small scale. At 50+ agents all subscribing, the connection overhead becomes significant. We use Redis pub/sub for high-frequency agent-to-agent events and Supabase realtime only for human-visible state changes. Storage lifecycle for agent-generated artifacts. Agent workflows generate a lot of temporary files (tool call results, intermediate analysis, scratchpad data). Without explicit lifecycle management, Supabase Storage fills up with orphaned artifacts. We add a Cost attribution per agent. Supabase doesn't natively track database queries per-agent. We add a Isolation patterns for multi-tenant agent backends: https://blog.kinthai.ai/openclaw-multi-tenancy-why-vm-per-user-doesnt-scale |
Beta Was this translation helpful? Give feedback.
-
|
I'm from the Realtime development team. Can you provide some information on what has been the overhead you found when using Realtime for agent coordination? |
Beta Was this translation helpful? Give feedback.
-
|
Self-hosting Supabase is very much production-viable now, but there are rough edges worth documenting for others considering it: What works well:
What needs attention:
The main operational gap: there's no self-hosted equivalent of the Supabase support team. When something goes wrong, you're on your own with Postgres logs and GitHub issues. What's your specific use case — dev environment, side project, or production workload? |
Beta Was this translation helpful? Give feedback.
-
|
solo dev, hosting multiple supabase coolify instances on dedicated hetzner server.
Could anyone share their working docker compose or kubernetes k8s version of supabase stack that can safely rollout without dropping pg operations? or know a fix in coolify? thank you |
Beta Was this translation helpful? Give feedback.
-
|
First of all, thanks for allowing us to give feedback in that matter. I love Supabase and I'm currently hosting all my projects there. I'd love to support the project in the future but at some point I might be forced to switch to a self-hosted version of Supabase because of the cost. I already gave the self-hosted version a try by using Coolify and I managed to get it up and running but I wasn't confident enough to use it for production. What I'd love to see and probably many others too, is a self-hosted version of Supabase that is managed by Supabase in the cloud for a flat fee of X USD. Managed by Supabase but running on an own server. Basically something like https://xcloud.host/#pricing or with Supabase https://xcloud.host/docs/how-to-install-supabase-with-xcloud/ or Coolify Cloud or whatever example you can find. I'm not sure if this is actually doable reliably but I'd love it. |
Beta Was this translation helpful? Give feedback.
-
|
Fwiw, re: "version of Supabase that is managed by Supabase in the cloud for a flat fee" - this is quite close to the current platform offering :) Each customer instance on AWS runs its own Postgres, Auth, PostgREST, and PgBouncer for a flat fee. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but it's not a flat fee. In my opinion it would be very nice to be able to bring your own server and then Supabase charges a flat fee of let's say 20 bucks per month to manage your Supabase instance on your own server. The advantage? The cost. Supabase and AWS prices are steep. |
Beta Was this translation helpful? Give feedback.
-
|
I can also upvote to bring your own server concept... Some countries have regulations for data residency. For my country, no data can go out of my country for my business. I wish I were able to use it with my own server, which is a Supabase-managed one :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for opening this thread — happy to share where my setup lands, because it's a fairly extreme corner of the self-hosting spectrum. Tell us about your setupI've built a custom, hyper-optimized, headless Supabase implementation from the ground up. I essentially deconstructed the stack and rebuilt it to strip away anything I didn't need (no Studio, no Vector/Logflare, no Supavisor, no Analytics, no Kong/Envoy). The result is a single
How would you describe yourself?Solo entrepreneur, full-stack developer, building on top of Supabase. I'm probably not the "ideal persona" for managed Cloud or the official self-hosted compose: I don't use the stack as-is. But I lean heavily on Supabase's modularity to wire up exactly the backend I need. What's actually working well
What would make my life easier1) Clearer documentation of environment variables — their conventions and expected types. This is the single biggest paper cut. The public docs only cover a subset, every component's GitHub repo extends them in its own way, and a lot of values are only discoverable by reading source. A few concrete examples I've hit:
A single, generated, per-service reference (name, type, unit, default, since-version) would close a huge gap. 2) If I could wave a magic wandAn official "headless / lite" Supabase: the same set of services, but as a pure data engine, without the opinionated dashboard / Studio / Analytics layer. Smaller, faster, fewer moving parts, easier to keep current. Basically blessing the shape of stack I ended up building by hand. Paired with that, an optional lite admin viewer — explicitly not Studio. No table creation, no schema editing, no bucket creation, no "design the database in a UI" energy. Read and manage existing rows, users and files: browse tables and storage buckets, edit/delete rows, manage users (reset password, soft-delete, etc.), inspect logs. Production-friendly and opinionated the other way: architecture stays in code/SQL, the UI is just for day-to-day data ops. That would cover the legitimate "but how do I look inside the DB in prod?" objection that headless setups always face, without dragging the full Studio surface back in. Deep dive: replacing Kong/Envoy with Caddy entirelySharing this because it might interest others trying to cut RAM and config surface. The official gateway (Kong, and the newer Envoy variant) is essentially doing four things on the protected routes:
So the whole new On top of that, the same Caddy instance does TLS, sliding-window rate limiting at the edge, static file serving for the Auth email templates on the internal network, and unified access logging. One service, one config file, one place to look when something goes wrong. One deliberate divergence from Envoy worth flagging for anyone copying this approach: Envoy's The tradeoff is real (no plugin ecosystem, no service-mesh story, no Kong-specific tooling) but for a self-hosted single-tenant stack the math is heavily in Caddy's favour: hundreds of MB of RAM saved, modern Supabase Auth features unlocked (new asymmetric Happy to share the Caddyfile snippets or the compose layout if it's useful to anyone going down the same path. |
Beta Was this translation helpful? Give feedback.
-
|
No problem, glad it helps (merged via PR #46124) :) Looking forward to seeing that Caddyfile! |
Beta Was this translation helpful? Give feedback.
-
Don't want to bother and propably you already noticed but storage added a new env variable |
Beta Was this translation helpful? Give feedback.
-
Here's the Caddyfile Dockerfile: # syntax=docker/dockerfile:1
FROM caddy:2.11.3-builder AS builder
RUN --mount=type=cache,target=/go/pkg/mod \
--mount=type=cache,target=/root/.cache/go-build \
xcaddy build \
--with github.com/mholt/caddy-ratelimit@v0.1.0
FROM caddy:2.11.3-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddyCaddyfile: {
email {$CADDY_CONTACT_EMAIL}
skip_install_trust
log {
level {$CADDY_LOG_LEVEL}
}
# Server-wide options. When running behind a CDN/L7 proxy (Cloudflare, Fastly, ALB, …) uncomment `trusted_proxies` so Caddy parses the real client IP out of forwarded headers; this also makes {client_ip}, rate_limit, GOTRUE_SECURITY_SB_FORWARDED_FOR_ENABLED, and access logs use the actual visitor IP instead of the immediate Docker peer. `private_ranges` already covers RFC1918 + ::1; replace or extend with the CDN's public ranges as needed.
# https://caddyserver.com/docs/caddyfile/options#trusted-proxies
servers {
# trusted_proxies static private_ranges
# trusted_proxies_strict
# client_ip_headers X-Forwarded-For CF-Connecting-IP
}
}
# ============================================================================
# Snippets — mirror the official Supabase Envoy filter chain in volumes/api/envoy/lds.template.yaml. Snippet names match the Envoy filter they replace so the two configs are easy to cross-reference. Routes below also carry their Envoy/Kong route names in comments (auth-v1-protected, rest-v1-protected, realtime-v1-ws-protected, etc.).
# ============================================================================
# Front-edge sliding-window rate limit. Caddy-only addition; Kong/Envoy do not rate-limit at the gateway by default in the upstream Supabase setup.
(api_rate_limit) {
rate_limit {
zone my_api_zone {
# {client_ip} resolves to the immediate peer when no CDN is in front, or to the parsed real client IP once `trusted_proxies` is configured in the global `servers {}` block above.
key {client_ip}
events {$GATEWAY_RATE_LIMIT_EVENTS}
window {$GATEWAY_RATE_LIMIT_WINDOW}
}
}
}
# Caddy already auto-injects Host, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host on every reverse_proxy (see "Defaults" in the reverse_proxy docs). We only add the two headers Supabase services read in addition:
# - X-Real-IP: gotrue/postgrest helpers consume it as a single-IP fallback.
# - X-Request-ID: GOTRUE_REQUEST_ID_HEADER and access-log correlation.
(forwarded_headers) {
header_up X-Real-IP {client_ip}
header_up X-Request-ID {request_id}
}
# Resolves the Apikey header to the matching internal asymmetric JWT. Mirrors the combined effect of Envoy's "translate apikey in header" Lua filter and the accept-list inside the "401 for missing/invalid API key" filter:
# 1. SUPABASE_PUBLISHABLE_KEY -> swap to ANON_KEY_ASYMMETRIC (anon)
# 2. SUPABASE_SECRET_KEY -> swap to SERVICE_ROLE_KEY_ASYMMETRIC (service_role)
# 3. ANON_KEY_ASYMMETRIC -> pass through (anon)
# 4. SERVICE_ROLE_KEY_ASYMMETRIC -> pass through (service_role)
# 5. ANON_KEY (legacy HS256) -> pass through (anon)
# 6. SERVICE_ROLE_KEY (legacy HS256) -> pass through (service_role)
# Cases 3-4 let Edge Functions (and any internal caller) reach the gateway carrying the internal asymmetric JWT they were configured with. Cases 5-6 are the legacy backward-compat path the platform still accepts.
# Output (custom placeholders, populated by the map directive):
# {_translated_apikey} = JWT to forward upstream (or "")
# {_role} = "anon" | "service_role" | ""
# An empty role means "no recognised key supplied" (missing, invalid, or AWS SigV4). Subsequent snippets read these directly via the `vars` matcher's placeholder form (canonical Caddy idiom, see https://caddyserver.com/docs/caddyfile/matchers#vars).
#
# compose.yml passes a unique unmatchable sentinel for any blank key ("__unset_<name>__"), so the map's input-uniqueness check holds even when legacy keys are not configured. Real Apikey headers never collide with the sentinels.
(api_key_lookup) {
map {http.request.header.Apikey} {_translated_apikey} {_role} {
"{$SUPABASE_PUBLISHABLE_KEY}" "{$ANON_KEY_ASYMMETRIC}" "anon"
"{$SUPABASE_SECRET_KEY}" "{$SERVICE_ROLE_KEY_ASYMMETRIC}" "service_role"
"{$ANON_KEY_ASYMMETRIC}" "{$ANON_KEY_ASYMMETRIC}" "anon"
"{$SERVICE_ROLE_KEY_ASYMMETRIC}" "{$SERVICE_ROLE_KEY_ASYMMETRIC}" "service_role"
"{$ANON_KEY}" "{$ANON_KEY}" "anon"
"{$SERVICE_ROLE_KEY}" "{$SERVICE_ROLE_KEY}" "service_role"
default "" ""
}
}
# Mirrors Envoy's first Lua filter "Copy ?apikey query to header" (lds.template.yaml ~lines 547-592). Browser WebSocket clients cannot set custom upgrade headers, so the apikey arrives in the URL.
(apikey_from_query) {
@apikey_only_in_query {
not header Apikey *
expression `{http.request.uri.query.apikey} != ""`
}
request_header @apikey_only_in_query Apikey {http.request.uri.query.apikey}
}
# Mirrors Envoy's "401 for missing/invalid API key" filter (lines 864-934). Apply on PROTECTED routes (auth-v1-protected, rest-v1-protected, graphql-v1-protected, realtime-v1-api-protected, realtime-v1-ws-protected, pg-protected). NOT applied on Storage/Functions/open routes.
(reject_invalid_apikey) {
@no_known_key vars {_role} ""
handle @no_known_key {
header Content-Type "application/json"
respond `{"message":"No API key found in request"}` 401
}
}
# Mirrors Envoy's "translate apikey in header" Lua filter (lines 714-771). No-op when no recognised key was supplied (so AWS SigV4 / unauthenticated calls pass through untouched on routes where they are allowed).
(translate_apikey_header) {
@translate_has_known_key not vars {_role} ""
request_header @translate_has_known_key Apikey {_translated_apikey}
}
# Mirrors Envoy's "translate apikey in query" Lua filter (lines 594-712). Required for the Realtime WebSocket route where browsers carry the key in the URL. Caddy `uri ... query` is regex find/replace; the pattern matches "apikey=" followed by any non-"&" characters (safe — both opaque keys and base64url JWTs contain only URL-safe characters).
(translate_apikey_query) {
@known_key_in_query {
expression `{http.request.uri.query.apikey} != ""`
not vars {_role} ""
}
uri @known_key_in_query query "apikey=[^&]+" "apikey={_translated_apikey}"
}
# Mirrors Envoy's "synth Authorization" Lua filter (lines 796-862). Synthesizes `Authorization: Bearer <internal asymmetric JWT>` when the client did not send a real bearer token of its own.
#
# DELIBERATE DIVERGENCE FROM ENVOY (kept — strictly safer):
# Envoy's `has_real_jwt` returns false for ANY Authorization that does not begin with "Bearer " (for example AWS SigV4: `AWS4-HMAC-SHA256 Credential=…`), so when an apikey is also present Envoy would overwrite the SigV4 header. We only synthesize in two cases, both gated on a known sb_*/internal asymmetric JWTs/legacy key being present:
# 1. Authorization is absent or empty.
# 2. Authorization starts with "Bearer sb_" (the client passed an opaque key in both headers, which is not a valid JWT).
# Any other Authorization (real Bearer JWT, AWS SigV4, anything else) is left untouched. In practice no real client sends both SigV4 and an sb_* apikey, so the only observable effect is preserving SigV4 on Storage — which is the correct behaviour.
(synth_authorization) {
@auth_missing_or_empty {
not header_regexp Authorization "^.+$"
not vars {_role} ""
}
request_header @auth_missing_or_empty Authorization "Bearer {_translated_apikey}"
@auth_is_sb_key {
header_regexp Authorization "^Bearer sb_"
not vars {_role} ""
}
request_header @auth_is_sb_key Authorization "Bearer {_translated_apikey}"
}
# Mirrors Envoy's "mirror apikey to x-api-key" Lua filter (lines 773-794). Realtime WebSocket reads X-Api-Key first.
(mirror_x_api_key) {
@mirror_has_known_key not vars {_role} ""
request_header @mirror_has_known_key X-Api-Key {_translated_apikey}
}
# ============================================================================
# Internal mailer template host (not published to host ports)
# ============================================================================
:8081 {
handle_path /mailer/* {
root * /srv/auth-mailer
file_server
}
respond 404
}
# ============================================================================
# Public site
# ============================================================================
{$PUBLIC_API_DOMAIN}, http://gateway {
encode zstd gzip
log {
output file /var/log/caddy/access.log {
roll_size 50mb
roll_keep 3
}
}
# Default response headers
header {
defer
Access-Control-Allow-Origin "{$CORS_ALLOWED_ORIGIN}"
Access-Control-Expose-Headers "tus-resumable, upload-offset, upload-length, location, x-upsert"
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
X-XSS-Protection "1; mode=block"
}
# Top-level route block enforces source-order matching for the handle blocks below (open routes must be checked before the protected /auth/v1/* catch-all, /realtime/v1/api/* before /realtime/v1/*, etc.).
route {
# ============================================================
# CORS preflight
# Access-Control-Allow-Origin and Access-Control-Expose-Headers are emitted by the outer `header { defer ... }` block for every response (including this 204), so they are not repeated here.
# ============================================================
@options method OPTIONS
handle @options {
header Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD"
header Access-Control-Allow-Headers "Origin, Accept, Accept-Profile, Authorization, Content-Type, Content-Profile, apikey, x-client-info, prefer, x-supabase-api-version, tus-resumable, upload-length, upload-metadata, upload-offset, x-upsert, x-signature"
header Access-Control-Max-Age "3600"
respond 204
}
# ============================================================
# OPEN routes (no apikey required)
# Mirror Envoy's auth-v1-open-* / well-known-oauth / sso-* routes.
# ============================================================
# auth-v1-open-verify -> auth:9999/verify (email confirm/recovery/invite/email-change links)
# auth-v1-open-callback -> auth:9999/callback (OAuth callback redirect target)
# auth-v1-open-authorize -> auth:9999/authorize (OAuth authorize entry)
# auth-v1-open-jwks -> auth:9999/.well-known/jwks.json (third-party JWT verification)
@auth_open path {$AUTH_PREFIX}/verify {$AUTH_PREFIX}/verify/* {$AUTH_PREFIX}/callback {$AUTH_PREFIX}/callback/* {$AUTH_PREFIX}/authorize {$AUTH_PREFIX}/authorize/* {$AUTH_PREFIX}/.well-known/jwks.json
handle @auth_open {
uri strip_prefix {$AUTH_PREFIX}
import api_rate_limit
reverse_proxy auth:9999 {
import forwarded_headers
header_up X-Forwarded-Prefix {$AUTH_PREFIX}
}
}
# well-known-oauth -> auth:9999/.well-known/oauth-authorization-server (RFC 8414)
@oauth_meta path /.well-known/oauth-authorization-server /.well-known/oauth-authorization-server/*
handle @oauth_meta {
import api_rate_limit
reverse_proxy auth:9999 {
import forwarded_headers
header_up X-Forwarded-Prefix /.well-known/oauth-authorization-server
}
}
# auth-v1-open-sso-acs -> auth:9999/sso/saml/acs
# auth-v1-open-sso-metadata -> auth:9999/sso/saml/metadata
@sso_saml path /sso/saml/acs /sso/saml/acs/* /sso/saml/metadata /sso/saml/metadata/*
handle @sso_saml {
import api_rate_limit
reverse_proxy auth:9999 {
import forwarded_headers
header_up X-Forwarded-Prefix {path}
}
}
# ============================================================
# PROTECTED routes (apikey required)
# ============================================================
# auth-v1-protected -> auth:9999/*
handle_path {$AUTH_PREFIX}/* {
route {
import apikey_from_query
import api_key_lookup
import reject_invalid_apikey
import translate_apikey_header
import synth_authorization
import api_rate_limit
reverse_proxy auth:9999 {
import forwarded_headers
header_up X-Forwarded-Prefix {$AUTH_PREFIX}/
}
}
}
# rest-v1-protected -> rest:3000/*
handle_path {$REST_PREFIX}/* {
route {
import apikey_from_query
import api_key_lookup
import reject_invalid_apikey
import translate_apikey_header
import synth_authorization
import api_rate_limit
reverse_proxy rest:3000 {
import forwarded_headers
header_up X-Forwarded-Prefix {$REST_PREFIX}/
}
}
}
# graphql-v1-protected -> rest:3000/rpc/graphql (with Content-Profile: graphql_public)
# Add the postgres-meta service and a `graphql` schema first; this is kept here for parity. pg_graphql is not part of the default custom stack but the route exists so it works the moment you enable it.
@graphql path /graphql/v1 /graphql/v1/*
handle @graphql {
route {
@no_content_profile not header Content-Profile *
request_header @no_content_profile Content-Profile graphql_public
rewrite * /rpc/graphql
import apikey_from_query
import api_key_lookup
import reject_invalid_apikey
import translate_apikey_header
import synth_authorization
import api_rate_limit
reverse_proxy rest:3000 {
import forwarded_headers
header_up X-Forwarded-Prefix /graphql/v1
}
}
}
# Custom: redirect /realtime/v1/admin/* -> /admin/* so the admin dashboard URL can live at the conventional /admin path while still being reachable through the realtime-prefixed legacy URL.
handle_path {$REALTIME_PREFIX}{$REALTIME_DASHBOARD_PREFIX}/* {
redir https://{host}{$REALTIME_DASHBOARD_PREFIX}{path} 301
}
# realtime-v1-api-protected -> realtime:4000/api/*
# REST API: gets translation + Authorization synthesis.
@realtime_api path {$REALTIME_PREFIX}/api {$REALTIME_PREFIX}/api/*
handle @realtime_api {
route {
uri strip_prefix {$REALTIME_PREFIX}
import apikey_from_query
import api_key_lookup
import reject_invalid_apikey
import translate_apikey_header
import synth_authorization
import api_rate_limit
reverse_proxy realtime:4000 {
import forwarded_headers
header_up X-Forwarded-Prefix {$REALTIME_PREFIX}/api
}
}
}
# realtime-v1-ws-protected -> realtime:4000/socket/*
# WebSocket and longpoll: query translation + X-Api-Key mirror. NO Authorization synthesis here (Realtime reads X-Api-Key first).
# /realtime/v1/websocket -> /socket/websocket
# /realtime/v1/longpoll -> /socket/longpoll
# /realtime/v1/... -> /socket/...
handle_path {$REALTIME_PREFIX}/* {
route {
import apikey_from_query
import api_key_lookup
import reject_invalid_apikey
import translate_apikey_header
import translate_apikey_query
import mirror_x_api_key
import api_rate_limit
rewrite * /socket{uri}
reverse_proxy realtime:4000 {
import forwarded_headers
header_up X-Forwarded-Prefix {$REALTIME_PREFIX}/
}
}
}
# ============================================================
# BYPASS routes (service handles its own auth)
# ============================================================
# storage-v1 -> storage:5000/*
# Storage authenticates internally (asymmetric JWT or AWS SigV4). The gateway translates apikey when it is a known sb_*/internal asymmetric JWTs/legacy value but never rejects on missing apikey (S3 presigned URLs carry no header). AWS SigV4 Authorization headers are left untouched (see the DELIBERATE DIVERGENCE comment on the synth_authorization snippet). Storage requires X-Forwarded-Prefix for S3 SigV4 verification and TUS Location URL construction; storage env must set REQUEST_ALLOW_X_FORWARDED_PATH=true for it to be honoured.
handle_path {$STORAGE_PREFIX}/* {
route {
import apikey_from_query
import api_key_lookup
import translate_apikey_query
import translate_apikey_header
import synth_authorization
import api_rate_limit
reverse_proxy storage:5000 {
import forwarded_headers
header_up X-Forwarded-Prefix {$STORAGE_PREFIX}
}
}
}
# functions-v1 -> functions:9000/*
# Edge Runtime handles its own auth; pass apikey and Authorization through untouched. The translation chain is fully skipped here, the same way Envoy skips it on /functions/v1/.
handle_path {$FUNCTIONS_PREFIX}/* {
route {
import api_rate_limit
reverse_proxy functions:9000 {
import forwarded_headers
header_up X-Forwarded-Prefix {$FUNCTIONS_PREFIX}/
}
}
}
# ============================================================
# OPTIONAL routes (commented for parity — uncomment to enable)
# ============================================================
# pg-protected -> postgres-meta:8080/* (service_role only)
# Mirrors Envoy's RBAC rule that limits /pg/ to the service_role principal. Add the `postgres-meta` service to compose.yml first.
#
# handle_path /pg/* {
# route {
# import apikey_from_query
# import api_key_lookup
# import reject_invalid_apikey
# @not_service_role not vars {_role} "service_role"
# handle @not_service_role {
# header Content-Type "application/json"
# respond `{"message":"Forbidden"}` 403
# }
# import translate_apikey_header
# import synth_authorization
# import api_rate_limit
# reverse_proxy postgres-meta:8080 {
# import forwarded_headers
# header_up X-Forwarded-Prefix /pg/
# }
# }
# }
# mcp-blocker / mcp -> studio:3000/api/mcp
# DENY by default in Envoy/Kong. Uncomment together with the studio service if you want to expose the MCP endpoint locally; review https://supabase.com/docs/guides/self-hosting/enable-mcp first.
#
# @mcp_paths path /api/mcp /api/mcp/* /mcp /mcp/*
# handle @mcp_paths {
# header Content-Type "application/json"
# respond `{"error":"forbidden","message":"Access is forbidden."}` 403
# }
# dashboard (catch-all) -> studio:3000/* (HTTP basic auth)
# Mirrors Envoy's catch-all `/` -> studio route with basic auth and inbound `Authorization` stripped. Add the `studio` service to compose.yml and define STUDIO_BASIC_AUTH_USER / STUDIO_BASIC_AUTH_PASSWORD_HASH in .env first. Place this block as the LAST handle (above the fallback) — it must not shadow the API routes above.
#
# handle {
# basicauth {
# {$STUDIO_BASIC_AUTH_USER} {$STUDIO_BASIC_AUTH_PASSWORD_HASH}
# }
# request_header -Authorization
# reverse_proxy studio:3000 {
# import forwarded_headers
# }
# }
# ============================================================
# Custom: Realtime admin dashboard at /admin/*
# ============================================================
handle {$REALTIME_DASHBOARD_PREFIX}/* {
reverse_proxy realtime:4000 {
import forwarded_headers
}
}
# ============================================================
# Fallback 404
# ============================================================
handle {
header Content-Type "application/json"
respond `{"error":"not_found","message":"The requested resource does not exist."}` 404
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! 🖖 Will try this :) |
Beta Was this translation helpful? Give feedback.
-
No, I haven't noticed yet :) No bother at all, but also - PRs are always welcome! |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone!
We've been investing more in self-hosting lately - including bringing on a new team member (me!) dedicated to improving the experience.
We know there are challenges (we see the issues you've filed!), and we've been working through them. But I'd also love to hear about what's working 🙂
Tell us about your setup:
How would you describe yourself?
What's actually working well for you?
What's the top thing that would make your life with self-hosted Supabase easier?
I’m trying to get a clearer picture of who's running Supabase self-hosted and how it’s going in the wild. Since we prefer not to have telemetry in our open-source projects, your input here directly helps shape our focus.
Quick note: I can't promise immediate fixes for everything - think of this more as helping us understand the audience. That said, I'm definitely interested in hearing about feature gaps, bugs, and requests too.
Thanks for sharing! 🙏
Beta Was this translation helpful? Give feedback.
All reactions