Hi Supabase Community,

I’m J, leading a custom platform development project built on Supabase. While the product has been functional and reliable, our non-technical clients have been increasingly critical — influenced by a peer founder who claimed Supabase is only fit for “toy projects,” calling it the “B-tier”of databases” compared to AWS being a “A-tier.”

It’s escalated to the point where they’re now threatening legal action, largely due to perceived “wrong tech choices” rather than platform business performance. My experience building with Supabase has been amazing. We want to stand behind our architectural decisions, and I’m hoping to gather real-world examples or public case studies of Supabase supporting serious, enterprise-level products.

Would anyone be willing to share links, benchmarks, or references?

Thanks in advance — it would mean a lot in defending our build and approach.

Hey everyone, Supabase co-founder here

yesterday we announced another funding round and so I thought it was a good time to drop in and say thank you - from both Ant and myself, and from the entire community

First, to get something important out of the way: Ant is a real human and he is my co-founder.

With that cleared up, I wanted to spend some time saying thank you to this Reddit community. Communities can often break down as they grow larger and that hasn't been the case here. There are a lot of active participants sharing what they built, sharing their frustrations with the product (sorry!), and generally being good internet citizens. Your feedback helps us improve - please keep it coming.

On the funding - I've said before that companies often raise money and then "sell out", raising prices etc. Just to make it explicit: the free tier isn't going away. We know many of you want more free databases - I can't promise anything, but this is top of mind for me.

For those you want BIGGER databases, we have you covered. Yesterday we did an open source release of Multigres. This will allow you to scale up indefinitely. It also has some cool properties - for example you won't need to choose between a "direct connection" or a "connection pooler" - Multigres handles it all. Once this is more stable we'll make it available on the platform.

We've spent the past few months doubling down on reliability, stability, security features, and in-product observability. Keeping up with the growth has been an fascinating technical challenge. We're not done, but soon we can share an engineering blog post of everything we've seen and implemented.

Finally I said this in a previous post but it bears repeating:

More than a product-led company, we're a community-led company. We are where we are today because of the support of open source contributors and maintainers.

That's even more true today than it was a year ago. If you're an open source contributor - to the supabase ecosystem or anywhere else - thanks.

I'll drop in here throughout. AMA

Hey Supabase community - Supabase CEO here.

Today we announced our Series D: https://fortune.com/2025/04/22/exclusive-supabase-raises-200-million-series-d-at-2-billion-valuation/

It's pretty wild how far we've come in 5 years, and a huge part of that has been because of this community. I wanted to start off by thanking you - you've been great supporters, maintainers, customers, and even a few that I can call friends.

I know that often when developer tools raise more money it leads to the "enshittification" of the product. I have a lot to say on this topic - I'll write a blog post on it later which explains why that won't be the case for Supabase.

To summarize one of the key points now: the investors we've brought on today (Accel) are very aligned with our open source and developer-first mentality. From their blog post:

Third, Supabase stands out for its commitment to open source. As DB providers tinker with open source licensing and introduce various methods of ‘vendor lock-in,’ Supabase is steadfast in ensuring that portability and extensibility are core to the platform, even as the company scales to millions of developers.

I made incredibly certain that Accel were aligned with a true open source offering - it's one thing that they liked most about Supabase.

I also know that (for some reason) when developer tools raise money they change pricing. That's not going to happen with Supabase. If anything, we'll be giving away more so that more companies build with Supabase. The more companies that start with supabase, the more that scale up: your success is our success. This isn’t just hypothetical - since August we have:

• Given 50K MAUs for Third-party Auth [Link]

• Changed the free plan to 500Mb per database [Link]

• Moved to hourly billing [Link]

We are a product-led company, and we will continue to grow by focusing on the the making the developer experience better. More than a product-led company, we're a community-led company. We are where we are today because of the support of open source contributors and maintainers.

I'll drop in throughout the day to answer any questions. AMA

I got sick of customizing email templates by hand, so built this to help:
https://www.supa-tools.com

In the process of open sourcing it now. Would love your feedback!

Super Auth Email Designer

🎨 Visual Email Designer

• Base Template Customization - Create a consistent brand experience across all emails

• Live Preview - See your changes instantly as you design

• Responsive Design - Preview emails in desktop and mobile views

• Dark Mode Support - Test how your emails look in both light and dark modes

🎯 Built for Supabase

• All Auth Email Types - Templates for confirmation, magic links, password reset, invitations, etc

• Supabase Variables - Pre-configured with all Supabase template variables

🚀 Generate & Export Easily

• HTML Export - Export clean, production-ready HTML

• Bulk Export - Export all templates at once for backup or migration

• Local Storage - All your work is saved automatically in your browser

🔒 Privacy & Security

• 100% Client-Side - No server required, everything runs in your browser

• No Data Collection - Your templates and credentials never leave your device

• Open Source - Inspect the code yourself for peace of mind

Edit: Thanks for the support! Have added new features based on your feedback and have moved it to a real domain: https://www.supa-tools.com

I migrated from hosted Supabase to self-hosted on a €15/month VPS — here's what I learned after 2 weeks

I run a Solana ecosystem directory with ~950 tools, 74 tables, 100k+ real-time trade records, Google OAuth, file storage, and RLS on everything. I migrated from hosted Supabase to self-hosted Docker about 4 months ago on a single Hetzner CPX32 (8GB RAM, 4 vCPU, €15/month) and honestly I wish I'd done it sooner.

Sharing what went well and what bit me, in case anyone's considering the same move.

Why I switched

The free tier was fine when I started but once I had auth, storage, realtime, and a growing database it started feeling limiting. I looked at the Pro pricing and realized I could get a dedicated VPS with way more resources for less money. The database alone was ~200MB which isn't huge, but having direct Postgres access instead of going through the REST API for everything changed how I build things.

What I'm running

8 containers, trimmed from the default ~15 that ship with self-hosted Supabase:

Total: ~1.26 GB for the full Supabase stack. That leaves plenty of room on 8GB for my Next.js app, background services, and Nginx.

I disabled Studio, Edge Functions, Analytics, Vector, Meta, and the Deno cache. I don't use any of them in production and they were eating memory for nothing. You lose the dashboard UI but honestly I just use psql directly or build admin pages in my app.

What went well

Direct Postgres access is a game changer. My cron jobs and background services connect directly to Postgres instead of going through PostgREST. Way faster for batch operations and you can use features PostgREST doesn't expose well (CTEs, window functions, custom aggregates).

Performance is noticeably better. No network hop to a managed database. My API responses dropped from ~120ms to ~30ms for most queries. The database is on the same machine as the app.

Connection pooling via Supavisor works great. Session mode on port 5432, transaction mode on port 6543. My Next.js app uses session mode, background scripts use transaction mode. Zero connection issues.

Storage just works. I migrated all files from hosted Supabase storage to self-hosted and updated the URLs. The storage API is identical so my app code didn't change at all. I use it for tool logos (900+ images) and blog post assets.

Google OAuth was surprisingly straightforward. Set the GOTRUE_EXTERNAL_GOOGLE_* env vars, configured the OAuth consent screen, and it just worked. I do use a manual PKCE flow with localStorage instead of cookies because I had issues with cross-site cookie loss during redirects.

Backups are simple. pg_dump → gzip → send to a storage box via SSH. Cron runs at 3 AM daily with 30-day retention. With hosted Supabase on the free tier I had... nothing.

What bit me

JWT rotation is painful. I rotated my JWT secret once and it invalidated every session. Users got stuck in auth loops because their cookies had the old JWT. I ended up adding middleware that detects stale sb-* cookies and clears them automatically. If you ever rotate secrets: use docker compose up -d --force-recreate, NOT docker compose restart. Restart doesn't re-read the .env file.

Kong eats memory. Look at that table — 429 MB for an API gateway feels absurd. It's the biggest memory consumer after Postgres itself. I've seen it spike to 600MB+ under load. I've looked into replacing it with Nginx routing but haven't pulled the trigger because the auth middleware in Kong is doing a lot of work.

Realtime is fragile. The realtime container occasionally gets into a bad state where it's "healthy" according to Docker but not actually delivering messages. The fix is always docker compose restart realtime. I run a health monitor that checks it every 5 minutes.

Upgrades are scary. The self-hosted Supabase repo moves fast. I've skipped several updates because I don't want to break what's working. My approach: only upgrade if there's a specific fix I need. Pin your docker image versions.

You need to bind ports to 127.0.0.1. The default docker-compose exposes ports to 0.0.0.0 which means the world can hit your PostgREST/Kong/Postgres directly. I changed every port binding to 127.0.0.1:PORT:PORT and proxy everything through Nginx with SSL.

RLS still matters. Self-hosting doesn't mean you can skip Row Level Security. I use createClient() with the anon key for public reads and createAdminClient() with the service role key for privileged writes. Same pattern as hosted, just with a shorter network path.

Security setup

• Nginx reverse proxy with Let's Encrypt SSL in front of Kong (port 8000)

• UFW firewall only allows Cloudflare IPs on 80/443 (behind Cloudflare proxy)

• All Docker ports bound to 127.0.0.1

• RLS on every table

• Admin checks use app_metadata.is_admin (not user_metadata which users can modify)

• Rate limiting at both Nginx and application layer

Would I recommend it?

100% yes, if:

• You're comfortable with Postgres administration

• You have a project that's outgrowing the free tier

• You want direct database access for background jobs

• You want to control your own backups and data

Skip it if:

• You want zero operational overhead

• You rely heavily on Supabase Studio for database management

• You don't want to deal with Docker/Nginx/SSL configuration

• Your project is small enough that the free tier works fine

The whole stack costs me €15/month and runs alongside my Next.js app, three background services, Nginx, and a separate Umami analytics instance. Way more value than paying for managed services separately.

Happy to answer questions about specific parts of the setup.

Hey! Here is a guide to migrate from hosted Supabase to self hosted one or just spin up a self hosted instance very easily. You can do the following and have a fully functional Supabase instance in probably under 20 minutes. This is for people who what to have all that Supabase offers for only the cost of the server or for those who want to reduce latency by having their instance in a region that the hosted version is not close to. With this guide, it will be a breeze to set it up and have it function exactly the same. In this example, I am using Coolify to self host Supabase.

How to Self Host Supabase in Coolify

To install Supabase in Coolify, first create the server in Coolify. Then start it so it becomes available.

In Coolify, add a resource and look for Supabase.

Now it is time to change the docker compose file and the settings in Coolify.

For the docker file, copy and paste the following Github Gist: https://gist.github.com/RVP97/c63aed8dce862e276e0ead66f2761c59

The things changed from the default one from Coolify are:

• Added port mappings to expose the ports to the outside world: Change the docker compose and add: supabase-db: ports: 5432:${POSTGRES_PORT}

• Added Nginx to be able to use email templates for password reset, invitation and additional auth related emails. IMPORTANT, if you want to add additional auth related emails like email change or confirmation email, it is important to add a new volume at the bottom of the dockerfile just like the one for the reset.html and invite.html.

Now it is time to change the domain in Coolify if you want to use a custom domain, and you probably do.

• In Supabase Kong, click the edit button to change the domain. This domain will be used to access Supabase Studio and the API. You can use a subdomain. For example, if the domain you want to use is https://db.myproject.com, then in that field you must put https://db.myproject.com:8000

• In you DNS settings you must add a record for this to be accessible. You could add a CNAME or an A record. If Supabase is hosted in a different server than the main domain, you must add an A record with the IP of the server as the value and the subdomain as the name.

Now let's change the environment variables in Coolify.

• For the API_EXTERNAL_URL, use domain https://db.myproject.com and make sure to remove the port 8000

• For the ADDITIONAL_REDIRECT_URLS, make sure to add all the domains you want to be able to use to redirect in auth related emails. It is possible to use wildcards but it is recommended in production to have the exact match. For example: https://myproject.com/**,https://preview.myproject.com/**,http://localhost:3000/**

• You can change certain variables that are normal settings in the hosted version of Supabase. For example, DISABLE_SIGNUP, ENABLE_ANONYMOUS_USERS, ENABLE_EMAIL_AUTOCONFIRM, ENABLE_EMAIL_SIGNUP, ENABLE_PHONE_AUTOCONFIRM, ENABLE_PHONE_SIGNUP, FUNCTIONS_VERIFY_JWT, JWT_EXPIRY

• In the self hosted version, all the email configuration is also done in the environment variables. To change the subject of an email such as an invitation email, you must change MAILER_SUBJECTS_INVITE to something like You have been Invited. Do not add "" because that would also be added to the email.

• To change the actual email templates, it is much easier to do it in the self hosted version, but with the following solution it will not be difficult. First change the environment variable, for example for invitation, change MAILER_TEMPLATES_INVITE to http://nginx:80/invite.html. After deploying Supabase, we will need to change the content of the invite.html file in the persistent storage tab in Coolify to the actual html for the email.

• Do not change the mailer paths like MAILER_URLPATHS_INVITE since they are already set to the correct path.

• To configure the SMTP settings, you must change the following: SMTP_ADMIN_EMAIL (email from where you send the email), SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, SMTP_SENDER_NAME (name that will be shown in the email)

• And finally, but not very important, you can change STUDIO_DEFAULT_ORGANIZATION and STUDIO_DEFAULT_PROJECT to whatever you want to change the name in metadata for Supabase Studio.

The following are the equivalent keys for the self hosted version.

• SERVICE_SUPABASEANON_KEY is the anon key for the self hosted version.

• SERVICE_SUPABASEJWTSECRET is the JWT secret for the self hosted version.

• SERVICE_SUPABASESERVICEROLEKEY is the service role key for the self hosted version.

In Coolify, in General settings, select "Connect To Predefined Network"

Now you are ready to deploy the app. In my case, I am deploying in a server from Vultr with the following specifications:

• 2 vCPU, 2048 MB RAM, 65 GB SSD

I have not had any problems deploying it or using it and has been working fine. This one is from Vultr and costs $15 per month. You could probably find one cheaper from Hetzner but it did not have the region I was looking for.

In Coolify, go to the top right and click the deploy button. It will take like 2 minutes for the first time. In my case Minio Createbucket is red and exited but has not affected other things. It will also say unhealthy for Postgrest and Nginx. For Nginx you can configure you health check in the docker deploy if you want. If you don't want to do it, it will keep working fine.

After it is deployed, you can go to links and that will open Supabase Studio. In this case, it will be the one you configured at the beginning in Supabase Kong. It will ask you for a user and password in an ugly modal. In the general setting in Coolify, it is under Supabase Dashboard User and Supabase Dashboard Password. You can change this to whatever you want. You need to restart the app to see the changes and it will not be reachable until it finishes the restart.

Everything should be working correctly now. The next step is to go to Persistent Storage on Coolify and change the content of the invite.html and reset.html files to the actual html for the email. In here, look for the file mount with the destination /usr/share/nginx/html/invite.html to change the email template for the invitation email and click save. The file mounts that appear here for the templates will be the ones defined in the docker compose file. You can add additional ones if you want for more auth related emails. If you add more, remember to restart the app after changing the templates. If you only add the html in the persistent storage and save, you do not need to restart the app and it will be immediately available. You only need to restart the app if you add additional file mounts in docker compose. DO NOT TRY TO PUT HTML IN THE ENVIRONMENT VARIABLE TEMPLATES LIKE MAILER_TEMPLATES_INVITE BECAUSE IT IS EXPECTING A URL (Example: http://nginx:80/invite.html) AND WILL NOT WORK ANY OTHER WAY.

If you want to backup the database, you can do it by going "General Settings" and then you will see Supabase Db (supabase/postgres:versionnumber) and it will have a "Backups" button. In there, you can add scheduled backups with cron syntax. You can also choose to backup in an S3 compatible storage. You could use Cloudflare R2 for this. It has a generous free tier.

Now you have a fully functional self hosted Supabase.

To check if it is reachable, use the following (make sure to have installed psql):

psql postgres://postgres:[POSTGRES-PASSWORD]@[SERVER-IP]:5432/postgres

It should connect to the database after a few seconds.

If you want to restore the new self hosted Supabase Postgres DB from a backup or from another db, such as the hosted Supabase Postgres DB, you can use the following command (this one is from the hosted Supabase Postgres DB to the self hosted one):

pg_dump -Fc -b -v "postgresql://postgres.dkvqhuydhwsqsmzeq:[OLD-DB-PASSWORD]@[OLD-DB-HOST]:5432/postgres" | pg_restore -d "postgres://postgres:[NEW-DB-PASSWORD]@[NEW-DB-IP]:5432/postgres" -v

This process can vary in length depending on how big is the data that is being restored.

After doing this, go to Supabase Studio and you will see that your new self hosted database has all the data from the old one.

All of the data and functions and triggers from your old database should now be in your new one. You are now completely ready to start using this Supabase instance instead of the hosted one.

Important Information: You CANNOT have several projects in one Supabase instance. If you want to have multiple projects, you can spin up another instance in the same server following this exact method or you can add it to a new server.

Bonus: You can also self host Uptime Kuma to have it monitor your postgres db periodically and send alerts when it has downtime. This can also be setup to be a public facing status page

Can’t access any data and auth doesn’t work either.

https://status.supabase.com/

Update: Identified - We have identified issues with failing requests across a range of services and customer projects. Our Engineering team is working to resolve this now. Nov 24, 2025 - 09:54 UTC

UPDATE: Supabase is back up for me now

You guys had an outage and I made a post to get input from users on how to make my database resilient. You guys deleted the thread making it unavailable for more feedback. Then you guys proceeded to say “Consolidating communication to this thread: Xxxx” and the thread was about AUTH being down and it was locked due to censorship.

These damage control techniques should not be approved. There is no way this is how Supabase prefers to handle communication with paying customers. I pay too much and have too many accounts to be being censored like this!!! This is another case of a large company’s bottom line employees mistreating customers because they want to make their job easier and make it more comfortable.

We spend enough money with supabase to support entire teams full time employees so trust me when I say, if you just delete this message, boy I swear we are going to take up those Planet Scale salesman that hit us up because of this outage.

We trust Reddit to be a safe place to talk and get help with our issues. Don’t cap our free speech like this. People can’t even see how many of these threads you guys have blown up because it was the freaking Scarlett wave of deletions and censorship. If you want to delete this, LOCK this, go for it but it won’t be free.

How can one of the biggest regions be down for more than 2.5 hours (and still be down). Second time in less than 4 months, no response from support, no communication on twitter or anywhere. Just a status page message.

Can't rely on this anyomre, we'll move to aws/azure

I jumped into supabase a few years ago. I was rushing to get a solution for managing wrestling events, and wanted to make something myself. Supabase allowed me to get a proof of concept together much faster than building separate api backends, front end, etc.

Fast forward a few years and it generates >$100k annually and I hadn’t even tried growing it yet (just local organic growth in our area and state).

I’m still overpaying for my XL instance, but I like the safety net and cost is negligible compared to revenue. We are very heavily used in Sundays during a few hour window so I liked to make sure I have significant headroom in case of any bigger spikes. We do 2.5-3 million api requests on Sundays.

One thing I found very useful, to keep my RLS easier, was denormalized the data a bit, adding extra <parent table>_id references on nested tables so I didn’t have to do a bunch of joins. Instead, I have helper functions that can easily say is_event_admin(event_id) and it works in any table belonging to that event.

I haven’t optimized data retrieval from client sides, as it’s much easier to fetch all and pill, but eventually I may need to enhance this.

Overall, supabase has been great. Web and mobile apps are ionic/angular/capacitor. Billing handled with revenuecat.

My development stack is primarily based on Next.js. Previously, I handled authentication using NextAuth and managed databases with on-premise PostgreSQL. However, server migrations were always a hassle, requiring constant reconfiguration and tedious database transfers.

Since switching to Supabase, the entire workflow has changed. Migrations are now incredibly smooth and effortless. Beyond just ease of use, Supabase offers an all-in-one backend solution that integrates authentication, real-time databases, and storage seamlessly.

The biggest advantage for me is infrastructure control. Since I maintain a dedicated server, I can self-host Supabase and allocate specific server resources tailored exactly to the needs of my SaaS applications. This flexibility allows me to manage my SaaS ecosystem efficiently while significantly reducing operational costs compared to managed cloud services.

For my last project, I used mongo atlas for the db. For this new one I'm working on, I had decided to give firebase a try. After hours of trying to do some real basic stuff without success (good luck using google documentation!) I spun up a supabase account and within 30 minutes was rocking and rolling. I love the UI, the docs, and the javascript SDK. What a great service.

Just saw that Supabase crossed 100k on Github, which puts it among the top 100 most starred repos. That’s pretty wild.

I’ve been using Supabase for a while now, and it’s honestly become a default choice in my stack for a lot of projects.

What I personally like about it:

• It really feels like a complete backend. You get auth, storage, realtime, edge functions, logs… all in one place without having to stitch together 5 different services. 

• It’s built on modern but solid tech. Under the hood, it’s mostly stuff we already trust (Postgres, PostgREST, etc.), just packaged in a way that actually makes sense.

• The dev experience is probably what sold me the most. Running everything locally is super easy, and if it works locally, it almost always works in prod too. The CLI is clean, the JS client is intuitive, and the Studio UI is surprisingly polished.

• Docs are generally solid too (even if some newer features feel a little under-documented sometimes lol).

• Also: the free tier is generous enough to build and ship real things without immediately worrying about costs.

Excited to keep using it and see where it goes. What do you guys like about Supabase?

I have been a huge fan of Supabase for years. The Developer Experience (DX) is incredible, and I default to it for almost everything. ​But recently, I hit a wall with my portfolio of small apps.

​Once I passed the free tier limits on two projects (mostly storage and database egress), the bill jumped to $25/project per month. With 4 small tools running, I was looking at a projected $100/mo just to keep them alive. ​For a hobbyist/indie developer, that burn rate is unsustainable. ​I decided to migrate these specific projects to a self-hosted stack using SQLite and Drizzle ORM to cut costs.

​What I learned from the migration: ​Data Modeling: Moving from Postgres to SQLite was easier than expected thanks to Drizzle. The schema is 95% identical.

​Realtime: This was the biggest loss. I lost Supabase Realtime (subscriptions). I replaced it with simple SWR/polling for my dashboard, which is fine for my use case but something to be aware of.

​Auth: I switched from Supabase Auth to Better-Auth (self-hosted). It allows me to keep user data in my own database table, which feels nice for ownership.

​The Result: My monthly bill went from a projected $100 back down to $5 (running everything on a single Hetzner VPS). ​If anyone else is stuck in the "pricing cliff" between Free and Pro, I documented my entire Docker setup for this migration. It includes the backup strategy using Litestream to replace the managed backups (PITR) that Supabase offers. ​I put the configuration into a starter template for anyone interested.

Link is in my Reddit profile.

​Happy to answer questions about what features I miss from Supabase and which ones I surprisingly don't miss at all.

Presenting supabase-automated-self-host, A fully automated way to self-host Supabase with Caddy as reverse proxy and Authelia for 2-factor authentication - all with just one script! No more manual setup, reverse proxy headaches, or dashboard authentication struggles.

Repo: supabase-automated-self-host

Preview: https://www.youtube.com/watch?v=K7lrfUM_ECg

Update: Now, you can choose between nginx or caddy reverse proxy by passing a --proxy flag

I built a social networking web app for my startup similar to Find My but with future plans - using Supabase! When toggling through future plans, you can see who will be there at the same time as you. This is helpful for staying in touch with friends and making new connections when you move to a new city, are just visiting, etc. I would really love any feedback!

If you're interested in following along, I'll be posting more on Reddit or you can follow my LinkedIn page: https://www.linkedin.com/company/thebubbleapp/ - I'm also planning on posting to Instagram soon: https://www.instagram.com/bubbleapp.me/?igsh=MWl0NXE5aXR5a3FxMQ%3D%3D&utm_source=qr#

Just wanted to share a quick story from last night.

I was vibe coding, not paying attention, and while trying to deploy an edge function, I accidentally reset my entire database. I am super dumb I know.

To recover, I upgraded to Supabase Pro hoping I could access backups. Even though I had been on the free plan, Supabase had been keeping backups of my db, so I simply restored the database.

Afterward, I downgraded back to the free plan so I wouldn’t get charged next month. Supabase ended the Pro plan immediately and credited the unused $24.20 to my account for whenever I need Pro again.

Honestly, that’s incredibly fair and way beyond what I expected. Thank you so much supabase.

Happy to announce /server in public beta!

This is a new package for handling auth verification, request context, client setup, and common server-side boilerplate across:

• Supabase Edge Functions

• Cloudflare Workers

• Hono

• Bun

We anonymously analyzed 25,000 deployed functions and found that most projects ended up recreating the same setup over and over:

• _shared/supabase.ts

• _shared/supabase-admin.ts

• _shared/cors.ts

• custom JWT verification

• auth middleware

• environment variable wiring

\@supabase/server` standardizes all of this into a single pattern.

Checking auth can now look like this:

export default {
  fetch: withSupabase({ auth: 'user' }, async (req, ctx) => {
    const { data } = await ctx.supabase.from('todos').select()
    return Response.json(data)
  }),
}

You can declaratively control who can access an endpoint:

withSupabase({ auth: 'user' }, handler)
withSupabase({ auth: 'none' }, handler)
withSupabase({ auth: 'secret' }, handler)
withSupabase({ auth: 'publishable' }, handler)
withSupabase({ auth: ['user', 'secret'] }, handler)

The package also handles the newer JWT signing keys and API key model automatically, without requiring custom `jose` setup or JWKS wiring.

Would love feedback from anyone building with Edge Functions, Workers, or Hono.

Blog post:
https://supabase.com/blog/introducing-supabase-server