Allow custom domains for API & Storage

[marcinkoziej]

Feature request

Hi!
I'd love to be able to set a custom domain alias for my supabase project url, so that instead:

the users would see "Chose an account to continue to myproject.mydomain.org".

Is your feature request related to a problem? Please describe.

The google sign in will show: "Choose an account to continue to dalihgspogdhpodshhofdgogdssg.supabase.co which looks completely like phishing to anyone who received an 101 phishing-defense training.
So this is not purely aesthetic problem, but a business one - imagine you prototype a product using Supabase (which it is great at) but you loose conversion because users are afraid to sign in (being worried that some strange jfdsljfdsfuds.supabase.co people will get access to their precious Google account)! 😨

Describe the solution you'd like

Implement a basic custom domain support using LetsEncrypt free/automatic cert generation to secure it. Not hard to implement!

This would require:

• setting custom domains in project settings
• supabase proxy generating LetsEncrypt SSL cert to be able to serve the domain securely (alternatively, let user upload a commercial SSL cert)

Describe alternatives you've considered

I did search GH issues to learn if you have considered custom domains and decided against them for reasons; but I could not find any such discussions.

Additional context

None, thank you for great work and FLOSS generosity of your enterprise!

[kiwicopple]

we're working on this 👍

[marcinkoziej]

Great! Waiting with anticipation! <3

[inian]

For this particular issue, you can submit a verification request to Google as documented here

[stingray21]

Apparently there is a way to set this up for Firebase link. I was wondering if the same approach would work for supabase, too. I couldn't get it to work yet though, but that could very likely be my fault.

[marcinkoziej]

Apparently there is a way to set this up for Firebase link. I was wondering if the same approach would work for supabase, too. I couldn't get it to work yet though, but that could very likely be my fault.

This can only work if Supabase will allow a authDomain parameter where you pass your custom domain that is mapped to supabase project domain. So we need to wait for the team to implement such feature.

[marcinkoziej]

Hey @kiwicopple ! Is there a timeline for custom domains ?
This issue got more pressing because now Google urges to verify the domains used in Oauth (they send emails like the one below).
Because I have no control over the Supabase project domain, nor can I put a verification file in there, there is not way to verify Supabase instance - and It's a matter of time before Google will cut of the Oauth provisioning. Help!

[gauntface]

I just went through the OAuth flow for Google and quickly realized this would be an issue for me as well.

[alvinsga]

Is there an ETA for this feature?

[amaralc]

Same issue here. This would be great indeed.

[joshdance]

Found this thread looking for info on Supabase custom domains, would love this feature as well.

[hatton]

Since we can't launch until this happens, I'm wondering if we should just use deno.land directly, as they do offer custom domains. We'd lose the nice built-in SUPABASE_SERVICE_ROLE_KEY environment variable but aside from that, is there anything else that we'd lose vs. doing the deno functions in Supabase itself?

[wh1337]

Just out of curiosity, do we have an ETA for this feature? 👀

[kiwicopple]

@J0 - I don't think this one is specific to Auth. We will need to add custom domains on the project-level. I'll transfer this back to the main repo for discoverability

To everyone else: I'm very sorry, we don't have a timeline yet. I realise this is impacting a lot of people - we have quite a backlog of tasks to get through and we're doing our best. I'll drop a timeline here as soon as I have 80% confidence on delivery dates

[matheustav]

Hi! I'd love to be able to use Cloudflare proxy to route api.example.com to supabase URL.

This way I would have:
1 - Custom domain
2 - Rate limitting / WAF (from Cloudflare)
3 - Queries cache based on endpoints/requests

Since Supabase limits the bandwidth, rate limitting and cache are essential for me, otherwise a malicious user could easily flood its endpoints.

Unfortunately at this moment if I try to use Cloudflare CNAME proxy I get this error:

Error 1014 - CNAME Cross-User Banned 

What happened?
You've requested a page on a website that is part of the Cloudflare network.
The host is configured as a CNAME across accounts on Cloudflare, which is prohibited by security policy.

AFAIK this happens because the xxxxx.supabase.co endpoint is already hosted at Cloudflare and for security reasons I'm not allowed to create this DNS record for my subdomain.

Is there a way to achieve this that I'm not seeing?
Maybe if I could get access to the IP address directly from AWS instance instead of xxxxx.supabase.co at Supabase admin this could be solved.

[killshot13]

Hi! I'd love to be able to use Cloudflare proxy to route api.example.com to supabase URL.

This way I would have: 1 - Custom domain 2 - Rate limitting / WAF (from Cloudflare) 3 - Queries cache based on endpoints/requests

Since Supabase limits the bandwidth, rate limitting and cache are essential for me, otherwise a malicious user could easily flood its endpoints.

Unfortunately at this moment if I try to use Cloudflare CNAME proxy I get this error:

Error 1014 - CNAME Cross-User Banned 

What happened?
You've requested a page on a website that is part of the Cloudflare network.
The host is configured as a CNAME across accounts on Cloudflare, which is prohibited by security policy.

AFAIK this happens because the xxxxx.supabase.co endpoint is already hosted at Cloudflare and for security reasons I'm not allowed to create this DNS record for my subdomain.

Is there a way to achieve this that I'm not seeing? Maybe if I could get access to the IP address directly from AWS instance instead of xxxxx.supabase.co at Supabase admin this could be solved.

Same problem here... Tried using an owned subdomain and CNAME'ing it to point to the Supabase subdomain, but no dice.

---

---

[aquaductape]

Any updates? Users don't like seeing the supabase url with the random characters cuz it makes our application look sketchy.

[madeleineostoja]

Yep I just launched a private beta for a product using Supabase and several users have already pinged me with this "security concern". It might seem like it's just visuals but it does significantly impact the adoptability of Supabase, and if it's not solved while we're in beta we'll probably be looking to migrate to another auth provider for OAuth. For now I'm disabling OAuth entirely, I'd rather have a less featured app than one that made users worry about our legitimacy.

[0xmax]

@kiwicopple Any updates on this? I understand you have a lot of (amazing!) stuff on the list but this is a blocking issue for a lot of users. No way to work around this client side unfortunately.

[inian]

Hi, this feature is coming soon. Please email [email protected] if you want to be on the waitlist when this launches.

[abhay187]

@inian and @kiwicopple update this thread when the fix is launched. Waiting eagerly.

[DevOfManyThings]

@inian I emailed that address a week ago, is there supposed to be any response from them? Haven't had any confirmation or request for account info to put me on the waiting list

[inian]

Hi @DevOfManyThings, we are emailing folks in batches depending on when they signed up. Keep an eye out!

[madeleineostoja]

Just got the email, to say I have sticker shock is an understatement. Totally get charging healthily for enterprise features, but whitelabelling oauth for a production app is not one of those imo. I’ll likely be looking for another authentication layer before we leave beta, supabase auth has felt really undercooked so far

[madeleineostoja]

Custom domains are still in private beta afaik, you need to email supabase to request access. After a lot of faffing with setup (feedback to supabase team — I think this needs to be smoothed over before general release) mine is working well

[roryw10]

@alex-galey as Inian mentioned a little further up the thread, you can email [email protected] to get early access to custom domains.

@madeleineostoja thanks for the feedback - we can appreciate that the experience getting set up with custom domains can be improved and we are working on it. We hope you can appreciate there can be some some trade offs with early access to new features so once things are working more smoothly we can release this at a platform level.

[alex-galey]

Thank you for your answer about custom domain enquiry @roryw10.
Do you have any information about a decision you would take to allow CNAME from Cloudflare ?
Solution is known and given by Clouflare support here.

[activenode]

I think allowing for simple CNAME would smoothen this and also make it simpler for everybody. I would also even pay for CNAME support but I think it'd be the best solution.

[activenode]

@ALL here: My problem still wouldn't be exactly solved with ONE custom domain for the supabase project because I have a multi-tenant SaaS so I'd need multiple custom domains which is also not supported in beta right now.

For everyone wanting a quick-win:

Create a supabase table shortlinks (hash, link) and simply send your own emails. That's what I do now and that will request a link from the Supabase API, insert it with a random hash into shortlinks table and then you go with whatever email you wanna send mydomain.com/short/$HASH and you read from the database and redirect. Done.

It's the best workaround you can find right now I think.

---

Sure: That doesn't solve the problem of network requests still showing as *.supabase.co but it's a good compromise especially in combination with adding one custom domain in the form of mygenericservicedomain.com

[darora]

@alex-galey our custom domain offering guides you through the setup needed to use a CNAME on Cloudflare (or any other provider), and uses the offering mentioned in the support page ("SSL for SaaS") you've linked (https://supabase.com/docs/guides/platform/custom-domains). The steps are required to make sure all the required components (e.g. auth, routing) get configured correctly.

As @activenode mentioned, currently we're offering a single custom domain per project. In the future we might support multiple domains, but that requires additional work to be performed on the auth service, and is not currently scheduled.

[GorvGoyl]

there's this solution mentioned but haven't tried yet #2925 (comment)

[TylerAHolden]

I think this issue is resolved with Custom Domain Add-on

[darora]

Indeed, closing this out.

[activenode]

Yes and no. What's still left is multi-tenant domain support.

[joshdance]

Yes and no. What's still left is multi-tenant domain support.

Multi-tenant support be a good candidate for a new issue?

[activenode]

https://github.com/orgs/supabase/discussions/13693

[StefanFlaschko]

@alex-galey our custom domain offering guides you through the setup needed to use a CNAME on Cloudflare (or any other provider), and uses the offering mentioned in the support page ("SSL for SaaS") you've linked (https://supabase.com/docs/guides/platform/custom-domains). The steps are required to make sure all the required components (e.g. auth, routing) get configured correctly.

As @activenode mentioned, currently we're offering a single custom domain per project. In the future we might support multiple domains, but that requires additional work to be performed on the auth service, and is not currently scheduled.

is this "single custom domain" included in the 25$ plan, or is it an additional 10$ ?

[miguelgargallo]

still 2023 Dec, no way to add custom domain on open source? this seems to force clients to pay

[activenode]

still 2023 Dec, no way to add custom domain on open source? this seems to force clients to pay

What do you mean by that? As you stated yourself, it's open source. So if you use that open source version on your server you can certainly have your custom domain.

I don't understand the problem.

Or do you mean "no way to add custom domain on the free tier"? If you mean that then yes, there is no way because it's a paid feature. How else would Supabase be able to make money? They have to pay bills as well.

[miguelgargallo]

Nothing is opensource if on production is not ready, have to setup a domain with caddy without the help of the team... Look at pocketbase @activenode

[activenode]

I feel like there is a big misunderstanding what Open Source means as well as what Supabase is supposed to do. Even though we're diverging from the actual topic, let me state a few points: Supabase is a company with people that have to pay bills, so every open source work they do is certainly volunatrily. If they wanted, they could just go closed-source. But they don't because Open Source (which means the code is publicly available) is one of their core principles. Also one of the principles of Supabase is to have well-separated services that do one special thing. For people to be able to manage Supabase in exactly the way they need it (you mentioned Caddy, I take npm, others use traefik), there is no predefined way of how this is done. This is, with self-hosting, up to the one who wants to implement it so that nobody, doing self-hosting, gets limited in any way.

So even if you'd pay for it, it wouldn't change the way self-hosting works really. There is Kong as a Service Orchestrator and you can pretty easily configure kong as you like (using a custom domain) or use Cadddy, npm or Traefik on top. That's the idea behind it and I wouldn't want it ANY other way.

I also want to highlight again that Supabase is doing everything to provide YOU everything you need to self-host and configure on your own.

Pocketbase is Pocketbase, Supabase is Supabase. If you like Pocketbase more, why don't you use Pocketbase then?
I feel quite some anger in here and I'm stopping my responses now, just was feeling to clarify a few things here.

Closing sentence: On supabase.com you can have custom domains if you pay (fair) and self-hosted you can always have custom domains with your own proxy (which you must use anyway the way it works).

Fyi: It's visible for everyone that you are the one who upvoted your own comment and downvoted mine :).

Have a good day.

[miguelgargallo]

I feel like there is a big misunderstanding what Open Source means as well as what Supabase is supposed to do. Even though we're diverging from the actual topic, let me state a few points: Supabase is a company with people that have to pay bills, so every open source work they do is certainly volunatrily. If they wanted, they could just go closed-source. But they don't because Open Source (which means the code is publicly available) is one of their core principles. Also one of the principles of Supabase is to have well-separated services that do one special thing. For people to be able to manage Supabase in exactly the way they need it (you mentioned Caddy, I take npm, others use traefik), there is no predefined way of how this is done. This is, with self-hosting, up to the one who wants to implement it so that nobody, doing self-hosting, gets limited in any way.

So even if you'd pay for it, it wouldn't change the way self-hosting works really. There is Kong as a Service Orchestrator and you can pretty easily configure kong as you like (using a custom domain) or use Cadddy, npm or Traefik on top. That's the idea behind it and I wouldn't want it ANY other way.

I also want to highlight again that Supabase is doing everything to provide YOU everything you need to self-host and configure on your own.

Pocketbase is Pocketbase, Supabase is Supabase. If you like Pocketbase more, why don't you use Pocketbase then?

I feel quite some anger in here and I'm stopping my responses now, just was feeling to clarify a few things here.

Closing sentence: On supabase.com you can have custom domains if you pay (fair) and self-hosted you can always have custom domains with your own proxy (which you must use anyway the way it works).

Fyi: It's visible for everyone that you are the one who upvoted your own comment and downvoted mine :).

Have a good day.

I understand the challenges and financial realities that Supabase faces as a company, and I appreciate the hard work that goes into developing such a complex platform. However, there’s a critical point that needs emphasis: the ability to deploy securely in an open-source environment. If achieving this is overly complex or gated behind paid features, it undermines the core value of open-source software. While I empathize with the business aspect, it’s important to ensure that promoting a product as open-source isn’t misleading if key functionalities for secure deployment aren’t realistically accessible. It’s not about comparing Supabase with other platforms, but about a genuine commitment to making open-source software secure, functional, and truly accessible for everyone.

[activenode]

This discussion is leading nowhere and is just going round in circles.

However, there’s a critical point that needs emphasis: the ability to deploy securely in an open-source environment.
Totally given. The services are secure, the docs tell you multiple options how to do it (https://supabase.com/docs/guides/self-hosting) - those mulitple options are a feature, not a disadvantage. It allows to integrate with the infrastructure of your choice.

If you feel that's too complicated then, don't self-host. I want to highlight: there is no fee to pay for having custom domains on the self-hosted version.

This btw. is the exact same thing with many other software. Take https://listmonk.app/ for example. That one also is just a container. You have to make sure to use Caddy or whatever to have a custom domain. That's actually industry-standard.

If achieving this is overly complex or gated behind paid features

Neither is it overly complex, there's a docker directory in the supabase repo and it contains the required config files nor is providing the custom domain feature on the SaaS supabase.com as a paid feature a security limitation.

it undermines the core value of open-source software

No, it does not. The definition of open-source is: the code is publicly visible. There are open-source licenses which grant you not even a single thing but only the possibility to be looking at the code.
You have a misconception of open-source. Supabase is one of the best ones in this regards already as, AFAIK, everything is MIT or Apache 2.0. Meaning: If you're dissatisfied with anything of it, you can literally legally STEAL all of that and make it as you wish.

Or even better: If YOU think that there's something it should have, why don't you propose something, discuss it and contribute it back to Supabase. If other people share your requirement, we all win when you contribute it.

Every added code adds complexity and shall be avoided at all costs if it doesn't benefit the majority of the target group and hence the product. I'd fear that your proposal of making it easier for "beginners in server infrastructure" would limit those that are experienced in server infrastructure and are the actual ones that should self-host. With low experience in servers, infrastructure, etc. I would not recommend to do self-hosting because of the security implications (not talking about Supabase).

if key functionalities for secure deployment aren’t realistically accessible

As a matter of fact, that's simply not true. I can do that in less than 30mins. Configure the configs, edit the docker-compose, add a proxy (e.g. npm) on top of Kong, add the domain. Done.
But that's just ONE solution and certainly other people want to do it differently and that could be one of the arguments why a pre-defined solution wouldn't be helpful. The Services withing kong communicate over a local network and you have to expose to it to the outside.

A really last remark on that one: How do you think Supabase.com does it? They also have to run the instances there and add the infrastructure of their choice to link custom domains to your instances. That costs money, so why should it be free? Not even the free tier should be free by that definition but IT IS.

[miguelgargallo]

This discussion is leading nowhere and is just going round in circles.

However, there’s a critical point that needs emphasis: the ability to deploy securely in an open-source environment.

Totally given. The services are secure, the docs tell you multiple options how to do it (https://supabase.com/docs/guides/self-hosting) - those mulitple options are a feature, not a disadvantage. It allows to integrate with the infrastructure of your choice.

If you feel that's too complicated then, don't self-host. I want to highlight: there is no fee to pay for having custom domains on the self-hosted version.

This btw. is the exact same thing with many other software. Take https://listmonk.app/ for example. That one also is just a container. You have to make sure to use Caddy or whatever to have a custom domain. That's actually industry-standard.

If achieving this is overly complex or gated behind paid features

Neither is it overly complex, there's a docker directory in the supabase repo and it contains the required config files nor is providing the custom domain feature on the SaaS supabase.com as a paid feature a security limitation.

it undermines the core value of open-source software

No, it does not. The definition of open-source is: the code is publicly visible. There are open-source licenses which grant you not even a single thing but only the possibility to be looking at the code.

You have a misconception of open-source. Supabase is one of the best ones in this regards already as, AFAIK, everything is MIT or Apache 2.0. Meaning: If you're dissatisfied with anything of it, you can literally legally STEAL all of that and make it as you wish.

Or even better: If YOU think that there's something it should have, why don't you propose something, discuss it and contribute it back to Supabase. If other people share your requirement, we all win when you contribute it.

Every added code adds complexity and shall be avoided at all costs if it doesn't benefit the majority of the target group and hence the product. I'd fear that your proposal of making it easier for "beginners in server infrastructure" would limit those that are experienced in server infrastructure and are the actual ones that should self-host. With low experience in servers, infrastructure, etc. I would not recommend to do self-hosting because of the security implications (not talking about Supabase).

if key functionalities for secure deployment aren’t realistically accessible

As a matter of fact, that's simply not true. I can do that in less than 30mins. Configure the configs, edit the docker-compose, add a proxy (e.g. npm) on top of Kong, add the domain. Done.

But that's just ONE solution and certainly other people want to do it differently and that could be one of the arguments why a pre-defined solution wouldn't be helpful. The Services withing kong communicate over a local network and you have to expose to it to the outside.

A really last remark on that one: How do you think Supabase.com does it? They also have to run the instances there and add the infrastructure of their choice to link custom domains to your instances. That costs money, so why should it be free? Not even the free tier should be free by that definition but IT IS.

No, I will tell you facts:

While I acknowledge your explanation, it still does not address the absence of fundamental elements like a login panel, SSL, and domain support in the self-hosted version of Supabase. These are not just features but necessities for a secure and functional deployment. The lack of these basic elements is a significant oversight, especially considering their importance in any production environment. This isn’t just about the complexity of deployment or the flexibility of the infrastructure. It’s about providing essential tools that are standard in today’s web development landscape. My point is not to diminish the work done by Supabase but to highlight a gap that critically affects the utility and security of the platform for a wide range of users. Addressing these gaps would not only enhance the platform’s functionality but also demonstrate a true commitment to the open-source community and its diverse needs.

[activenode]

No, I will tell you facts:

Hm interesting. Reads like an opinion.

but to highlight a gap that critically affects the utility and security of the platform for a wide range of users

Users that self-host such a system on their own server are well-aware of the infrastructural needs or else IMO they should not self-host for the sake of their own security. What you're stating is a Paradoxon.

It’s about providing essential tools that are standard in today’s web development landscape.

That's why it's so easy to run another container with Nginx Proxy Manager or Caddy. Those are the essential tools that allow everyone to choose their solution without Supabase dictating it.

absence of fundamental elements like a login panel, SSL, and domain support in the self-hosted version of Supabase

Why doesn't NextJS have built-in SSL and custom domains? It has even a built-in server so why not? Why can't I just tell NextJS to do everything including LetsEncrypt?

You are trying to enforce your vision on the product here. I could state a lot of things that speak against these things built-in when self-hosting but I'll refrain from further explanations as I'm not feeling like you're trying to reflect from an alternative perspective.

It's not like the Supabase team removed stuff from the sourcecode to make it harder for you. They just built their own infrastructure around the Supabase instances - which are open-source. Not the supabase.com infrastructure is open-source, the underlying product is.

See, all the repos here are open-source. Take that frustration and translate it into the thing you're seeking whilst making sure everyone is served, both the yay/nay-sayers to what you want and everybody wins.

[miguelgargallo]

No, I will tell you facts:

Hm interesting. Reads like an opinion.

but to highlight a gap that critically affects the utility and security of the platform for a wide range of users

Users that self-host such a system on their own server are well-aware of the infrastructural needs or else IMO they should not self-host for the sake of their own security. What you're stating is a Paradoxon.

It’s about providing essential tools that are standard in today’s web development landscape.

That's why it's so easy to run another container with Nginx Proxy Manager or Caddy. Those are the essential tools that allow everyone to choose their solution without Supabase dictating it.

absence of fundamental elements like a login panel, SSL, and domain support in the self-hosted version of Supabase

Why doesn't NextJS have built-in SSL and custom domains? It has even a built-in server so why not? Why can't I just tell NextJS to do everything including LetsEncrypt?

You are trying to enforce your vision on the product here. I could state a lot of things that speak against these things built-in when self-hosting but I'll refrain from further explanations as I'm not feeling like you're trying to reflect from an alternative perspective.

It's not like the Supabase team removed stuff from the sourcecode to make it harder for you. They just built their own infrastructure around the Supabase instances - which are open-source. Not the supabase.com infrastructure is open-source, the underlying product is.

See, all the repos here are open-source. Take that frustration and translate it into the thing you're seeking whilst making sure everyone is served, both the yay/nay-sayers to what you want and everybody wins.

1. “Facts” refer to concrete realities experienced firsthand, not mere opinions. My observations are grounded in my direct experiences with the platform.

2. This dialogue is not a personal crusade. My involvement is driven by a commitment to the core values of open-source. Here’s a relevant issue for reference: Supabase GitHub Issue Allow custom domains for API & Storage #12429. Liked and supported by hundreds.

3. It is disconcerting to witness a trend where the community is expected to build out essential functionalities that would elevate Supabase as a viable production tool. This approach, seemingly outsourcing critical development to users who are not employed by Supabase, feels dismissive and underestimates the community’s intelligence. As a staunch supporter of open-source values, such responses are concerning and seem to diverge from the ethos of collaborative and accessible software development.

[OddDev]

Yes, I'd suggest to go to the Linux kernel next and tell them to provide a GUI installer.

[activenode]

Ok so I provided a lot of facts and background knowledge in the above discussion to explain you why this ticket, rightfully, is closed and why your request is your request and not a security concern or whatsoever at all. Paul also has responded to this already saying similiar things like I did (#19949 (comment)) also pointing back to its scalability.

Here’s a relevant issue for reference: Supabase GitHub Issue #12429. Liked and supported by hundreds.

You just self-referenced this ticket which is implemented and closed. At this point I get the feeling I'm talking to an AI Chatbot...

It is disconcerting to witness a trend where the community is expected to build out essential functionalities that would elevate Supabase as a viable production tool.

There is no would. It IS a viable production tool right now. Period. There's no discussion to be made here.

Let me summarize all of what you said:

• You want something to make it easier for inexperienced people to self-host on Production systems which is a paradoxon.
• There is no elevation of it being a production tool by doing what you want. It is a production tool right now.
• You argue like your request would elevate Supabases Business somehow. It does not.
• You also argue that they are "outsourcing critical development". Neither is your request critical by no means, nor does Supabase outsource critical development. Quite the opposite is the case rn.
• Then you are saying you are not willing to contribute because Supabase should implement something YOU want but there's equally enough people that'd be constrained by what you want.
• Plus: You didn't respond to any of my questions e.g. why NextJS doesn't have what you are requesting.

All of that really makes it feel like you're kinda stuck somewhere with self-hosting and are trying to impose that on a feature being implemented trying to argue with really paradox statements like what open-source is which frankly is really drawing a picture of greediness and selfishness much more than any kind of contribution.

See what you want is essentially another project on top of Supabase. It should most definitely not be part of Supabase itself. Something like supabase-self-hosted-kickstart. But then again, there's no universal solution for this to make everyone happy - coming back to: the way it is right now, everybody is served and no one is constrained.

A few goto links:

• https://www.linode.com/docs/guides/installing-supabase/
• https://supabase.com/docs/guides/self-hosting/docker
• https://blog.activenode.de/the-ultimate-supabase-self-hosting-guide

[miguelgargallo]

Ok so I provided a lot of facts and background knowledge in the above discussion to explain you why this ticket, rightfully, is closed and why your request is your request and not a security concern or whatsoever at all. Paul also has responded to this already saying similiar things like I did (#19949 (comment)) also pointing back to its scalability.

Here’s a relevant issue for reference: Supabase GitHub Issue #12429. Liked and supported by hundreds.

You just self-referenced this ticket which is implemented and closed. At this point I get the feeling I'm talking to an AI Chatbot...

It is disconcerting to witness a trend where the community is expected to build out essential functionalities that would elevate Supabase as a viable production tool.

There is no would. It IS a viable production tool right now. Period. There's no discussion to be made here.

Let me summarize all of what you said:

• You want something to make it easier for inexperienced people to self-host on Production systems which is a paradoxon.

• There is no elevation of it being a production tool by doing what you want. It is a production tool right now.

• You argue like your request would elevate Supabases Business somehow. It does not.

• You also argue that they are "outsourcing critical development". Neither is your request critical by no means, nor does Supabase outsource critical development. Quite the opposite is the case rn.

• Then you are saying you are not willing to contribute because Supabase should implement something YOU want but there's equally enough people that'd be constrained by what you want.

• Plus: You didn't respond to any of my questions e.g. why NextJS doesn't have what you are requesting.

All of that really makes it feel like you're kinda stuck somewhere with self-hosting and are trying to impose that on a feature being implemented trying to argue with really paradox statements like what open-source is which frankly is really drawing a picture of greediness and selfishness much more than any kind of contribution.

See what you want is essentially another project on top of Supabase. It should most definitely not be part of Supabase itself. Something like supabase-self-hosted-kickstart. But then again, there's no universal solution for this to make everyone happy - coming back to: the way it is right now, everybody is served and no one is constrained.

A few goto links:

• https://www.linode.com/docs/guides/installing-supabase/

• https://supabase.com/docs/guides/self-hosting/docker

• https://blog.activenode.de/the-ultimate-supabase-self-hosting-guide

Hey, stop okay, this is not a personal thing, begin to face the reality and answer to other users that claims the same.

Do not answer only to me, answer to the people like: @anasfik #19949 (comment)