La teva app de Lovable ja és construïda. La producció es decideix sota la línia de flotació: a Supabase

Una app de Lovable que corre sobre Supabase és més a prop de producció del que admetran la majoria d'enginyers que la revisin, i més lluny del que es pensa el fundador que l'ha construïda. Tots dos errors costen diners. El primer acaba en una reescriptura que ningú no necessitava. El segon posa en producció una base de dades que respon a qualsevol que pregunti.

Escric des de la banda de qui hereta aquests repositoris. Abans de Conectia vaig passar anys fent DevOps i resposta a incidents en entorns enterprise, i avui els nostres enginyers es fan càrrec de productes construïts amb IA i els preparen per a usuaris reals. Amb Lovable el patró es repeteix prou per posar-lo per escrit: les pantalles estan bé, l'esquema sol ser raonable i gairebé tot el que comporta risc viu en una capa que el fundador no ha mirat mai.

En una app de Supabase, la política de row-level security és el backend. Quan s'entén per què, la resta de l'auditoria s'ordena sola.

El navegador parla directament amb Postgres, i aquest és tot el disseny

Una app típica de Lovable és un front en React que crida Supabase directament amb una clau pública. Al mig no hi ha cap servidor d'API escrit per tu. Supabase exposa les taules per HTTP, i l'única cosa que decideix quines files pot llegir o escriure cada petició són les polítiques de Postgres de cada taula.

Aquest disseny no és un defecte: és el que permet a un fundador tenir un producte funcionant en un cap de setmana, i aguanta a escala si les polítiques són correctes. La documentació de Supabase posa la condició sense embuts: una taula sense RLS ni polítiques assenyades deixa que qualsevol client en llegeixi i en modifiqui les dades. La de Lovable ho diu des de l'altra banda: «Missing RLS policies are the most common way app data gets exposed», és a dir, la manca de polítiques RLS és la via més habitual per on es filtren dades.

I ja ha passat a escala. El maig del 2025 un investigador va analitzar 1.645 apps de l'aparador públic de Lovable i en va trobar 170 amb taules que es podien llegir o escriure només amb la clau pública. Va quedar registrat com a CVE-2025-48757. Des d'aleshores Lovable fa escanejos de seguretat automàtics en publicar, i la seva pròpia pàgina de seguretat diu el que diria qualsevol proveïdor honest: aquestes eines no substitueixen una revisió de seguretat a fons.

Ja vaig escriure sobre què falla en general als MVP fets amb IA. Lovable sobre Supabase falla de maneres prou concretes per merèixer una llista pròpia.

Abans d'arreglar res, esbrina què és teu

La primera pregunta de l'auditoria no és tècnica: on viu això i qui té les claus?

• Lovable Cloud o un projecte propi de Supabase? D'ençà que Lovable va fer de Cloud el backend per defecte, molts fundadors no han obert mai un tauler de Supabase. La documentació de Lovable recomana connectar-hi un projecte propi si vols la propietat directa, la teva pròpia facturació o accés complet al tauler de Supabase. A Cloud, la regió queda fixada quan l'actives i no hi ha migració d'un clic cap a un projecte de Supabase propi. Val més decidir-ho aviat, abans que les dades creixin.
• El repositori. Connecta GitHub i porta el repo a una organització de l'empresa, no al compte personal del fundador. Lovable sincronitza en els dos sentits, però només una branca alhora. Quan hi hagi enginyers fent commits al mateix repo, decideix qui mana a main. Si la protecció de branca rebutja un push de Lovable, el canvi va a parar a una branca lovable-sync que algú haurà de fusionar: és el comportament correcte, i la primera vegada sorprèn.
• El que Git no s'emporta. El repo conté el codi i els fitxers de migració; les dades i els fitxers pujats s'exporten a part. La teva estratègia de còpies de seguretat no pot ser «és a GitHub».
• Qui hi pot entrar. MFA a GitHub i a l'organització de Supabase, més d'un propietari i una llista de tothom qui té accés al tauler. La checklist de producció de Supabase demana exactament això, i són vint minuts.

On es trenquen les polítiques, en l'ordre en què me les trobo

Els problemes es repeteixen d'una base de dades de Lovable a la següent. Cap no és exòtic, i cadascun, un cop localitzat, és una o dues hores de feina sènior.

1. Taules amb l'RLS desactivat. Sol ser una taula afegida al final o creada a mà a l'editor SQL. El Security Advisor de Supabase les assenyala; és el primer que cal executar.
2. RLS activat i obert de bat a bat. Una política que diu «qualsevol usuari autenticat ho pot llegir tot» passa el control d'«RLS activat» de l'escàner i, tot i així, lliura cada fila a cada client que es registri.
3. Aïllament multi-tenant per convenció. L'app filtra per organization_id al front, mentre que la política només comprova que l'usuari ha iniciat sessió. El correcte és una taula de pertinença i una política que dedueixi el tenant a partir d'auth.uid(), mai d'un valor que envia el client.
4. Polítiques que es refien de user_metadata. Cada usuari pot editar les seves metadades, i Supabase adverteix expressament que no s'hi autoritzi res. Els rols van a app_metadata o a taules pròpies.
5. Vistes i funcions que se salten l'RLS. Les vistes creades per l'usuari postgres ignoren les polítiques si no porten security_invoker = true. Una funció security definer exposada per RPC s'executa amb els permisos del seu propietari. Totes dues són eines legítimes, i totes dues són forats quan ningú no les ha triades amb coneixement de causa.
6. Buckets d'emmagatzematge públics. Factures i documents d'identitat en un bucket públic són a una URL de qualsevol. L'emmagatzematge té les seves pròpies polítiques sobre storage.objects, i cal auditar-les com si fossin taules.
7. Polítiques correctes però lentes. Una columna sense índex dins d'una política converteix cada lectura en un escaneig seqüencial, i cridar auth.uid() sense embolcallar-la en un select l'avalua fila a fila. Amb cinquanta usuaris no es nota; amb cinquanta mil, és un tiquet de suport.

Claus, edge functions i els límits que ningú no esmenta el dia del llançament

La clau secreta se salta l'RLS. Supabase distingeix ara una clau publicable, que pot anar al navegador, d'una clau secreta que se salta el row-level security i no ha de sortir mai del teu control. Busca service_role i sb_secret_ al bundle compilat. I apunta't la data: Supabase retira les claus heretades anon i service_role a finals del 2026, de manera que una app que encara les faci servir té una migració pendent, passi el que passi amb la resta d'aquest article.

Cada edge function és una frontera d'autorització. Lovable escriu edge functions per a tot el que necessita un secret: pagaments, correus, crides a un LLM. Desa les claus com a secrets de Supabase, fora del repositori, i aquesta part està ben resolta. El forat és a dins de la funció: sovint s'executa amb permisos elevats i es refia del payload. Cadascuna hauria de verificar el JWT de qui la crida i comprovar que aquell usuari pot fer aquella acció abans de tocar la clau secreta.

Les edge functions tenen límits estrictes: 2 segons de CPU per petició, 256 MB de memòria i 150 o 400 segons de temps total, segons el pla. Una exportació a PDF, una cadena llarga de crides a un LLM o una importació nocturna no hi pertanyen: van a un worker amb una cua.

Els rate limits protegeixen Supabase Auth, no les teves funcions. Els endpoints d'autenticació porten límits per IP raonables. Una edge function que crida l'API d'un model de pagament no en té cap fins que l'escrius, i això la converteix en un punt de facturació obert a qualsevol amb sessió. I després hi ha el que trenca el dia del llançament: sense SMTP propi, l'enviament de correu integrat de Supabase està limitat a dos correus per hora. Existeix per fer proves. Configura el teu SMTP abans de la primera campanya, o les confirmacions de registre deixaran d'arribar just quan més falta fan.

Migracions, entorns i còpies de seguretat: la lampisteria que una demo no necessita mai

Lovable escriu els canvis d'esquema com a migracions revisades a supabase/migrations/, que és més del que tenen la majoria de MVP fets a mà que he auditat. La deriva ve de tot el que es fa fora de Lovable: una columna afegida des del tauler, una política retocada a mà a mitjanit. La solució és una línia base: comparar l'esquema viu amb la carpeta de migracions amb la CLI de Supabase, fer commit de la diferència i, a partir d'aquí, canviar l'esquema només amb migracions.

Després, els entorns. En aquestes apps el normal és un sol projecte per a desenvolupament i producció, i així és com un script de prova acaba esborrant files reals. El branching de Supabase et dona una base de dades de preview per pull request i branques persistents per a staging, i la seva integració amb GitHub aplica les migracions a producció en fusionar. Afegeix-hi una CI que comprovi tipus, passi els tests i executi tests de polítiques contra una base de dades de branca, perquè una política sense test és una política que algú afluixarà sense adonar-se'n.

Les còpies de seguretat decideixen com de dolent serà el teu pitjor dia. Al pla gratuït no hi ha còpies descarregables i el projecte es pot pausar després d'una setmana d'inactivitat. Els plans de pagament guarden còpies diàries (set dies a Pro), i la recuperació a un punt en el temps redueix el pitjor cas a uns dos minuts de dades perdudes. Fes una restauració de prova en una branca abans de necessitar-la. Una còpia que no s'ha restaurat mai és una esperança.

Per acabar, observabilitat i cost: seguiment d'errors al front, un ID de petició al log de cada edge function, pg_stat_statements per a les consultes lentes i un sostre diari per a tot el que crida un model. A escala, la factura gairebé mai no la dispara la base de dades: la disparen un còmput que s'ha quedat curt, el trànsit de sortida de l'emmagatzematge i unes funcions sense rate limit.

Quan quedar-se a Supabase i quan moure el backend

Algú, sovint la teva primera contractació sènior, proposarà reescriure el backend «com cal». He vist aquest consell cremar un trimestre de runway més d'una vegada. La resposta honesta: Supabase és Postgres, i Postgres no és la peça que falla. Queda't a Supabase quan el producte sigui sobretot dades amb permisos, les polítiques es puguin escriure i provar, i l'autenticació encaixi amb els teus usuaris. Això descriu la majoria d'apps de Lovable que he vist.

Mou la lògica de negoci a un servei —en Python o en Node, els stacks amb què treballem— quan el domini ja no càpiga en polítiques: transaccions de diversos passos entre moltes taules, processos llargs que superen els límits de les edge functions, integracions pesades amb tercers o un requisit de compliment que exigeix una única API auditable davant de les dades. Fins i tot llavors, poques vegades es deixa Supabase. La base de dades, l'autenticació i l'emmagatzematge s'hi queden; el navegador deixa d'escriure directament a les taules sensibles i passa a cridar el teu servei, ruta a ruta. És el mateix enfocament incremental que defenso a monòlit o microserveis per a un MVP: moure la frontera allà on hi ha el risc, no tot alhora.

Què auditaria primer, i en aquest ordre

Si la teva app de Lovable m'arribés a la taula dilluns, aquest seria l'ordre. Importa més l'ordre que la llista, perquè cada pas fa segur el següent.

1. Propietat, el primer dia. Repo en una organització de GitHub de l'empresa, projecte de Supabase (o Lovable Cloud) inventariat, MFA a tot arreu i la llista d'accessos per escrit.
2. Exposició, dies u i dos. Security Advisor i, després, l'RLS i les polítiques de cada taula, els buckets, les vistes, les funcions security definer i una cerca de claus secretes al bundle. Fes rotar tot el que hagi estat exposat alguna vegada.
3. Edge functions. Verificació del JWT i autorització a cadascuna, rate limits a tot el que gasta diners i els processos llargs, fora.
4. Configuració de l'autenticació. SMTP propi, confirmació per correu activada, OTP amb caducitat curta, URL de redirecció limitades als teus dominis i CAPTCHA al registre.
5. Còpies de seguretat. Pla de pagament, PITR si les dades importen i una restauració provada.
6. Migracions i entorns. Línia base de l'esquema, staging amb branching i CI amb tests de polítiques a les rutes que toquen diners o dades personals.
7. Observabilitat i sostres de cost. Seguiment d'errors, ID de petició, revisió de consultes lentes i un sostre diari de despesa en models.
8. I aleshores, la decisió sobre el backend, amb el que hagin ensenyat els set passos anteriors i no per gust.

Un enginyer sènior que ja ho ha fet abans cobreix els passos u a cinc la primera o la segona setmana. En l'ordre invers —primer funcionalitats i el perímetre després— la mateixa feina s'allarga un trimestre.

El buc és fet. Revisa sota la línia de flotació abans d'avarar-lo

Pensa en un vaixell sobre falques a la drassana: pintat, equipat, acabat als ulls de qui hi passa per davant. Ningú no l'avara sense que algú hagi revisat el que queda sota la línia de flotació. Lovable t'ha construït el buc de pressa i bé, i ha respost la pregunta difícil: si algú vol el producte. El que queda és la part que cap demo no ensenya, feta en un ordre conegut.

Si estàs valorant qui ho hauria de fer, he comparat les empreses que porten a producció MVP fets amb IA. O, si aquesta és la pregunta que tens al davant ara mateix, aquest és l'equip que posem en productes de startup: enginyers sènior seleccionats amb una taxa d'acceptació del 3%, que comencen amb una setmana de Blueprint per auditar el que tens, fixar l'arquitectura i deixar-te un pla per escrit que pots executar amb nosaltres o sense nosaltres.