Har du noensinne prøvd å bygge en SaaS-applikasjon og så kommet til punktet der du må skille data mellom kunder? Det er ikke bare teknisk utfordrende - det er kritisk. Feil her kan føre til at en kunde ser data fra en annen. Og i verste fall: en straffesak. Når du bruker vibe coding - der du bare beskriver hva du vil, og AI genererer koden - blir det enda vanskeligere. Fordi AI ikke vet hva du ikke sier. Og i multi-tenancy, er det det du ikke sier som ødelegger alt.
Hva er multi-tenancy, og hvorfor er det så viktig?
Multi-tenancy betyr at én enkelt applikasjonsinstans tjener mange kunder - eller "tenanter" - samtidig. Hver kunde har sin egen data, sine egne innstillinger, og sin egen brukeropplevelse. Men alt kjører på samme kode, samme servere, samme database. Det er ikke bare effektivt - det er økonomisk nødvendig. I 2024 var 73 % av alle nye SaaS-applikasjoner bygget på denne modellen. Det er ikke en tilfeldighet. Det er fordi du ikke kan skalerer en SaaS til tusenvis av kunder hvis du må bygge en egen server for hver enkelt.
Men her kommer utfordringen: hvordan sikrer du at én kunde ikke kan komme til dataene til en annen? En enkel feil i databaseforespørselen - f.eks. å glemme å legge til WHERE tenant_id = X - kan åpne for en total datalekkasje. Og i en vibe-coded applikasjon, hvor AI genererer koden basert på en tekstbeskrivelse, er det lett å glemme å spesifisere dette. Det er ikke AI-en som er feil. Det er deg. Fordi du ikke sa nok.
Hvordan isolerer du tenanter? Tre strategier
Det finnes tre måter å isolere data mellom kunder på. Og du må velge riktig fra dag én.
- Databasen per kunde: Hver kunde har sin egen database. Enkelt og trygg. Men dyrt. Hver database krever ressurser, backup, og vedlikehold. Ikke praktisk for mange kunder.
- Delte database, skjemaer per kunde: Én database, men hver kunde har sitt eget skjema (som en egen "mappe" inni databasen). Bedre ressursutnyttelse. Men kompleks i vedlikehold og oppdateringer.
- Delte database, radnivå-isolasjon: Alle kunder deler samme tabeller, men hver rad har et
tenant_id-felt. Alle forespørsler må inkludere dette feltet. Det er den vanligste modellen i moderne SaaS - og den som AI mest ofte feiler på.
Bitcot sin løsning fra januar 2024 bruker radnivå-isolasjon med PostgreSQLs Row-Level Security (RLS). Det betyr at databasen selv blokkerer alle forespørsler som ikke har riktig tenant_id. Ingen unntak. Ingen glemsler. Og det er nettopp det du må si til AI-en: "Implementer RLS med tenant_id som diskriminator. Ingen forespørsel skal kunne gå gjennom uten det."
Autentisering: Ikke bare "logg inn" - men "logg inn som riktig kunde"
En kunde kan ha flere brukere. En annen kunde kan bruke SSO med Azure AD. En tredje kan bruke Google Login. Og du må håndtere alle samtidig - uten å blande dem.
Her er det ikke nok å bare bruke Supabase Auth eller Firebase Auth. Du må ha et system som vet hvilken kunde hver bruker tilhører. Og hvordan? Gjennom et tenant context-system. Når en bruker logger inn, må systemet ikke bare bekrefte passordet - det må også sette en "tenant"-kontekst som følger alle påfølgende forespørsler.
AI kan generere en login-side. Men den vil ikke automatisk legge til tenant-kontekst. Du må spesifisere: "Når en bruker logger inn, hent tenant_id fra brukerens konto og legg den i en JWT-token. Bruk denne tokenen i alle API-kall. Ingen forespørsel uten tenant_id skal tillates."
Bitcot sin løsning bruker en API-gateway som validerer tokenen før den lar kallet gå videre. Hvis tenant_id mangler, blir kallet avvist. Denne kontrollen må bygges inn i arkitekturen fra start - ikke etterpå. Og det er akkurat det som går galt i 62 % av SaaS-startupene som bruker vibe coding, ifølge Gartner.
Kostnadsstyring: Når én kunde sluker hele serveren
En av de mest skjulte farene i multi-tenancy er ressursforbruk. Tenk deg at én kunde - kanskje en stor bedrift - begynner å laste opp 100 GB data per dag. Eller kjører 50 000 forespørsler i minuttet. Hvis du ikke setter grenser, vil denne kunden forbruke 80 % av alle ressursene. Og alle andre kunder får tregt svar. Eller ingen svar.
Her er det ikke nok å bare bruke AWS Lambda. Du må måle. Du må sette grenser. Og du må stoppe. Når en kunde når 90 % av sin tildelte kvote, må systemet varsle. Ved 100 %, må det blokkere.
Bitcot bruker serverless funksjoner til å måle hver kundes bruk i sanntid. Hver API-kall registreres med tenant_id. Hver databaseforespørsel telles. Hver filopplasting måles. Og hvis en kunde går over grensen - stopper systemet automatisk. Og sender en varsling.
Men AI vil ikke generere dette. Du må spesifisere det: "Bygg et metering-system som registrerer alle API-kall, databaseforespørsler og filopplastinger per tenant. Bruk en dynamisk kvote basert på abonnement. Blokker overbruk."
En utvikler på Reddit skrev i juli 2024: "Jeg spilte $12 000 på AWS fordi min vibe-coded SaaS ikke hadde kostnadsstyring. Én kunde brukte 83 % av alle ressurser. Jeg måtte stoppe alt."
Vibe coding er ikke en magisk knapp
Det er en myte at vibe coding gjør alt enkelt. Det gjør det raskt. Men ikke enklere. Du kan generere en login-side på 30 sekunder. Men hvis du ikke spesifiserer at hver forespørsel må inneholde tenant_id, så vil AI generere en applikasjon som lekkasjer data. Og du vil ikke vite det før en kunde kommer med klage.
Fronteggs CTO, Eran Stiller, sa i mars 2024: "Vibe coding skaper 'black box'-arkitekturer. Uten å forstå hva AI-en har bygget, kan du ikke sikre at det er trygt."
GitHub sin forskning fra mai 2024 viser at når du spesifiserer isolasjonskrav eksplisitt - "Bruk RLS. Bruk tenant_id. Ingen forespørsel uten tenant_id. Alle kall må ha JWT med tenant_id. Bruk API-gateway for å validerer det." - så lykkes AI i 87 % av tilfellene. Uten det? Bare 41 %.
Hva må du gjøre før du starter?
Her er det ikke nok å bare skrive: "Bygg en SaaS med multi-tenancy."
Du må gjøre dette før du lar AI skrive én linje kode:
- Velg isolasjonsstrategi: Radnivå med tenant_id er den beste for de fleste.
- Definer autentisering: Hvilke IDP-er bruker kundene? Hva er token-strukturen?
- Sett kostnadsbetingelser: Hva er kvoten per kunde? Hva skjer ved overbruk?
- Bygg testprosedyrer: Automatiser tester som sjekker at ingen forespørsel kan hoppe over tenant_id.
- Test manuelt: Bruk et verktøy som Burp Suite eller Postman. Prøv å gjøre en forespørsel uten tenant_id. Den må avvises.
Bitcot anbefaler 15-20 timer med arkitekturplanlegging før du starter vibe coding. Det er ikke tid tapt. Det er besparelse. Fordi å fikse en feil i multi-tenancy etter at applikasjonen er bygget, tar 40-60 timer - og ofte må du starte på nytt.
Hva skjer hvis du glemmer det?
En feil i multi-tenancy er ikke bare en bug. Den er en sikkerhetsbrudd. Og det er ikke teoretisk. I 2024 utgjorde feil i tenant-isolasjon 34 % av alle SaaS-sikkerhetsbrudd, ifølge AWS. Og 17 % av alle SaaS-brudd i første halvår av 2024 skyldtes GDPR- og CCPA-overtrædelser - altså datalekkasje mellom kunder.
En utvikler på Hacker News skrev: "Jeg bygde en SaaS med vibe coding i 2 dager. Men det tok 3 uker å fikse datalekkasjene. Jeg fikk en klage fra en kunde som så finansdata fra en konkurrent."
Det er ikke bare et teknisk problem. Det er et juridisk problem. Og et økonomisk problem. Og et reputasjonsproblem.
Det er ikke AI som feiler. Det er deg.
Vibe coding er ikke en erstatning for arkitekturforståelse. Det er en forsterker. Og hvis du ikke forstår isolasjon, autentisering og kostnadsstyring - så vil AI forsterke dine feil. Ikke rette dem.
Den eneste måten å bygge trygg multi-tenancy i en vibe-coded SaaS er å være ekstremt spesifikk. Ikke si: "Bygg en SaaS." Si: "Bruk PostgreSQL RLS. Alle tabeller må ha tenant_id. Alle forespørsler må inkludere tenant_id fra JWT. API-gateway må avvise alle forespørsler uten det. Bruk serverless funksjoner til å måle bruk per tenant. Blokker ved 100 %. Send varsling ved 90 %."
Det er ikke vanskelig. Det er enkelt. Bare du må si det. Og du må si det før du skriver én linje kode.
Post Comments (7)
AI skriver kode og vi skal være ekstra spesifikke? Haha. Det er jo som å be en katt om å ikke hoppe på bordet. AI er ikke en hjelper, den er en bombetimer. Når du sier "bygg en SaaS", får du en applikasjon som lar alle se alle data. Og så kommer folk og sier "det er ikke AI-en sin feil, det er din". Nei. Det er systemets feil. Og systemet er skapt av mennesker som tror de kan forutsi alt. Det er ikke teknologi som er farlig. Det er menneskets overtro. 🤡
Det er så fascinerende hvordan folk bare aksepterer at AI skal skrive kritisk infrastruktur. Det er som å la en 14-åring bygge en bro. Vibe coding er ikke en fremtid - det er en kollaps i gjennomføring. Og så skal vi ha RLS, JWT, API-gateways? Hvor mange av disse startupene har faktisk en devsecops-ansvarlig? 3%? 5%? Jeg har sett 12 SaaS-er i løpet av 2024 som ble stengt av GDPR fordi de trodde "tenant_id" var en god ide - men ikke at den måtte være kryptert. Det er ikke en bug. Det er en kulturell feil. Og vi feirer det som "innovasjon". 🤭
Det er viktig å understreke at multi-tenancy ikke er et teknisk problem, men et arkitektonisk og prosessmessig utfordring. RLS i PostgreSQL er en solid løsning, men den må kombineres med streng kontroll av autentiseringsflow og logging av alle forespørsler. Det er også kritisk å implementere testkasuser som simulerer angrep - ikke bare funksjonelle tester. En god praksis er å bruke infrastruktur som kode (IaC) for å sikre at RLS-regler er definert i versjonskontroll. Uten dette, vil selv de mest spesifiserte AI-instruksjonene være ufullstendige. Det er ikke nok å si "husk tenant_id". Man må bygge systemer som ikke tillater å glemme det. Det er arkitektur, ikke magi.
LOL så du må si "alle forespørsler må ha tenant_id" for at AI skal forstå det? 🤦♂️ Hva om du bare sier "gjør det trygt"? AI blir jo ikke smartere hvis du skriver 100 ord. Det er som å si til en kokebok "gjør maten god" og så skrik "NEI, BRUK SALT!" 😂 Jeg har prøvd vibe coding med 3 ulike AI-er - og den ene som faktisk fungerte, var den jeg sa: "hvis du glemmer tenant_id, skal du kaste en feil og skrive en epost til meg." Det var det eneste som virket. AI er ikke en tenkende maskin - den er en gjetne kopi av en utvikler som sovnet i 2018. 🤖
ja men egentlig så er det jo så enkelt? bare legg inn tenant_id i alle tabellene og så bruker du jwt token og så må alle kaller ha den… det er jo ikke så vanskelig? jeg prøvde det i en liten app og det fungerte med litt prøving og feil… men jeg tror mange glemmer å teste det manuelt… jeg brukte postman og prøvde å fjerne tenant_id og så ble det blocket 😊 sånn må du gjøre det… ikke bare stole på AI… du må sjekke selv…
Det er så viktig å huske at teknologi ikke er ferdig før du har testet den med en ekte bruker. Jeg har hjulpet flere småbedrifter med SaaS, og det som gjør forskjellen, er ikke AI eller RLS - det er at du snakker med kunden. Spør dem: "Hvordan vil du oppleve dette?" Ofte kommer de med ideer du aldri tenkte på. Og ja - du må si eksakt hva du vil. Men du må også lytte. En god arkitekt er ikke den som skriver mest kode - han er den som skriver minst kode, og får mest ut av det. Ikke la AI ta over. La den hjelpe. Og husk: en god løsning er ikke den som er kompleks - den er den som ikke går i stykker. 🙌
Det er så rart at alle ser på vibe coding som en "feil" - men det er jo bare et verktøy. Som en hammer. Du kan bygge et hus med den, eller slå deg selv i tåa. Problemet er ikke AI. Problemet er at vi ikke lenger lærer grunnleggende prinsipper. Hvorfor lærer ikke utviklere hvordan databaser virker før de lar AI skrive kode? Jeg liker at AI hjelper, men jeg vil ikke ha en app som jeg ikke forstår. Så jeg tester alt. Med Postman. Med Burp. Med en terminal. Og så ser jeg: "Hva skjer hvis jeg sletter tenant_id?" Og da ser jeg at systemet blokkerer. Da vet jeg at det er trygt. Det er ikke magi. Det er grunnleggende sikkerhet. 🛡️