Threads
Loading user profile...
Terry Sutton announced a new feature allowing developers to provision a Supabase project using the Stripe CLI as part of the Stripe Projects developer preview. This integration simplifies the setup process by providing a full Supabase project with one command. A user inquired about the integration's automatic capabilities with Stripe.
Terry Sutton is seeking volunteers for the SupaSquad to support the Supabase subreddit. The goal is to enhance community engagement by answering questions, guiding new users, and maintaining high-quality discussions. Existing contributors are encouraged to apply, while new participants are invited to get involved before applying.
Following up here from our legal team: \> To really discuss this issue we should separate two things people often blend: where your data is *stored*, and which jurisdictions have *authority over the provider*. Choosing an EU region keeps your core project data and backups resident in that region, but you're right that geography alone doesn't resolve the second question of compelled disclosure, and this isn't specific to Supabase. Any U.S. company or any provider with a sufficient US nexus that has possession, custody, or control of data can be subject to US legal process regardless of whether the data is stored in the EU -- including AWS, Microsoft Azure, and Google Cloud. Regulators and courts have grappled with the tension here with GDPR, which is why SCCs, TIAs, and supplemental safeguards exist. The supplemental measure that actually addresses compelled disclosure is encryption where Supabase holds no key (region selection and SCCs don't). \> What actually changes the analysis isn't location, it's whether the provider can decrypt your data. Standard, provider-managed encryption doesn't help here, because the provider holding the keys can be compelled to use them. What does help is encrypting sensitive data with keys we never hold (client-side or application-layer encryption), then Supabase may only be capable of producing encrypted data because we would not have the ability to decrypt it ourselves. That's the viable middle path between "just pick a region" and "self-host everything." Region selection plus our DPA (EU SCCs, defined security safeguards) covers your residency and transfer obligations; customer-controlled encryption is what addresses the access concern. And it's also worth nothing that we would challenge government orders that conflict with applicable law rather than disclosing on demand. Of course users can also do client side encryption on top of that and have control over their own keys. Hope this helps!
nice! these should be enough to get you going I think: [https://github.com/supabase/supabase/blob/master/DEVELOPERS.md](https://github.com/supabase/supabase/blob/master/DEVELOPERS.md) [https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
hey u/Cold_Interaction_598 sorry about the delay here. Missed this comment. Re: backups — the storage team is looking at ideas here. Could you say more about the use case you're trying to solve for here?
Copying from a recent self-hosting thread: \> We have no plans for multi-project at this point. There's a ton of complexity in building and maintaining a multi operator, and then we'd end up handing a lot of that complexity over to you. Separating instances into their own servers is a good thing. [https://www.reddit.com/r/Supabase/comments/1u147jz/comment/oqoos0t/](https://www.reddit.com/r/Supabase/comments/1u147jz/comment/oqoos0t/)
Self-hosting updates here! [https://www.reddit.com/r/Supabase/comments/1u147jz/recent\_updates\_to\_selfhosting/](https://www.reddit.com/r/Supabase/comments/1u147jz/recent_updates_to_selfhosting/)
Nice one! This would be great in the docs — maybe under troubleshooting guides — if interested! [https://supabase.com/docs/guides/troubleshooting](https://supabase.com/docs/guides/troubleshooting)
could be this from us-east-2 [https://status.supabase.com/](https://status.supabase.com/)
Unfortunately there isn't currently a tool for this. Here's the guide for migrating regions: [https://supabase.com/docs/guides/platform/migrating-within-supabase](https://supabase.com/docs/guides/platform/migrating-within-supabase)
Would love to have your help with a better doc for that! Very cool to see it running on a pi!
Appreciate this frustration. See my previous comment about why we do this: [https://www.reddit.com/r/Supabase/comments/1u147jz/comment/oqoos0t/](https://www.reddit.com/r/Supabase/comments/1u147jz/comment/oqoos0t/)
Good question! There's actually so many good reasons. Here's a few: 1. Reduced adoption risk: * Even customers who never self-host care that they can * Makes the managed platform easier to adopt because it reduces perceived lock-in 2. Compliance requirements * Some organizations can't use our hosted offering 3. Open source stewardship * Since supabase itself is built on a bunch of open source projects, its important to us to give back * Investing reinforces the core promise that attracted many users to us in the first place 4. Forcing function for product quality and portability * Running the platform outside of our hosted infra forces better docs, reproducible deployments, etc * Improvements flow back into hosted * The entire platform becomes more standardized no matter where it's deployed 5. More Supabase begets more Supabase * A self-hosted deployment is still a Supabase deployment * Devs learn the APIs, build integrations, create content, train coworkers, etc * Growing the ecosystem is valuable regardless of where it runs These are just a few off the top of my head!
Appreciate the feedback. Would love to hear more about docs confusion if you've got any specific examples I could go from. The 3rd party auth one is interesting — first google result is a landing page, which links to the providers, all of which list the config option near the top. Maybe these were added since you last tried? In any case, love to get any more feedback you have like this.
We have no plans for multi-project at this point. There's a ton of complexity in building and maintaining a multi operator, and then we'd end up handing a lot of that complexity over to you. Separating instances into their own servers is a good thing.
we got u!
It sounds like you're already aware of this, but for others who read this: Functions automatically run in the region closest to the user making the request. But if the function is performing db or storage operations, you can choose to run in the same region as your db. Docs: [https://supabase.com/docs/guides/functions/regional-invocation](https://supabase.com/docs/guides/functions/regional-invocation)
Love to hear more about how it's changed your life! :\^)
What way do you mean? We already have a Python sdk, but I'm sure you've already seen that. [https://supabase.com/docs/reference/python/start](https://supabase.com/docs/reference/python/start)
\^yes, this is basically our position.
Hey there. Sorry you're running into this. This is likely related to this dns issue [https://status.supabase.com/incidents/308hm84ntd47](https://status.supabase.com/incidents/308hm84ntd47) We'll provide updates there as soon as we have them.
Indeed, still working on the community round part. Unfortunately we don't allow transferring shares :\^)
Have you seen the new RLS Testing tool in the Dashboard? [https://github.com/orgs/supabase/discussions/45233](https://github.com/orgs/supabase/discussions/45233)
cool project!
thanks u/SnooChipmunks2539 and good luck building!
Looks like a build issue. Seems sorted now.
What do you mean by “persistent”?
could you say more about this? \> a kick ass browser extension or inline AI SQL that can be ran across your datasets.
Love to get more details on what you find painful
We've put a bunch of work into this over the years — what else would you like to see here?
We've got a roundup of recent self-hosted work coming very soon! will post here this afternoon or monday.
Endorse this threat! Great idea!
Very cool idea! Nicely done.
Deleting this as it contains PII. We are in contact via our support system, let's continue to communicate there.
Could you submit a support ticket? Happy to take a look. Since you're not able to login, you'll likely need to send an email to [support@supabase.io](mailto:support@supabase.io)
Reporting, thank you.
\[supabase team member here\] These are all great options tbh. If you're already using [Supabase](https://supabase.com?utm_source=chatgpt.com), our auth is a pretty natural fit because it's well integrated with the rest of the platform. A few things worth looking at specifically: * flows supported: password, OTP, phone, social, anonymous, SSO, MFA/passkeys, etc * pre-built auth UIs/components: [Supabase UI Auth Components]() * auth hooks/customization: [Auth Hooks](https://supabase.com/docs/guides/auth/auth-hooks?utm_source=chatgpt.com) * SSR/mobile/edge runtime support * how auth connects into database permissions/RLS * pricing once you scale (our pricing is pretty competitive) Happy to answer any questions you have.
You could do restore to a new project to test this out quickly. https://supabase.com/blog/restore-to-a-new-project
You can use Restore to a new project to move your db, but the rest unfortunately needs to be handled manually [https://supabase.com/dashboard/project/\_/database/backups/restore-to-new-project](https://supabase.com/dashboard/project/_/database/backups/restore-to-new-project)
Hosted or self-hosted is basically what we have on offer here =)
Many apologies for this — should be resolved now. Details on the status page: [https://status.supabase.com/incidents/vd5bmmcdt5bf](https://status.supabase.com/incidents/vd5bmmcdt5bf)
\+1 You might also look at our Discord — probably be helpful for you to get more real-time help.
u/ashkanahmadi 's suggestion is valid too. I think that transferring and then "emptying" the project would be the easiest.
You just want to transfer the project to another account: [https://supabase.com/docs/guides/platform/project-transfer](https://supabase.com/docs/guides/platform/project-transfer)
40 minutes! Nice post, thanks for sharing!
Has this resolved? That instance looks healthy now
great!
Hey! You'll should be able to contact support via the dashboard (top right corner). Happy to take a look as well — submit a ticket and pass your ticket id here
It’s a very hard problem! We’d love for everyone to be able to send unlimited emails, but is a very tricky balance to maintain deliverability for everyone.
Hey there Are you sure this is the correct account that you've logged in with? Do you normally login via Bolt? Are they visible there?
As others have said, the built-in email service is really meant for testing/dev, not production sending. For that, you need to setup a custom smtp of your choice. Auth emails are are very hard to run at scale because they attract tons of abuse: spam signups, bots, credential stuffing, phishing attempts, bounce spam, etc. If every free project could send unlimited emails from shared Supabase infrastructure, the sender reputation would get destroyed pretty quickly and legit auth emails would start landing in spam for everyone.
Will address, thanks.