aantti

It is. Hopefully gets fixed at some point.

or check supabase.com/contribute 🙂

> self hosting supabase [...] The supabase CLI Just as a side note - do not use "CLI" for "self-hosting" please 🙂 It is not a production-ready setup that you're getting with CLI-launched containers. Self-hosted is described here https://supabase.com/docs/guides/self-hosting - and it generally works with Podman. If something won't start - would appreciate an issue.

No easy way unfortunately aside from spinning an instance per project. (Actually this is matching the current managed Supabase architecture, it's just that those instances are managed by a gigantic internal orchestrator.)

Can you try it in an absolutely new environment? 🙂 Also - use the latest everything in `supabase/docker`? Clean all containers, images, volumes, etc. E.g., when accidentally starting a "new project" on top of an old direvtory with, e.g., existing `volumes/db/data` - that wouldn't work.

https://supabase.com/docs/guides/self-hosting/ 🙂

You shouldn't be using CLI-launched Supabase containters exposed to the Internet. This setup is completely unprotected.

There's no pooler in CLI-launched Supabase, Postgres can be accessed directly; however, I'm hoping this isn't about using CLI for any external traffic - this is s highly insecure setup, all keys and passwords are hardcoded.

If you skip analytics (logflare), should hopefully squeeze in a couple of GB. Someone just did a lot of experimentation and noted the memory usage https://dev.to/voieducode/part-1-i-rebuilt-supabase-from-scratch-to-understand-what-i-was-paying-for-3oip (without Logflare, btw) An example minimal config here that should be even less - https://github.com/supabase/supabase/blob/self-hosted/minimal-config/docker/docker-compose.min.yml with just Auth, Postgres, PostgREST, Kong, and Studio

Yeah, no problem 🙂 Re the branch you've mentioned above that I experimented in last year - I have to update it, it's the state of self-hosted Supabase as of July 2025 in that branch, afair. There's no official configuration like that, because it will still come with certain limitations (described in https://github.com/aantti/supabase/blob/self-hosting/aws-aurora/aws/aurora/notes-on-aurora-restrictions.md)

Kong just checks for the `apikey` header and matches keys (comparing them as strings) to internal ACLs, it doesn't actually verify or parse the key. If no `apikey` header, Kong will respond with `"message":"No API key found in request` The error you're getting means Kong couldn't match the `apikey` to anything, I'm guessing. Do you see the key in both the env vars inside the Kong container, and in the `kong.yml`? Check with `docker exec supabase-kong cat /home/kong/kong.yml` ? Also, what is your `ANON_KEY` - is it a symmetric JWT API key? (Self-hosted currently still doesn't have a configuration for the new opaque `sb_` API keys.)

Kong just checks for the apikey header and matches anon & service_role to internal ACLs, it doesn't actually verify the key. If no apikey header, Kong will respond with `"message":"No API key found in request` The error you're getting is from PostgREST, I think. Where did you get the anon api key from? 🙂 Is that a legacy symmetric JWT API key or?...

Just updated - https://status.supabase.com/

No easy way to just use multiple databases inside one server. So yes, basically should be cluster level separation. The setup largely mimicks what you have on platform inside your own customer instance. Two projects = two EC2 instances, etc.

Multi-projects is not supported by the not `IS_PLATFORM` code path in the current Studio, no (due to the lack of the management layer API on platform), but yes, you can just spin off separate instances of self-hosted inside your EKS and point them to separate databases on Aurora? There are some third party solutions to make it look more like "multiple projects" I think. Also - have a look at supabase-kubernetes repo in supabase-community, it's well-maintained again now.

Did you mean you'd like to set up [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) on top of Aurora Postgres?

If self-hosted (not CLI), then via env vars in .env - I'm actually writing a how-to atm.

Good to know 🙂 Cc <@869319595784290395>

I think, <@869319595784290395> just solved this a bit more via https://github.com/supabase/supabase/pull/40822 🙂

A quick note about the Helm chart repo - <@367474243966992394> became the main contributor and maintainer 🙂 We'll be working on improving it and keeping it in sync with the upstream [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting) configuration (Docker Compose). Most of the stuff has been already fixed and more WIP. Huge kudos to Luiz 🖖

As a quick update - maintenance for Helm chart restarted with <@367474243966992394> as the new maintainer and main contributor 🙂 Should work!

Hey, yes, I did update the Storage settings while integrating some of the <@869319595784290395>'s fixes, and as a clean-up effort while adding a couple of how-to's [here](https://supabase.com/docs/guides/self-hosting/self-hosted-s3) and [here](https://supabase.com/docs/guides/self-hosting/copy-from-platform-s3). The changes are reflected in the [CHANGELOG](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) 🙂 Apologies if this caused inconveninces, as I can't realistically also support any 3rd party deployment options such as Coolify... That said, I'm trying to maintain a reasonable common "upstream self-hosted Supabase configuration." What did break for you with Coolify?

I guess that was me 🙂 You have to check the latest configuration snapshot here https://github.com/supabase/supabase/tree/master/docker (make sure to check CHANGELOG), and update docker-compose.yml and other parts accordingly. For edge functions UI and for the SQL snippets UI in particular - Studio has to have mounts for volumes/functions and volumes/snippets

I have a minimal Docker Compose here if you could try launching only Postgres, Auth, Kong, Studio, Posgtrest, and postgres-meta (technically Posgtrest and Auth could be skipped too if you don't need them) - https://github.com/supabase/supabase/blob/self-hosted/minimal-config/docker/docker-compose.min.yml

Curious, how much memory on this server? Can you check if it's lack of memory? E.g., `docker inspect supabase-db --format='{{.State.OOMKilled}}'`

I haven't added a new configuration mimicking the platform with the new api keys (`sb_`) keys and new asymmetric jtw user session tokens yet. Technically, Auth can be configured similarly to what's on platform.

Can also be installed via `brew` - but I'd agree it's super confusing. When no-brew, it should be installed in the local project to be able to use `npx supabase` (I think), and when via brew - can be just `supabase`. You can also build it locally with `go build` && `go install` and use your own build.

<@1248043582506532904>

Hard to say to be fair 🙂 I'd be curious in hearing any feedback too. Generally, self-hosted is this - https://supabase.com/docs/guides/self-hosting (NOT THIS - https://supabase.com/docs/guides/local-development !!) So I'd expect any VM that can run Docker + Compose to be good enough. There's also a reference Helm chart here - https://github.com/supabase-community/supabase-kubernetes/ Note: it's not generally possible to use hosted Azure Postgres 1:1 and keep everything working, but some stuff might work - will require quite a bit of editing and digging into the Postgres container migrations and extracting what's needed to properly configure an external managed database

apologies for this one; 1.37.1 should just start cleanly

You can also check [discussions](https://github.com/orgs/supabase/discussions) and [issues](https://github.com/supabase/supabase/issues), <@1023182692575084605> - I'm trying to keep the "self-hosted" labeling accurate. There's also this one - https://github.com/orgs/supabase/discussions/39820 that might be useful to skim-read / summarize with an LLM.

<@1023182692575084605> Re updates - briefly described here - https://supabase.com/docs/guides/self-hosting/docker#updating, but I'd also advise to check [CHANGELOG](https://github.com/supabase/supabase/blob/master/docker/CHANGELOG.md) and [versions.md](https://github.com/supabase/supabase/blob/master/docker/versions.md); I'm trying to maintain a monthly "release" schedule now. The downtime depends - usually it's the time it takes to (re)create and restart the containers.

<@1023182692575084605> "Is there a clear list somewhere of which paid features are strictly Cloud/control-plane features (Branching, Dashboard SSO, managed backup/restore UX, etc.)" => unfortunately not a very clear list anywhere, but happy to elaborate / help to assess. Some of these were already answered above. Most of Supabase - basically all "products" are fully permissive open source, and even Studio codebase is. The differences between self-hosted and platform are mostly stemming from the missing platform APIs - that are sometimes about the configuration convenience mostly (e.g. UI vs .env for Auth, and other settings), but sometimes it's also much more complex "orchestration" level functionality like easy updates or backups or else. Dashboard SSO - if you mean having a better auth in Studio, that's possible either via an external authentication at the additional proxy level, or via some minimal modifications to the Studio code to authorize against locally running Auth.

<@1023182692575084605> re "custom role passwords, secrets/keys," - self-hosted is currently "symmetric JWT" and "legacy API keys," but I'm planning to add an option to configure and use "new opaque API keys" and "asymmetric JWT" - application architecture -wise it will match platform experience, I'm hoping; actual implementation will be a bit simpler (probably along the line of what CLI already moved to)

great help as always <@764524500162445402> and <@869319595784290395>! <@1023182692575084605> - product marketing team is working on an updated feature matrix here https://supabase.com/features (I'm thinking it will evolve a bit more to check self-hosted vs platform easier) Also, see https://discord.com/channels/839993398554656828/1464577736654721115/1465369722114801696 ("main employee for self-hosted" - that'd be me)

<@1248043582506532904> fyi

<@1248043582506532904> fyi

<@1248043582506532904> fyi

> well I guess I gonna start with supabase cloud version, later I may move to self hosting it <@1319766540584751145> Probably the best way to familiarize yourself with Supabase and related application architecture, then decide 🙂 To answer your question about the feature gaps - as mentioned above, it's mostly about lacking configuration UI (in platform those components all connect to platform configuration APIs), but also the following isn't implemented: - Multiple organizations and multiple projects (you'll have to start a separate instance of [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting/docker) per "project") - Configuring email templates, SMTP, Auth, Replication via UI - Branching - Supabase "products metrics" - Analytics and vector buckets - ETL - Backups via UI (I think this one is fairly obvious) A bit more about the resposibilities divide here: https://supabase.com/docs/guides/self-hosting#your-responsibilities-when-self-hosting Last but not least - [local development & CLI ](https://supabase.com/docs/guides/local-development)is NOT [self-hosted Supabase](https://supabase.com/docs/guides/self-hosting). Do not use CLI-run containers for "self-hosted Supabase" purposes, that was not meant to be a configuration ever to be exposed to any external traffic.

> The biggest gap is in the JWT token types & algo These are configurable. And if you meant the migration to the new opaque API keys, this is planned - we have to figure out what's the best way to implement it without much overhead.

<@1248043582506532904> fyi

> But could you tell me when this jwt auth changed from legacy one? There was a fairly quiet switch that CLI did a couple of weeks ago - defaulting to using asymmetric keypair and new asymmetric JWT tokens. In addition, a bug was introduced where `status -o env` keeps displaying different "keys." I've tried to explain what happened here - https://github.com/supabase/cli/issues/4524#issuecomment-3794549522 Quite a bit of confusion unfortunately going on. A recommendation would be to start switching to using new opaque API keys - or downgrade CLI. Separately "verify jwt" option disables previously existing checks for the JWT API keys (the "legacy API keys"), it's not about "disabling checking JWT user session tokens" or else. You can read more about the new asymmetric JWT and the new opaque API keys here: https://supabase.com/docs/guides/auth/signing-keys https://supabase.com/docs/guides/api/api-keys Last but not least, just in case - do not use CLI-started containers in any unprotected network environment - CLI containers are for isolated local development only.

<@1248043582506532904> fyi

<@1248043582506532904> fyi

<@981289715800109116> You can reach out to the growth team I guess https://forms.supabase.com/enterprise (and/or https://supabase.com/contact/sales) for inquiries. It is not startups only that use Supabase in production.

Complete configuration will not unfortunately fit into 2GB RAM atm, <@526697728185466881> - not with Logflare/Analytics. But you can just use what you need, e.g., here's an example of a reduced configuration - https://github.com/supabase/supabase/blob/self-hosted/minimal-config/docker/docker-compose.min.yml

Same as here? https://www.reddit.com/r/Supabase/comments/1qhwz0g/cant_login_to_supabase_postgres_db_through_docker/ I'm still not sure what's going on with this one 🙂

There aren't any standard configurations for that and it may not work fully the way you expect it to (because of certain limitations of RDS & Aurora). If you're interested, I did a project along these lines last summer (will probably need an update but should give you a good idea) - https://github.com/aantti/supabase/tree/self-hosting/aws-aurora/aws/aurora It describes pretty much everything you have to be aware of, including the limitations and gotchas. Hope this helps, <@398594671254831104>

> posts are not monitored by them I'd say some people are checking but irregularly vs the SupaSquad community folks 💪

I'm not in legal, but this seems ok to me <@313663116854558721> - I don't see any red flags in what you've asked and shared. Should be absolutely fine.