Threads
Loading user profile...
what happened to you is really common with AI builders (I see the exact same thing with Lovable all the time): the AI scaffolds its own users table and login logic instead of wiring everything through supabase auth. so you end up with supabase auth knowing about the login, and the app's own table not having a row for that user - logged in but the db doesn't know you. the fix is to make supabase auth the only source of truth. app data about users goes in a profiles table that references auth.users, with a trigger that creates the profile row on signup. that's the official pattern, laid out here: [https://supabase.com/docs/guides/auth/managing-user-data](https://supabase.com/docs/guides/auth/managing-user-data) and yes, your instinct is right - set up the supabase side first (auth + profiles + trigger), then tell the AI explicitly "use supabase auth for all login and signup, do not create your own users table". being that direct in the prompt is what prevents the second user system from ever appearing.
for the middleware question, the \[supabase next.js guide\](https://supabase.com/docs/guides/auth/server-side/nextjs) was updated recently and now recommends getClaims() for protecting routes instead of getSession or getUser. worth a read, it answers exactly what you're asking 😄
the trust part is what I appreciate most here. it's easy to start over trusting an agent once it's been right a few times in a row, and until now there was nothing to check that instinct against (outside of what I'm doing rn) the other half is knowing which pieces are still worth doing by hand, or at least watching closely. that's normally something you only learn after something breaks. and it makes it much easier to actually study where the gaps are instead of guessing at them. thanks for open sourcing the harness and not just publishing the numbers !
oh I've seen this one. it's nasty because nothing tells you anything. super useful. you should drop it in the showcase channel in the supabase discord too, you'd probably get more feedback there
on the naming debate, i am with you: memory is the right word because it builds the right mental map (if you are not super technical\*)
i have something very similar running on supabase and honestly it is one of the highest-leverage things i have ever built: my agents search it before answering and save as they learn, and the best part is that it remembers things i do not even remember telling it. it saves me real time every single day. on the naming debate, i am with you: memory is the right word because it builds the right mental map. a database stores whatever you insert, a memory decides what is a duplicate, what supersedes what, and what deserves to surface first. that write-path opinion is the whole difference, and your readme clearly gets it. tip from living with mine for months: build the prune loop earlier than feels necessary. memory that only grows starts ranking the 50th reworded copy of a fact above the thing you actually need, a periodic cleanup pass keeps recall sharp. that plus a reranker on retrieval were my two biggest wins. nice work open sourcing this, i will read the schema 🙌 one
the closest thing already exists inside pro: $25/mo comes with a usage bundle (100k MAUs, 8gb db disk, 100gb file storage, 250gb egress), and spend caps are on by default, but you can toggle them off in the dashboard and everything beyond the bundle bills per usage. supabase literally calls it "pay as you grow", mau overage is $0.00325 each, storage $0.125 per gb, that kind of granularity.
se você é a mesma pessoa do Discord, que bom te ver por aqui :) todo projeto Lovable usa Supabase de alguma forma, a escolha é entre o Lovable Cloud (Supabase gerenciado pela Lovable) ou um Supabase seu. pro seu caso: Supabase próprio. por quê: créditos de IA só são gastos quando você fala com o agente. com seu próprio Supabase você troca as imagens direto no dashboard, Storage pros arquivos e Table Editor pras tabelas, zero créditos. como vai: cria seu projeto no supabase.com, conecta na Lovable via Connectors (guia: https://docs.lovable.dev/integrations/supabase) e daí em diante edita os dados sempre pelo dashboard do Supabase. comparação das duas opções: https://carolmonroe.com/blog/lovable-cloud-vs-supabase só um aviso: se seu projeto já tem dados no Lovable Cloud, me fala antes de trocar, porque aí precisa migrar os dados primeiro pra não quebrar o app.
cool!
Since you're on Lovable Cloud, this is actually expected: your database isn't a direct Supabase you control, it's managed by Lovable, so everything that touches the backend goes through their agent. Code written outside only becomes source when it syncs, nothing deploys it until the agent is asked to. I reproduced this yesterday on a fresh Cloud project and it behaved exactly like you describe: sync arrives fine, nothing deploys, one chat message deploys it all. Practical tip so you don't have to leave your terminal: connect the Lovable MCP and send that deploy/update request through it after you push, the agent picks it up and refreshes everything. Or bundle it into messages you're already sending, like u/cubixy2k does with his merge reviews. And if writing code outside Lovable is your main workflow, Cloud is removable now: export and move to your own Supabase, where you deploy directly with no agent in between. I wrote up that process here: [https://carolmonroe.com/blog/export-remove-lovable-cloud](https://carolmonroe.com/blog/export-remove-lovable-cloud)
[https://discord.gg/supabase](https://discord.gg/supabase) :)!
Your edit is the cleanest fix, and it dodges TWO Microsoft failure modes at once: the cross-domain link flagging, and Defender-style scanners that auto-click links to verify them, which invalidates magic links before the user ever opens them (we've seen that one repeatedly with corporate inboxes). OTP is immune to both. To answer the open question though: the way to keep link-based verification is the custom domain add-on (paid), it moves your auth endpoints to auth.yourdomain.com so the link domain matches your sending domain: https://supabase.com/docs/guides/platform/custom-domains. Rule of thumb that's held up for us: custom domain and custom SMTP go together, doing one without the other is where the weird failures live.
this looks super good, and the alert-on-absence idea is genuinely cool. you should share it in the supabase discord showcase, plenty of people there would benefit from this: (adding it to my own toolbox too haha)
What I do for my own projects is a variation of your standalone-page idea, with an agent on top: a scheduled job runs read-only checks, logs latency + error class, and alerts only on consecutive failures (no 3am false positives). The part that made it actually useful: when something fails, an AI agent pulls the project's logs and advisors through Supabase's MCP and sends me a diagnosis, platform vs my instance vs quota, instead of just "down". UptimeRobot tells you something broke, this tells you what to get ahead of.
The official database testing guide covers most of this: pgTAP + the CLI (supabase test new / supabase test db) + a GitHub Actions CI example: [https://supabase.com/docs/guides/local-development/testing/overview](https://supabase.com/docs/guides/local-development/testing/overview) pgTAP tests run in a transaction and roll back, so no junk data between runs, and the RLS helpers cover the silent edge-case bugs you described. For the LLM part: have it generate tests from a real schema dump (supabase db dump --schema-only) instead of migration files, with a deterministic seed.sql it cannot touch. The model writes assertions, not state. Kills the invented-columns problem. Edge functions side, if you need it: [https://supabase.com/docs/guides/functions/unit-test](https://supabase.com/docs/guides/functions/unit-test)
this is cool! i juggle multiple supabase orgs for client work and the logout/login/token dance is my exact daily friction, whoami mapping accounts to emails and orgs is the killer detail. for reach: share it in the supabase discord and get it on made with supabase, the team does look at tools like this. trying it this week! :)
your car analogy is the right instinct, and the tooling for exactly that already exists: connect the Supabase MCP to whatever AI you code with (official guide: [https://supabase.com/docs/guides/getting-started/mcp](https://supabase.com/docs/guides/getting-started/mcp) works with Claude Code, Cursor, VS Code, etc). that gives your coding agent direct access to your database and the Supabase docs, so the backend gets handled the same way as your frontend. the trick that turns it into a learning tool instead of a black box: add a rule or skill to your setup that says "every time we touch something I haven't used before (RLS, triggers, migrations, policies), explain what it is and why in two sentences before applying it". you learn the engine while driving it. and since you're worried about breaking or leaking data, three guardrails: point the MCP at a development project, not production (the docs themselves insist on this), keep schema changes migrations-only like you're already doing, and ask the agent to explain any SQL before you run it. that plus RLS basics is honestly the five-finger rule you're looking for.
supabase doesn't send transactional email itself, you call a provider (resend, postmark, sendgrid) from an edge function. the exception is auth emails, those go through the SMTP you configure. for "order shipped" type stuff it's always an external provider.
oh i feel this, but good news, it's super fixable once you set a couple things up. a few folks here already pointed at the right stuff (plan first, be specific, use the supabase MCP so it reads your real RLS/auth instead of guessing) and that helps a ton. the things i never stop recommending though: \- the supabase agent skills. they give the AI standing rules to follow postgres/supabase best practices (RLS, migrations, proper types, indexes) by default, so you're not babysitting every change. honestly the biggest upgrade you can make: npx skills add supabase/agent-skills (https://supabase.com/docs/guides/getting-started/ai-skills) \- the Security + Performance Advisors right in your supabase dashboard. they auto-flag missing indexes, unindexed foreign keys and RLS gaps, basically the "future implications" the AI skips over. free safety net, takes two minutes. set those two up and it stops "fixing for now" and starts actually respecting your schema. you've got this 🙌
resend. it covers both, transactional for receipts/auth and broadcasts + audiences for the newsletter, so you're not running two vendors. the tip: don't make "reads supabase directly" the requirement, that's the trap. keep supabase as your single source of truth and let a trigger do the syncing for you. put a trigger on auth.users (or your profiles table) that fires a supabase edge function, and have it upsert the contact into a resend audience via their api. new signup -> automatically on your newsletter list, zero manual export, ever. add a marketing\_opt\_in column and only upsert when it's true so you stay compliant, and write unsubscribes back to supabase so your app always holds the truth. that's the real fix, the csv dance is the part to kill, not the two-vs-one-vendor thing. one provider for both halves + event sync = list always current, no exports.
click the three dots on the Supabase plugin in Codex and hit 'Remove from Codex'. then re-add the plugin and it should prompt you to pick the correct workspace this time. https://preview.redd.it/0wialysooq2h1.png?width=1090&format=png&auto=webp&s=cabadebc3f83d38e57f2f5df9f392e7616662947
great that you're making the jump. a few things from experience: yes, free tier works fine for building and early users. main limits to plan around: 1GB storage, 500MB database, 50k monthly active users, and projects pause after 7 days of inactivity on free tier. for dev vs prod, use separate supabase projects (one free for dev, one for prod when ready). for learning path: start with auth (email + google), then database design with RLS, then edge functions. the official docs are honestly the best resource: [https://supabase.com/docs](https://supabase.com/docs) one real tip: learn RLS early, not later. it's the thing that catches most frontend devs off guard when they go to production. the supabase MCP for claude code is also great for learning best practices as you build - it checks your RLS and suggests improvements in real time.
glad you made it through. reading this felt like watching a horror movie unfold in real time.
let me know if it fixed now please
still stucked?
yes you have a window, but heads up - the UI changed recently. the Supabase database selection step moved from the old Connectors page to inside the Cloud modal. so the flow now is: create project, click the Cloud button, scroll to the bottom of the modal, and select your own Supabase database there. connect it before prompting anything database/auth related and Cloud won't activate. once Cloud activates, you can't disconnect it. also, stay alert when you're building in chat - Lovable will sometimes ask which database to use, but sometimes it just picks Cloud automatically without asking. go to Connectors > App connectors > Lovable Cloud > Manage permissions and set it to "Ask each time" so it always asks before enabling Cloud. that way you stay in control.
i've been rotating keys this week too and it really should become a habit for all of us :)
super interesting!
honestly for your use case i'd look at Lovable (lovable.dev). it's built exactly for this - you describe what you want, it builds a real working app connected to Supabase with no coding required. way faster than Retool/Bubble for demos, and the output looks production-grade, not like a prototype i'm a marketer with some design background and it's been a game changer for me. as a designer you'll feel right at home because you can iterate visually and it handles all the Supabase connection (auth, database, storage) for you. you can either use Lovable Cloud (managed backend, zero setup) or connect your own Supabase project directly if you want more control tight deadlines + no code + supabase = lovable is the move
are you still stuck on this?
hey, are you still stuck on this
Glad to read that ! happy building!
i already escalated this internally so hopefully they can help you soon. Stuck pausing states always need the Supabase team to clear, but free tier tickets do get answered. Hang tight!
Haven't run into this myself but found a few things that might help: The real key in \[api\] is external\_url (not host). Try: \[api\] external\_url = "http://192.168.x.x:54321" Then site\_url under \[auth\] pointing to your LAN URL + the callback in additional\_redirect\_urls. Restart with supabase stop && supabase start. Default local email is Inbucket on :54324 btw, if you're on Mailpit, double-check your template uses {{ .SiteURL }} and isn't hardcoding anything. Docs: \- Native mobile deep linking: [https://supabase.com/docs/guides/auth/native-mobile-deep-linking](https://supabase.com/docs/guides/auth/native-mobile-deep-linking) \- Magic link auth: [https://supabase.com/docs/guides/auth/passwordless-login/auth-magic-link](https://supabase.com/docs/guides/auth/passwordless-login/auth-magic-link) Most people end up just using a cloudflared/ngrok tunnel for mobile testing (:
Here are some practices I use with my team :) 1. **Use org roles wisely.** Supabase lets you invite team members with different roles - give the freelancer "Developer" access instead of "Owner". They can work with the database but can't delete the project or manage billing. 2. **Never share your service role key.** That key bypasses RLS entirely. If they need it for edge functions, deploy those yourself or review the code before deploying. 3. **Use branching (Pro plan).** Create a branch for the freelancer to work on - they get their own isolated database copy. You review and merge changes, nothing touches production directly. 4. **Back up before they start.** Run `pg_dump` or use the Supabase dashboard backups. If anything goes wrong, you can restore. 5. **Review their migrations.** Any schema changes should go through you before hitting production. Check for things like `DROP TABLE`, `TRUNCATE`, or `SECURITY DEFINER` functions. 6. **Audit after they're done.** Remove their access when the work is complete. Check that RLS is still enabled on all tables and no new functions were created with elevated permissions. 7. **Use Claude Code to review.** You can run a diff review on the freelancer's branch before merging - it'll catch things like dropped RLS policies, new SECURITY DEFINER functions, or exposed service keys. Cheaper than trusting blindly, faster than reviewing every SQL line yourself. Biggest risk with freelancers isn't usually malice - it's accidental damage. Branching + backups cover that. Some useful docs: - [Access Control (org roles)](https://supabase.com/docs/guides/platform/access-control) - how to set Developer vs Owner roles - [RLS guide](https://supabase.com/docs/guides/database/postgres/row-level-security) - make sure your policies survive the freelancer's changes - [JWT Signing Keys](https://supabase.com/docs/guides/auth/signing-keys) - understand what keys to protect
Since you're on Lovable Cloud without direct Supabase dashboard access, the SQL schema alone won't cover everything. Here's how to get a full backup: Lovable Cloud now has an SQL editor tab in the Cloud panel. You can use it to export data. For the schema (tables, triggers, RLS, functions), ask the Lovable AI chat to generate the full SQL migration file - it has access to everything and can output the CREATE TABLE, policies, and function definitions. For the actual data, use the SQL editor to SELECT and export CSV table by table, or ask Lovable to create an Edge Function that exports all tables as JSON. \- Lovable + Supabase docs: [docs.lovable.dev/integrations/supabase](http://docs.lovable.dev/integrations/supabase)
My workflow completely changed when I started using Supabase. I went from building shallow things toactually thinking about systems - how data interacts with actions, how to manage context, how to build more agentic solutions. And honestly, building with it is how I learned Supabase. Beyond the classic features (database, auth, storage, edge functions), the ones I'm really enjoying right now: \- pgvector - I built a semantic memory system with 500+ entries and embeddings. I search by meaning, not keywords. This one taught me more about Supabase than any tutorial. I wrote about it here: [https://carolmonroe.com/blog/i-gave-my-ai-a-memory](https://carolmonroe.com/blog/i-gave-my-ai-a-memory) \- pg\_cron - one of my favorites. Scheduled jobs that trigger edge functions, process data, send notifications. It's becoming super popular with AI agents right now \- Realtime - subscriptions for live updates across your app The magic is in combining them: pg\_cron triggers an Edge Function, the function writes to the DB, a Realtime subscription picks it up, pgvector makes it searchable by meaning. That's when you stop thinking "database" and start thinking "system" Resources to get started: \- Getting Started: [https://supabase.com/docs/guides/getting-started](https://supabase.com/docs/guides/getting-started) \- Features overview: [https://supabase.com/docs/guides/getting-started/features](https://supabase.com/docs/guides/getting-started/features) \- pgvector & Embeddings: [https://supabase.com/docs/guides/database/extensions/pgvector](https://supabase.com/docs/guides/database/extensions/pgvector) \- Semantic Search: [https://supabase.com/docs/guides/ai/semantic-search](https://supabase.com/docs/guides/ai/semantic-search) \- Automatic Embeddings: [https://supabase.com/docs/guides/ai/automatic-embeddings](https://supabase.com/docs/guides/ai/automatic-embeddings) \- Edge Functions: [https://supabase.com/docs/guides/functions](https://supabase.com/docs/guides/functions) \- Scheduling with pg\_cron: [https://supabase.com/docs/guides/cron](https://supabase.com/docs/guides/cron) \- pg\_cron + Edge Functions combo: [https://supabase.com/docs/guides/functions/schedule-functions](https://supabase.com/docs/guides/functions/schedule-functions) \- AI & Vectors toolkit: [https://supabase.com/docs/guides/ai](https://supabase.com/docs/guides/ai)
when you're building multiple projects it makes a huge difference. I can have an idea, create a new project, and have auth + database + storage running in minutes without configuring three separate services (:
Awesome. Thank you!
This is really cool, thanks for building it.. One question, for people who are security-conscious about passing credentials through the hosted version, the local CLI + Docker option works the same way right? That would be my recommendation for anyone with production data.
a lot of people don't realize this but you're not actually stuck with 2 free projects. You can create additional organizations, and each one gets 2 free projects. So if you need more, just create another org (:!
once lovable cloud is enabled it can't be disconnected - that's why remix keeps it too. the workaround is: 1. connect github to your current project (if you haven't already) 2. create a new blank lovable project 3. import the repo using [https://lovable.dev/products/git-import](https://lovable.dev/products/git-import) 4. connect your own supabase before building anything for migrating your data, check these out: \- lovable's self-hosting guide: [https://docs.lovable.dev/tips-tricks/self-hosting](https://docs.lovable.dev/tips-tricks/self-hosting) \- supabase's lovable troubleshooting page: [https://supabase.com/docs/guides/troubleshooting?search=Lovable](https://supabase.com/docs/guides/troubleshooting?search=Lovable) \- video walkthrough of the full migration: [https://youtu.be/jEBVpl1GBvQ](https://youtu.be/jEBVpl1GBvQ) \- i also wrote a step-by-step guide on exporting from lovable cloud: [https://carolmonroe.com/blog/export-lovable-cloud-claude-code](https://carolmonroe.com/blog/export-lovable-cloud-claude-code) the key is connecting your own supabase *before* you start building in the new project, otherwise cloud activates again.
[https://dreambase.ai/](https://dreambase.ai/)