Supabase
Replies: 53 comments 98 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. |
|
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)? |
|
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.... |
|
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. 
|
|
Thanks for asking! Some recent notes here -#39849 |
|
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. |
|
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 |
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. |
|
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)
|
|
@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. |
|
...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. |
|
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 :) |
|
@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. |
|
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). |
|
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 |
|
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
|
|
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? |
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. |
|
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. |
|
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. |
|
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. |
|
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). |
|
Awesome, thanks for the linked resource, i wasn't aware of that. Sure, happy to compare. |
|
Yeah, I went through the same. |
|
Did you get it working to use pg_net? |
|
No, it's not available on AWS Aurora. I think I put a note about the limitations somewhere in that branch :) |
|
Thank you for the amazing product! Setup:
About us:
Working well for us:
Nice to haves:
|
|
Appreciate the feedback! This is noice - "self-hosting for about 2 years now"!! |
|
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) |
|
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. |
|
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. |
|
Interesting :) This looks more like a paid "onprem" option, though? |
|
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. |
|
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. |
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 |
|
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. |
|
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. |
|
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 |
|
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? |
|
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? |
|
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 |
|
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. |
|
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. |
|
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. |
|
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 :) |
|
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. |
|
No problem, glad it helps (merged via PR #46124) :) Looking forward to seeing that Caddyfile! |
Don't want to bother and propably you already noticed but storage added a new env variable |
Here's the Caddyfile (see it evolving here: https://github.com/gatherpeers/supabase-headless/tree/main/caddy) 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
}
}
} |
|
Thanks! 🖖 Will try this :) |
No, I haven't noticed yet :) No bother at all, but also - PRs are always welcome! |
|
Great thread — sharing my setup in case it helps others hitting enterprise-scale challenges: Setup:
What's working well:
Pain points / gotchas:
Would love to see:
Handled similar multi-tenant, enterprise-scale backend workflows on this stack. I work via async sprints for infrastructure integrations — if anyone needs this layer optimized fast without dev overhead, feel free to connect on LinkedIn. |
|
Another update on the state of self-hosted Supabase - following up on the January recap.
Overall, the main focus has been on closing the gap between self-hosted and platform behavior, and also - an easier setup/management of the compose configuration. Setup & management
Documentation
Gateway & auth
Other highlights
Kubernetes
What's next
What I keep in mind, but don't have a clear path for yet
The CHANGELOG.md has the full detail. Thanks to everyone here - the specificity in this thread really helps, and to those who contributed via issues and PRs 🙏 |
|
Quick follow-up to my comment and the Caddyfile I shared afterward: Same idea as before — headless Supabase-compatible API stack, Caddy instead of Kong/Envoy, SQL migrations, two Docker networks, no Studio/Analytics on the runtime path — now with compose, docs, key generation, and supabase-js integration tests. It's in active development (mainly for my product), not an official distribution, and not claiming Cloud/Studio parity. But @aantii's June recap noted a lot of interest in a lighter/headless path with no clear upstream answer yet — so sharing this in case it helps anyone going down the same road. Issues and feedback welcome!! |
|
Cc @luizfelmach, @singh-inder :) |
|
I have an issue with the local Supabase setup for the development of my self service Custom Identity Providers feature. Why is the "Sign In / Providers" disabled for non "IS_PLATFORM" usecses? All while on the UI it is disabled: supabase/apps/studio/components/layouts/AuthLayout/AuthLayout.utils.ts Lines 99 to 101 in 1c827c5 And i would assume that the backend is also disabled but did not have time to look into it yet. |
|
Two things here :) For one, the The For CLI config details refer to Supabase CLI config. For self-hosted Supabase see the how-to guides on the left here. Last but not least - do not use CLI deployment mode as a publicly accessible Supabase instance. Local CLI-run services are supposed to be used in an isolated development-only environment - never to be exposed to any external traffic. |
|
I realize I wrote my comment in a bit of a confusing manner late last night. I meant:
|
It is enabled as in it's functional and you can use it.
No argument here :) It is confusing. There's a lot more work planned for both CLI and Studio going forward, including the improvements to how things are configured (for CLI at least), but at the moment it's along the lines of what I've described above. |
|
Can somebody please entangle me? I think I threw myself into a few too many firsts (first Linux laptop, first ReactNative with Expo, first time using TypeScript, first forced use of Docker to self-hosted Supabase). My aim is to install a self-hosted Supabase using it with ReactNative/Expo. After installing Docker Desktop I googled and somehow found a page that told me to install a dev dependency via npm which I did and after I ran supabase start I could open the Supabase Studio (CLI) on port 54323. The other links shown in the terminal didn't work and as I couldn't see any container in my Docker Desktop running and docker ps didn't show containers either I thought I did something wrong. Nevertheless I tried to create a table which worked. In the evening my husband had a look and went a bit deeper into Linux and finally found the running container. Up until then I tried to find out why it didn't work and then found out that this wasn't actually what I was looking for. The challenges and my questions start with:
Has anybody any idea how to solve this? |
|
@kikru77, appreciate you asking, though it would've been more convenient to have this one as a separate discussion :) I can relate to the confusion experienced here, and it's a common gotcha with misinterpreting CLI as self-hosted Supabase. As far as I could understand you first tried to use your app against a CLI and then also installed the self-hosted configuration. But then you got lost in the process of actually connecting your app project to your locally running self-hosted Supabase. I'll try to answer here, but consider maybe also joining our Discord for more help.
If you really want to use the actual self-hosted Supabase and later re-deploy it somewhere on an external server and expose it to the users of your app, skip the CLI path entirely and familiarize yourself with self-hosted (first, locally on your laptop, then on a remote server). Consider adding an HTTPS proxy configuration on top when deploying externally. I'm hoping this helps, and again - a Discord thread might probably be easier since there might be more people there who have used Expo ReactNative vs a CLI or a self-hosted Supabase instance. |
|
An update on the state of self-hosted Supabase - following up on the June recap.
Setup & management
Documentation
Gateway & proxies
Kubernetes
What's next
Refer to the CHANGELOG.md for a detailed list of changes and updates. |
|
Quick follow-up to the headless stack I shared here. I've been building a Realtime for that setup, and I'm quite proud of it: Sluice. It's a small Go server that streams Postgres changes from the WAL ( The design difference is authorization.
A reduces the policy to a constant (the canonical Same Postgres 18.4, one change, N subscribers on it:
@aantti, if you have a moment I'd love for you to try it, and to share it with the team if it looks useful. Happy to take any feedback. |
|
I created a nuget package for .net aspire. with this it is easy to use Supabase and Realtime, Kong and everything required locally and also deploy it to azure or kubernetes. https://www.nuget.org/packages/Nextended.Aspire.Hosting.Supabase |
|
Hi, we have a self-hosted supabase and when I tried to upload an image on supabase's storage bucket, it didn't go through. But when I tried to use curl for uploading that image, it uploaded it successfully. Here are the following details of our supabase storage:
This is the error log that Kong provided: |
|
This would be more suitable to have in an issue, but also - the configuration above doesn't look like the current self-hosted Supabase... I haven't yet updated Postgrest to v16, your Studio looks like a very old image, and Kong has been deprecated in favor of Envoy. I'd suggest you to check the changlelog and carefully migrate from the old configuration. |
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! 🙏
All reactions