--- title: "Er Supabase GDPR-kompatibelt? Hvor dataene faktisk ligger" description: "Supabase holder databasen, Auth og Storage i regionen du velger. Storage-CDN, Edge Functions, logger og support jobber andre steder. Lovable Cloud også." url: "https://madsalt.tech/no/blog/is-supabase-gdpr-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/no/about/" language: "no" published: 2026-11-04 --- # Er Supabase GDPR-kompatibelt? Hvor dataene faktisk ligger TL;DR Supabase støtter GDPR-kompatible apper og tilbyr en databehandleravtale (DPA), men det gjør ikke appen din kompatibel. Regionen du velger rommer Postgres-databasen, Auth, Storage-filer og sikkerhetskopier. Fire ting jobber utenfor den: cachen til Storage-CDN-et, Edge Functions med mindre du låser dem, plattformens logger og støttetilgang. Må dataene bli i EU, velg Irland, Paris, Frankfurt eller Stockholm, ikke det generelle "Europe"-alternativet, som også kan havne i London eller Zürich. En region kan ikke endres senere: å flytte betyr et nytt prosjekt og en migrering. Lovable Cloud fungerer på samme måte og velger regionen nærmest deg hvis du ikke velger selv. Jeg er Denys, fullstack- og AI-ingeniør, og de fleste appene jeg bygger eller retter, kjører på Supabase. Europeiske klienter stiller to spørsmål før noe annet: er Supabase GDPR-kompatibelt, og hvor ligger dataene? Denne artikkelen svarer på begge fra Supabases og Lovables egne dokumenter, lest 29. oktober 2026, pluss kommandoene jeg bruker for å sjekke et prosjekt. ## Er Supabase GDPR-kompatibelt? Supabases [GDPR-guide](https://supabase.com/docs/guides/security/gdpr-compliance) beskriver det som delt ansvar: Supabase sikrer infrastrukturen, og du er ansvarlig for applikasjonens databehandling, samtykkeflyt og tilgangskontroll. I GDPR-termer er Supabase databehandleren din for dataene du lagrer, og [Data Processing Addendum](https://supabase.com/legal/customer-resources/data-processing-addendum) er kontrakten som sier det. Samme dokument kaller Supabase behandlingsansvarlig for én kategori, bruksdataene det samler inn for å drive plattformen. To deler av den DPA-en har betydning i praksis: - **Region.** Når du ber Supabase behandle data i en region, lagrer og behandler det dem primært der, med mindre loven, dine egne instrukser eller tjenesten du har bedt om krever noe annet. - **Underdatabehandlere.** Du godkjenner Supabases [liste over underdatabehandlere](https://supabase.com/legal/customer-resources/subprocessor-list) på forhånd, og Supabase varsler 30 dager før listen endres. Du kan abonnere på endringene på samme side. Listen omfatter AWS og Cloudflare for hosting, og tjenesteleverandører for support, feilovervåking og meldinger til kontobrukere. ## Hvor lagrer Supabase dataene dine? [FAQ-en om dataplassering](https://supabase.com/legal/privacy-resources/data-residency-and-transfers-faq) og [regionsiden](https://supabase.com/regions) deler det slik: | Del av prosjektet ditt | Hvor den behandles | | --------------------------------------- | ---------------------------------------------------------------------------------- | | Postgres-databasen og sikkerhetskopiene | AWS-regionen du valgte | | Auth (brukere, sesjoner) | Regionen du valgte | | Storage-filer ved opprinnelsen | Regionen du valgte | | Storage-CDN-ets cache | Globalt, bufret på Cloudflare | | Edge Functions | Ved edgen nærmest den som kaller, med mindre du låser dem til en region | | Plattformens logger og telemetri | Utenfor regionen din; loggene lagres i EU-datasentre | | Støttetilgang | Et globalt støtteteam, når du ber om hjelp eller ved en sikkerhetshendelse, logget | | Konto- og betalingsdataene dine | Supabases sentrale systemer; Supabase er behandlingsansvarlig her | ![Hvor hver del av et Supabase-prosjekt behandles. Region = AWS-regionen du velger når du oppretter prosjektet. Database, Auth, sikkerhetskopier: Postgres, Auth → din region; Storage-filer: fil → din region → CDN-cache, global; Edge Functions, ikke låst: funksjonskall → edge nærmest kalleren; Plattformlogger: logger, telemetri → EU-datasentre.](https://madsalt.tech/charts/no/is-supabase-gdpr-compliant.svg) *Figur 1. Supabases FAQ om dataplassering og regionsiden, lest 29. oktober 2026.* FAQ-en svarer rett på det brutale spørsmålet: Supabase garanterer ikke at dataene dine aldri forlater regionen. Databasen og sikkerhetskopiene blir; de fire kategoriene nederst i tabellen kan forlate den. ## Hvilke Supabase-regioner ligger i EU? Fire bestemte regioner ligger innenfor EU: West EU (Ireland) `eu-west-1`, West EU (Paris) `eu-west-3`, Central EU (Frankfurt) `eu-central-1` og North EU (Stockholm) `eu-north-1`. London `eu-west-2` og Zürich `eu-central-2` ligger i Europa og har GDPR-tilstrekkelighetsvedtak, men er ikke EU-medlemsland. Den forskjellen betyr noe når du oppretter prosjektet. Det generelle "Europe"-alternativet lar Supabase velge en ledig europeisk region etter kapasitet, og [regionguiden](https://supabase.com/docs/guides/platform/regions) advarer om at det kan bli London eller Zürich. Hvis kontrakten din eller kunden sier "data blir i EU", velg en bestemt EU-region. Én detalj til hvis du bruker regionale Edge Functions: regionsiden sier at det ikke er mulig å låse en funksjon til en region i Ohio eller Stockholm. ## Hvordan sjekker du regionen til prosjektet ditt? I dashbordet vises regionen i prosjektets innstillinger. Fra en terminal lister Supabase CLI alle prosjekter du har tilgang til, med region: ```bash supabase projects list supabase projects list -o json # each project has a "region" field, e.g. "eu-west-1" ``` Jeg kjørte dette på min egen konto med CLI 2.109.1: hvert prosjekt kom tilbake med AWS-regionkoden sin, så et raskt blikk viser om noe prosjekt ligger utenfor EU. **Kan du endre den?** Nei. Supabases [feilsøkingsnotat](https://supabase.com/docs/guides/troubleshooting/change-project-region-eWJo5Z) sier at et prosjekt er bundet til regionen på infrastrukturnivå. Å flytte betyr å opprette et nytt prosjekt i målregionen og migrere til det, og deretter oppdatere API-URL-en og nøklene i appen og kopiere hemmeligheter for tredjeparts innlogging for hånd. En prosjektoverføring til en annen organisasjon endrer heller ikke regionen. ## Er Lovable Cloud GDPR-kompatibelt? En Lovable Cloud-app kjører backend etter samme modell, så de samme spørsmålene gjelder, med Lovables innstillinger foran. Fra Lovables [backend-dokumentasjon](https://docs.lovable.dev/features/cloud), [databasedokumentasjon](https://docs.lovable.dev/features/database) og [DPA-side](https://lovable.dev/data-processing-agreement): - **Regionen er én av Americas, Europe eller Asia Pacific**, valgt når backend aktiveres. En standard for arbeidsområdet satt av en admin går foran (Business- og Enterprise-planer). Ellers bruker Lovable din egen innstilling "where project data is stored", og uten den regionen nærmest deg. - **Du ser den kanskje aldri.** Med Enable Cloud satt til "Always allow" oppretter Lovable backend i den regionen uten å spørre. Bare "Ask each time" viser regionen først. - **Den kan ikke endres.** Lovable sier rett ut at regionen til et prosjekt ikke kan endres og at et eksisterende prosjekt ikke kan flyttes. - **Sjekk den** under More → Database → Manage → Settings, i raden Database location, for eksempel "Europe (Frankfurt)". - **Selve nettstedet leveres globalt**, uansett region; regionen dekker bare backend. - **AI-forespørsler er en egen sak.** Å holde forespørsler til AI-modeller i EU er en innstilling som heter EU inference, på Enterprise-arbeidsområder. - **DPA-en er inkludert på Business- og Enterprise-planer.** Så hvis du aktiverte backend mens du jobbet utenfor Europa, uten en egen innstilling, kan backend ligge i en annen region, og med "Always allow" på spør ikke Lovable. Sjekk raden Database location før den første ekte brukeren registrerer seg. ## Hva regionen ikke løser Supabases egen guide sier det: å velge en region er en kontroll av dataplassering og gjør ikke i seg selv en applikasjon GDPR-kompatibel. Hullene jeg oftest finner, ligger i appen, ikke i plattformen: 1. **Personopplysninger som alle kan lese.** En tabell med RLS av, eller en policy som slipper gjennom hver rad, serverer navn og e-poster til alle som har den offentlige nøkkelen. Den gratis [Supabase sikkerhetssjekken](https://madsalt.tech/no/tools/supabase-security-check/) flagger tabeller uten RLS, policyer som slipper gjennom hver rad og sensitivt utseende kolonner som anonyme besøkende kan lese. 2. **Kontoer opprettet med en annens adresse.** Med e-postbekreftelse av kan hvem som helst registrere seg med en adresse de ikke eier. 3. **Filer i offentlige buckets.** En [offentlig bucket](https://madsalt.tech/no/notes/supabase-public-bucket/) serverer hver fil til alle med URL-en, og CDN-et bufrer den over hele verden. 4. **Databehandlere du selv la til.** Hver e-post-, SMS-, AI- eller analysetjeneste Edge Functions kaller, er din databehandler, ikke Supabases, og trenger sin egen avtale. 5. **Sletting og oppbevaring.** En sletteforespørsel feiler hvis fremmednøkler hindrer sletting av en bruker som har skrevet innhold, og logger som beholder adresser for alltid, er et oppbevaringsproblem. De to siste, og fire til, går jeg gjennom i GDPR-delen av [sikkerhetssjekklisten min for Lovable-apper](https://madsalt.tech/no/blog/lovable-app-security-checklist/). For hva Supabase sertifiserer utover GDPR, se [er Supabase trygt?](https://madsalt.tech/no/blog/is-supabase-secure/). Denne artikkelen er ikke juridisk rådgivning; personvernombudet eller juristen din avgjør hva behandlingen din krever. Usikker på hvor dataene i appen din ligger? Jeg sjekker gjerne regionen og tilgangsreglene sammen med deg. Ingen salgstale. [Ta kontakt](https://madsalt.tech/no/#contact)