nexorsist

Guessing an AI did this for him otherwise the modal probably would have alerted him to what he is doing

Wait for support? Stop trolling

Listen to what gary said to you. Your original message says that projectID: dpohajnecyqmogjkschu - exceed the quota. You now say your ProjectID is: rrpiwtkmuldvgnplrpng This means that you deleted the old project that exceeded quota and opened a new one in hopes that you can just continue, which did not work out for you. You will keep getting the error, especially because it seems your v0 project is still pointed to the old project. If you cannot figure out how to update your v0 project to point to new Supabase project then that is your problem also. He is right that you are violating your account terms on a free policy, so you just need to wait patiently for Support to respond to tell you the exact same thing. If you want to go crazy over limits then pay for a Supabase subscription or learn to self-host your Supabase while you are still developing so that you can mash it as much as you like

If your one has a problem or gets compromised you are going to have massive problems

Feel like having their password change on all the tenants is the better behaviour. But I also think it isn't great to mix tenants data together in one giant database. It would probably be better to fire up a new Supabase instance per tenant and price that into your service

If you are still regularly updating them because you are still developing this can get annoying really quickly. But if you're determined to stay on this setup, then there are some solutions to automate this with your repo updates

You need to physically copy the edge functions to the mounted volume on the host drive (where Coolify is hostes). /data/coolify/services/<serviceIDcontainer>/functions Then you need to restart the edgeFunction container in Coolify and it will serve them.

Esm.sh gives a lot of problems in my experience.

Okay so I will just leave this here incase someone else needs to know and mark it complete: - It is not that it doesn't work with --db-url, it does infact work. - You need a local docker running because it creates certain images on the local docker and performs the squash / diff actions on the local docker prior to squashing between you and the remote db (and for diff it is launching a specific docker container for the purpose of doing the diff) So this does infact work, but I think the documentation and error messages require an updat to explain this interaction

May as well add here that the same happens for db diff and using --db-url. Also in documentation it supposedly supports this

Ah super! Thanks for the tip, I did not think about that! I will likely eventually move it out of the pre-build process into a separate service that migrates when there are new migrations (already does this for functions) so that it doesn't mess with the build process.