--- title: "Er Supabase GDPR-kompatibelt? Hvor dine data reelt ligger" description: "Supabase holder databasen, Auth og Storage i den region, du vælger. Storage-CDN, Edge Functions, logs og support arbejder andre steder. Lovable Cloud også." url: "https://madsalt.tech/da/blog/is-supabase-gdpr-compliant/" author: "Denys Zaichenko" author_url: "https://madsalt.tech/da/about/" language: "da" published: 2026-11-04 --- # Er Supabase GDPR-kompatibelt? Hvor dine data reelt ligger TL;DR Supabase understøtter GDPR-kompatible apps og tilbyder en databehandleraftale (DPA), men det gør ikke din app kompatibel. Den region, du vælger, rummer Postgres-databasen, Auth, Storage-filer og backups. Fire ting arbejder uden for den: Storage-CDN'ets cache, Edge Functions, medmindre du fastlåser dem, platformens logs og supportadgang. Skal data blive i EU, så vælg Irland, Paris, Frankfurt eller Stockholm og ikke den generelle "Europe"-mulighed, som også kan ende i London eller Zürich. En region kan ikke ændres senere: at flytte betyder et nyt projekt og en migrering. Lovable Cloud fungerer på samme måde og vælger den region, der er tættest på dig, medmindre du selv vælger. Jeg er Denys, fullstack- og AI-ingeniør, og de fleste apps, jeg bygger eller retter, kører på Supabase. Europæiske klienter stiller to spørgsmål, før noget andet: er Supabase GDPR-kompatibelt, og hvor ligger dataene? Denne artikel besvarer begge ud fra Supabases og Lovables egne dokumenter, læst 29. oktober 2026, plus de kommandoer, jeg bruger til at tjekke et projekt. ## Er Supabase GDPR-kompatibelt? Supabases [GDPR-guide](https://supabase.com/docs/guides/security/gdpr-compliance) beskriver det som et delt ansvar: Supabase sikrer infrastrukturen, og du er ansvarlig for din applikations databehandling, samtykkeflows og adgangskontrol. I GDPR-termer er Supabase din databehandler for de data, du gemmer, og dets [Data Processing Addendum](https://supabase.com/legal/customer-resources/data-processing-addendum) er den kontrakt, der siger det. Det samme dokument udpeger Supabase som dataansvarlig for én kategori, de brugsdata, det indsamler for at drive platformen. To dele af den DPA har betydning i praksis: - **Region.** Når du beder Supabase behandle data i en region, gemmer og behandler det dem primært dér, medmindre loven, dine egne instrukser eller den tjeneste, du har bedt om, kræver andet. - **Underdatabehandlere.** Du godkender på forhånd Supabases [liste over underdatabehandlere](https://supabase.com/legal/customer-resources/subprocessor-list), og Supabase giver 30 dages varsel, før listen ændres. Du kan abonnere på ændringerne på samme side. Listen omfatter AWS og Cloudflare til hosting samt tjenesteudbydere til support, fejlovervågning og beskeder til kontobrugere. ## Hvor gemmer Supabase dine data? [FAQ'en om dataplacering](https://supabase.com/legal/privacy-resources/data-residency-and-transfers-faq) og [regionssiden](https://supabase.com/regions) deler det sådan op: | Del af dit projekt | Hvor den behandles | | ---------------------------------- | ------------------------------------------------------------------------------------- | | Postgres-databasen og dens backups | Den AWS-region, du valgte | | Auth (brugere, sessioner) | Den region, du valgte | | Storage-filer ved oprindelsen | Den region, du valgte | | Storage-CDN'ets cache | Globalt, cachet på Cloudflare | | Edge Functions | Ved den edge, der er nærmest kalderen, medmindre du fastlåser dem til en region | | Platformens logs og telemetri | Uden for din region; logs gemmes i EU-datacentre | | Supportadgang | Et globalt supportteam, når du beder om hjælp eller ved en sikkerhedshændelse, logget | | Dine konto- og betalingsdata | Supabases centrale systemer; Supabase er dataansvarlig her | ![Hvor hver del af et Supabase-projekt behandles. Region = den AWS-region, du vælger, når du opretter projektet. Database, Auth, backups: Postgres, Auth → din region; Storage-filer: fil → din region → CDN-cache, global; Edge Functions, ikke fastlåst: funktionskald → edge nærmest kalderen; Platformens logs: logs, telemetri → EU-datacentre.](https://madsalt.tech/charts/da/is-supabase-gdpr-compliant.svg) *Figur 1. Supabases FAQ om dataplacering og regionssiden, læst 29. oktober 2026.* FAQ'en svarer direkte på det barske spørgsmål: Supabase garanterer ikke, at dine data aldrig forlader regionen. Din database og dine backups bliver; de fire kategorier nederst i tabellen kan forlade den. ## Hvilke Supabase-regioner ligger i EU? Fire bestemte regioner ligger inden for 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-tilstrækkelighedsafgørelser, men de er ikke EU-medlemsstater. Den forskel betyder noget, når du opretter projektet. Den generelle "Europe"-mulighed lader Supabase vælge en ledig europæisk region efter kapacitet, og [regionsguiden](https://supabase.com/docs/guides/platform/regions) advarer om, at det kan blive London eller Zürich. Hvis din kontrakt eller din kunde siger "data bliver i EU", så vælg en bestemt EU-region. Én detalje mere, hvis du bruger regionale Edge Functions: regionssiden siger, at det ikke er muligt at fastlåse en funktion til en region i Ohio eller Stockholm. ## Hvordan tjekker du dit projekts region? I dashboardet vises regionen i projektets indstillinger. Fra en terminal viser Supabase CLI alle projekter, du har adgang til, med deres region: ```bash supabase projects list supabase projects list -o json # each project has a "region" field, e.g. "eu-west-1" ``` Jeg kørte det på min egen konto med CLI 2.109.1: hvert projekt kom tilbage med sin AWS-regionskode, så et hurtigt blik viser, om et projekt ligger uden for EU. **Kan du ændre den?** Nej. Supabases [fejlfindingsnote](https://supabase.com/docs/guides/troubleshooting/change-project-region-eWJo5Z) siger, at et projekt er bundet til sin region på infrastrukturniveau. At flytte betyder at oprette et nyt projekt i målregionen og migrere til det, og derefter opdatere din API-URL og dine nøgler i appen og kopiere hemmeligheder til tredjepartslogin i hånden. En projektoverførsel til en anden organisation ændrer heller ikke regionen. ## Er Lovable Cloud GDPR-kompatibelt? En Lovable Cloud-app kører sin backend efter samme model, så de samme spørgsmål gælder, med Lovables indstillinger foran. Fra Lovables [backend-dokumentation](https://docs.lovable.dev/features/cloud), [databasedokumentation](https://docs.lovable.dev/features/database) og [DPA-side](https://lovable.dev/data-processing-agreement): - **Regionen er en af Americas, Europe eller Asia Pacific**, valgt når backend aktiveres. En standard for arbejdsområdet, sat af en admin, vinder (Business- og Enterprise-planer). Ellers bruger Lovable din egen indstilling "where project data is stored", og uden den den region, der er tættest på dig. - **Du ser den måske aldrig.** Med Enable Cloud sat til "Always allow" opretter Lovable backend i den region uden at spørge. Kun "Ask each time" viser regionen først. - **Den kan ikke ændres.** Lovable siger ligeud, at et projekts region ikke kan ændres, og at et eksisterende projekt ikke kan flyttes. - **Tjek den** under More → Database → Manage → Settings, i rækken Database location, for eksempel "Europe (Frankfurt)". - **Selve sitet leveres globalt**, uanset regionen; regionen dækker kun backend. - **AI-forespørgsler er en sag for sig.** At holde AI-modelforespørgsler i EU er en indstilling kaldet EU inference, på Enterprise-arbejdsområder. - **DPA'en er inkluderet på Business- og Enterprise-planer.** Så hvis du aktiverede backend, mens du arbejdede uden for Europa, uden en indstilling af din egen, kan backend ligge i en anden region, og med "Always allow" slået til spørger Lovable ikke. Tjek rækken Database location, før din første rigtige bruger tilmelder sig. ## Hvad regionen ikke løser Supabases egen guide siger det: at vælge en region er en kontrol af dataplacering og gør ikke i sig selv en applikation GDPR-kompatibel. De huller, jeg oftest finder, ligger i appen, ikke i platformen: 1. **Persondata, som enhver kan læse.** En tabel med RLS slået fra eller en policy, der tillader hver række, udleverer navne og e-mails til enhver med den offentlige nøgle. Det gratis [Supabase sikkerhedstjek](https://madsalt.tech/da/tools/supabase-security-check/) markerer tabeller uden RLS, policies der tillader hver række og følsomt udseende kolonner, der kan læses af anonyme besøgende. 2. **Konti oprettet med en andens adresse.** Med e-mailbekræftelse slået fra kan enhver tilmelde sig med en adresse, vedkommende ikke ejer. 3. **Filer i offentlige buckets.** En [offentlig bucket](https://madsalt.tech/da/notes/supabase-public-bucket/) leverer hver fil til enhver med dens URL, og CDN'et cacher den over hele verden. 4. **Databehandlere, du selv har tilføjet.** Hver e-mail-, SMS-, AI- eller analysetjeneste, dine Edge Functions kalder, er din databehandler, ikke Supabases, og har brug for sin egen aftale. 5. **Sletning og opbevaring.** En anmodning om sletning fejler, hvis fremmednøgler blokerer for at slette en bruger, der har skrevet indhold, og logs, der gemmer adresser for evigt, er et opbevaringsproblem. De to sidste og fire til gennemgår jeg i GDPR-afsnittet i min [sikkerhedstjekliste til Lovable-apps](https://madsalt.tech/da/blog/lovable-app-security-checklist/). For hvad Supabase certificerer ud over GDPR, se [er Supabase sikkert?](https://madsalt.tech/da/blog/is-supabase-secure/). Denne artikel er ikke juridisk rådgivning; din databeskyttelsesrådgiver eller jurist afgør, hvad din behandling kræver. Usikker på, hvor din apps data ligger? Jeg tjekker gerne regionen og adgangsreglerne sammen med dig. Ingen salgstale. [Kontakt mig](https://madsalt.tech/da/#contact)