06 — Isolation, hosting & overdragelse: beslutningsgrundlag
Formål: Give os grundlaget til at træffe den bedst mulige beslutning om arkitektur, hosting og backend til fabrikken — særligt hvordan vi laver isolerede miljøer pr. kunde der er nemme at skalere, domæne-tilknytte og sælge/overdrage til kunden bagefter.
Dette er et beslutningsgrundlag, ikke selve beslutningen. Når vi vælger, fanges valget som en ADR i
adr/. Se ogsåreference-stack.md(den foreslåede stack) oghosting-og-platform.md(GCP vs. Vercel+Convex).To produktlinjer, to arkitekturer: dette dokument dækker isoleret miljø pr. kunde — rigtigt for skræddersyede SaaS-leverancer der skal kunne sælges/overdrages som kode. For website-produktet i volumen (ét kodebase → tusindvis af SMV-sites) gælder den modsatte, delte multi-tenant-model — se
07-website-os-multi-tenant-arkitektur.md§2.Bygger på webresearch fra juli 2026 (priser verificeret mod leverandørernes egne sider den 2026-07-18). Feltet skifter hurtigt — verificér tal før endelige beslutninger og før du citerer priser til en kunde. Priser er ekskl. moms medmindre andet står; USD-omregning kurs ≈ 7, EUR ≈ 7,45.
1. TL;DR — anbefalingen på én side
-
Det ene greb der løser næsten alt:
OCI-container + Terraform + Postgressom fast fabriksstandard. Så længe hver kundeløsning er (a) pakket i en standard Docker/OCI-container, (b) beskrevet som Infrastructure-as-Code (Terraform), og (c) bruger standard-Postgres som datalag, er overdragelse = "flyt", ikke "genopbyg", og sprog + hosting bliver frikoblet fra lock-in. Det er den vigtigste enkeltbeslutning i hele dokumentet. -
To spor, ikke ét valg:
- Fast-lane (hurtige websites, fx CVR-produktet): Vercel (projekt pr. kunde) + Neon. Bedst udvikleroplevelse, indbygget "claim-deployment"-overdragelse skabt netop til bureau→kunde.
- Fabriks-lane (SaaS/apps der skal skaleres og overdrages): containeriseret app på Google
Cloud Run (projekt pr. kunde, EU) eller Fly.io (app pr. kunde) + Neon. Container-portabilitet
- scale-to-zero + ren overdragelse.
-
Microsoft-lane (kun for Microsoft-/enterprise-/.NET-kunder): Azure Container Apps (samme container, scale-to-zero, ~$0 compute) + Neon. Vælg bevidst, ikke som default — se punkt 3.
-
Azure: ja, men bevidst — og ikke for dyrt, hvis gjort rigtigt. Din frygt er kun berettiget på ét punkt: Azures egen Postgres koster ~$15–19/md pr. kunde (intet scale-to-zero). Med **ACA Consumption
-
Neon falder en lille kunde til ~$1–6/md** — compute er praktisk talt gratis. Kompleksiteten ligger ikke i containeren (lige så let som Cloud Run), men i Azures tenant/subscription/RBAC-overbygning. Vælg Azure når kunden er Microsoft-forankret, kører .NET, eller har formelle EU-compliance-krav — ellers er Cloud Run/Fly billigere og enklere. (Uddybet i §11.)
-
Kubernetes: ikke nu. Overkill for et to-mands-team med mange små kunder. Genovervej kun for én stor kunde med hård skala/isolationskrav (da: GKE Autopilot som namespace-per-tenant).
-
AI-/MCP-styrbarhed (dit minimumskrav) er opfyldt bredt. Alle seriøse kandidater kan drives af Claude Code via MCP + CLI + Terraform. Cloudflare og Vercel er de mest "AI-native"; Cloud Run/Fly/AWS/Azure/GCP kan alt via CLI + Terraform + officielle MCP-servere.
-
Sprog: standardisér fabrikken på TypeScript. Afvig bevidst til C#/.NET når kunden er Azure/Microsoft-enterprise, og til Python for data/ML/scripting (fx CVR-scriptet bliver i Python). Sproget bør ikke drive hosting-valget — containeren gør det ligegyldigt.
-
Vigtig konsekvens for den eksisterende reference-stack: overdragelses-kravet trækker standard-Postgres (Neon/Supabase) foran Convex som default for kundeleverancer. Convex er fortsat et rimeligt valg (open source + self-host + Postgres-understøttelse), men er "medium lock-in" og passer bedst til interne/AI-realtidsprodukter, ikke til det vi skal kunne overdrage let. Se §9.
2. Hvad skal beslutningen opfylde? (kriterier)
Kravene fra opgaven, oversat til vurderingskriterier:
| # | Kriterium | Hvorfor |
|---|---|---|
| K1 | Isolation pr. kunde | Hver kunde skal have sit eget miljø (data, drift, fejl-domæne, fakturering). |
| K2 | Nem at skalere/udvide | Op og ned uden omskrivning; lav trafik pr. kunde, mange kunder. |
| K3 | Nem domæne-tilknytning | Kundens eget domæne + automatisk HTTPS, uden bøvl. |
| K4 | Salgbar/overdragelig | Kunden skal kunne overtage kode + drift selv bagefter. Lav lock-in. |
| K5 | Fuldt AI-/MCP-styrbar (minimumskrav) | Claude Code skal kunne provisionere, deploye, konfigurere og styre distribution via MCP/connectors + CLI + IaC. |
| K6 | Lav, forudsigelig omkostning | To-mands-bootstrap; marginvagt (jf. ../administration/forretningsmodel-og-pricing.md §5). |
| K7 | Lav driftskompleksitet | Ikke fuldtids-DevOps; skal kunne håndteres af to personer + agenter. |
| K8 | EU/GDPR-hosting | Vi håndterer persondata (jf. ../produkter/cvr-leads-hjemmesider/handoff-teknisk.md §4). |
3. To akser — så vi sammenligner æbler med æbler
Spørgsmålet "Docker? Kubernetes? Azure/GCP/AWS/Vercel/Cloudflare?" blander to uafhængige akser. Vi holder dem adskilt og kombinerer dem derefter til konkrete modeller (§5):
- Akse 1 — Pakke-/isolationsmodel: hvordan isoleres og køres en kunde?
PaaS (push-to-deploy)·Serverless containere·Docker på VPS·Kubernetes·Edge/serverless. - Akse 2 — Leverandør: hvor kører det?
Vercel·Cloudflare·Google Cloud·AWS·Azure·Hetzner·Fly.io· DB:Neon/Supabase/Convex.
Nøgleindsigt: Isolations- og skalerings-egenskaber følger mest Akse 1; pris, AI-styrbarhed og overdragelses-mekanik følger mest Akse 2. Derfor sammenligner vi begge — og fastlægger containeren som den fælles nævner, så vi kan bevæge os på tværs uden omskrivning.
4. Platformene kort — hvad er hvad?
Før vi sammenligner: hvad er de forskellige spillere egentlig? (De første seks er hosting/compute; de sidste tre er databaser/backends.)
- Vercel — Hosting-platform bygget til frontend og især Next.js. Modellen er "push til git → live side" med nul server-opsætning; kendt for markedets bedste udvikleroplevelse. Du betaler pr. bruger (sæde) + forbrug. Bedst til websites/apps hvor fart til demo betyder mest.
- Cloudflare — Et globalt edge-netværk (startede som CDN/DNS/sikkerhed) der kan køre din kode tæt på brugeren via Workers, med egen database (D1) og fil-storage (R2). Billigst ved skala og mest "AI-native". Forbehold: Workers er ikke fuld Node.js, så noget kode er bundet til deres runtime.
- Google Cloud Run — Googles serverless container-tjeneste. Du afleverer en Docker-container; Google kører den, skalerer automatisk fra 0 til mange, og du betaler kun når den kører (scale-to-zero). Standard-containere = meget portabelt. Del af det store Google Cloud (GCP).
- Fly.io — Kør containere/apps tæt på brugere globalt via en enkel kommandolinje. "App = kunde"-
model, auto-stop/-start, og meget lav lock-in (alt er en
Dockerfile+ en lille config-fil). Mindre enterprise-/compliance-tyngde end de store clouds. - Hetzner — Tysk hosting-udbyder hvor du lejer en virtuel maskine (VPS) og selv kører Docker på den. Billigst og mest kontrol, laveste lock-in — men du står selv for OS-opdateringer og drift. EU-datacentre (DE/FI).
- Azure Container Apps (Microsoft) — Microsofts serverless container-tjeneste på Azure (svarer til Cloud Run): scale-to-zero, gratis automatisk TLS, gratis månedligt forbrugs-grant. Compute-laget er lige så enkelt som Cloud Run — men Azures tenant/subscription/RBAC-model er den tungeste at lære af alle kandidaterne. Stærkest til Microsoft-/enterprise-/.NET-kunder. Se den ærlige pris-/ kompleksitetsvurdering i §11 (Anbefaling).
- Kubernetes (GKE / AKS / EKS) — Ikke én tjeneste, men et system til at orkestrere mange containere på tværs af servere. Meget kraftfuldt til stor skala, men komplekst og dyrest ved mange små kunder. Findes managed hos Google (GKE), Azure (AKS) og AWS (EKS).
- Neon — Serverless Postgres-database. Helt almindelig Postgres, men med scale-to-zero (du
betaler ~$0 når databasen er idle) og lynhurtig "branching". Billigst for mange små databaser og
trivielt at tage med sig (
pg_dump) — derfor stærk til overdragelse. - Supabase — "Firebase oven på Postgres": database + auth + fil-storage + functions i én pakke. Hurtigt at komme i gang; lock-in opstår kun hvis man aktivt bruger de ekstra tjenester (selve databasen er standard-Postgres).
- Convex — En reaktiv backend hvor man skriver TypeScript-funktioner; stærk til AI- og realtidsapps. Open source og kan self-hostes med Postgres, men mere leverandør-specifik i sit app-design end ren Postgres — derfor "medium" lock-in.
5. Kandidat-modeller (dem vi faktisk sammenligner)
Seks konkrete modeller. "Pris/kunde/md" = realistisk for én lille, lav-trafik-kunde, inkl. database, konsolideret hvor det er billigst (fælles konto/plan, isoleret pr. projekt).
| Model | Kort | Pakke-/isolationsmodel | Typisk pris/kunde/md |
|---|---|---|---|
| M1 — Vercel + Neon | Push-to-deploy PaaS | Projekt pr. kunde i ét team | ~$1–2 ekstra (deler ét $20-sæde) · fuld isolation: +$20/kunde |
| M2 — Cloud Run + Neon | Serverless containere | GCP-projekt pr. kunde, EU | ~$1–3 (scale-to-zero + free tier) |
| M3 — Fly.io + Neon | App-maskiner (containere) | Fly-app/org pr. kunde | ~$3–4 (~$2 compute + $1–2 DB) |
| M4 — Cloudflare | Edge/serverless | Konto/projekt pr. kunde | ~$0–1 ekstra (deler ét $5-abon.) |
| M5 — Hetzner VPS + Docker | Docker Compose på VPS | Én VPS pr. kunde (DE/FI) | ~€7 ekskl. moms (~€9 inkl.) alt-i-alt |
| M6 — Managed Kubernetes | K8s | Namespace- eller cluster-pr-kunde | ~$10 (GKE Autopilot pod) → $40–100+ (cluster/kunde) |
| M7 — Azure Container Apps + Neon | Serverless containere | Resource group / subscription pr. kunde | ~$1–6 (ACA scale-to-zero + Neon) · ~$15–20 hvis Azure-egen Postgres |
Database er den reelle omkostningsdriver. Undgå én altid-tændt managed DB pr. lille kunde (Cloud SQL ~$8–10/md, Fly Managed Postgres fra $38/md, Supabase ~$10/md pr. projekt, Azure Postgres Flexible Server ~$15–19/md — ingen ægte scale-to-zero). Neon (scale-to-zero, brugsbaseret, ~$1–2/md pr. lille kunde, ~$0 når idle, op til 1.000 projekter, nu også Azure-native) passer "mange små idle kunder" markant bedre — og er standard-Postgres, så overdragelse =
pg_dump.
6. Omkostninger synliggjort (pris-matrix)
Alle tal verificeret mod leverandørens egen prisside 2026-07-18 medmindre markeret (sekundær kilde).
6a. Compute/hosting pr. lille kunde
| Leverandør | Model | Grundpris | Pris pr. lille kunde | Skalering | Note |
|---|---|---|---|---|---|
| Vercel | PaaS | $20/sæde/md (inkl. $20 forbrug) | ~$0 ekstra (projekt-pr-kunde) / $20 (team-pr-kunde) | Auto (Fluid Compute), forbrugsmålt | Ubegrænsede projekter + domæner på Pro |
| Cloudflare | Workers Paid | $5/md (10M req + 30M CPU-ms inkl.) | ~$0 ekstra under fælles konto | Serverless/edge, billigst ved skala | Containers GA 13-04-2026 |
| Google Cloud Run | Serverless container | $0 (free tier: 180k vCPU-s + 2M req/md, konto-bredt) | ~$0–2 (scale-to-zero) | Auto 0→N; cold start ved min=0 | $0,000024/vCPU-s (sekundær) |
| Fly.io | App-maskine | $0 | ~$2 (shared-cpu-1x, 256 MB; ~$0 auto-stop) | Auto-stop/-start pr. app | TLS-cert $0,10/md (10 gratis) |
| Azure Container Apps | Serverless container | $0 (grant: 180k vCPU-s + 360k GiB-s + 2M req/md, pr. subscription) | ~$0 (Consumption, scale-to-zero) | Auto 0→N; cold start ved min=0 | Environment gratis; managed TLS gratis. App Service B1 = ~$13/md altid-tændt |
| Hetzner | VPS + Docker | €5,49/md (CX23) | ~€7 alt-i-alt (+IPv4 €0,50 + backup ~€1,10) | Vertikal resize; LB ~€7,49/md | 20 TB traffik inkl.; DE/FI = EU |
| GKE Autopilot | Kubernetes | 1. cluster dækket af $74,40/md kredit (sekundær) | ~$10 (lille always-on pod) + evt. LB ~$18–25 | Pay-per-pod, Google driver noder | Namespace-per-tenant billigst |
| Azure AKS (Free) | Kubernetes | $0 control-plane | ~$40–90/cluster (node + LB) (sekundær) | — | Eneste cloud m. gratis control-plane pr. cluster |
| AWS EKS | Kubernetes | $73/md pr. cluster (control-plane) | ~$100+/cluster | — | Dårligste pris ved mange små; højeste kompleksitet |
Azure, kort: selve compute-laget (ACA Consumption) er praktisk talt gratis for små idle kunder — på niveau med Cloud Run. Frygten for at Azure bliver dyrt er kun berettiget på databasen: Azures egen Postgres (Flexible Server) har intet ægte scale-to-zero og koster ~$15–19/md pr. kunde. Løsningen er Neon (nu Azure-native), ikke at droppe Azure. Frygten for kompleksitet er berettiget på ét punkt: Azures tenant/subscription/RBAC-overbygning er tungere end Cloud Run/Fly — ikke ACA selv. Se §7–§9 + §11.
6b. Database pr. lille kunde
| DB | Model | Pris pr. lille kunde | Idle-pris | Overdragelse |
|---|---|---|---|---|
| Neon | Serverless Postgres, scale-to-zero | ~$1–2/md | ~$0 (kun storage ~$0,18) | pg_dump — trivielt. Meget lav lock-in |
| Supabase | Postgres-platform pr. projekt | ~$10/md (Micro) + $25 org-fee | Fuld pris (ingen scale-to-zero på betalt) | pg_dump; lock-in kun hvis Auth/Storage/Functions bruges |
| Cloud SQL | Managed Postgres | ~$8–10/md (sekundær) | Fuld pris (ingen scale-to-zero) | Standard Postgres; GCP-glue |
| Azure PostgreSQL Flexible Server | Managed (B1ms) | ~$15–19/md (compute ~$14,5 + 32 GiB storage ~$4,4) | Kan stoppes, men storage betales videre; ingen ægte auto-suspend | Standard Postgres; følger subscription ved overdragelse |
| Fly Managed Postgres | Managed | fra $38/md | Fuld pris | Standard Postgres |
| Convex | Reaktiv backend | (følger hosting) | — | Medium lock-in; self-host + Postgres muligt (§9) |
Læsning af tabellen: For "mange små idle kunder" er kombinationen billig/gratis compute + Neon klart billigst: M1/M2/M4/M7 lander reelt på ~$1–6/kunde/md, M3 (Fly) ~$3–4, M5 (Hetzner) ~€7–9 men med hårdest isolation og laveste lock-in, og M6 (Kubernetes) er dyrest og tungest ved denne profil. På alle clouds gælder: vælger man cloud-udbyderens egen altid-tændte managed Postgres (Cloud SQL, Azure Flexible Server) i stedet for Neon, tredobles omkostningen pr. kunde.
7. Isolation, skalering & domæne (K1–K3) pr. model
| Model | Isolation (K1) | Skalering (K2) | Domæne + HTTPS (K3) |
|---|---|---|---|
| M1 Vercel | Projekt-grænse (blødt) / team (hårdt, dyrt) | Auto, nul-config | Ubegrænsede custom domains gratis, auto-TLS — nemmest |
| M2 Cloud Run | Projekt pr. kunde = hård isolation | Auto 0→N | Domain mapping, Google-managed TLS gratis (LB koster ekstra) |
| M3 Fly.io | App/org pr. kunde = hård, ren | Auto-stop/-start | fly certs add, gratis IPv6/anycast, auto-TLS |
| M4 Cloudflare | Konto pr. kunde (ellers blødt) | Serverless, bedst ved skala | Ubegrænset, auto-DNS+cert; kræver domænet som CF-zone |
| M5 Hetzner VPS | VPS pr. kunde = hårdest (eget kernel/net/disk) | Vertikal resize; horisontal via LB | A-record → VPS + Caddy = zero-touch Let's Encrypt |
| M6 Kubernetes | Namespace (blødt) / cluster (hårdt) | Bedst til stor skala | LB + cert-manager; per-cloud annotations |
| M7 Azure ACA | Resource group (blødt) / subscription pr. kunde = hård | Auto 0→N | az containerapp hostname + gratis managed cert; ikke bag proxy |
Kort: hård isolation billigst via M2 (projekt/kunde), M3 (app/kunde), M5 (VPS/kunde) og M7 (subscription/kunde). Domæne-tilknytning nemmest på M1 (Vercel); M5 er tættest på "det bare virker" med Caddy; M7 har gratis automatisk TLS men certifikatet kan ikke udstedes gennem en proxy.
8. Overdragelse/salgbarhed (K4) — det nye, tunge krav
Princip: hold kode / infrastruktur / data adskilt og portable. Lock-in opstår kun når ét af de tre lag er bundet til en leverandør på en måde der kræver omskrivning frem for flytning.
Overdragelses-venlighed pr. model (nemmest → mest manuelt):
- M1 Vercel — nemmest inden for Vercel. Indbygget Project Transfer (zero downtime) og Claim-Deployments (claim-URL, gyldig 24 t — skabt netop til bureau→kunde og AI-genererede deployments; overfører også tilknyttede Neon/Supabase/Prisma-ressourcer). Kunden ender som ejer i sin egen konto uden at vi har haft deres betalingskort. At forlade Vercel helt er dog en ombygning af infra-limen (Edge Functions, KV, Blob) → hold kritisk logik i standard Next.js/Node.
- M5 Hetzner VPS / M3 Fly.io — laveste lock-in. Alt er
Dockerfile+docker-compose.yml/fly.toml - image. Overdrag = flyt VPS/app til kundens konto eller giv dem repo + registry-adgang, så de kører det hvor som helst. Intet proprietært at rulle tilbage.
- M2 Cloud Run — portabel container, stickier GCP-glue. Selve containeren kører overalt; IAM, Secret Manager, Cloud SQL, LB er GCP-specifik lim. Afbødes ved ét GCP-projekt pr. kunde → overdragelse = projekt-migration til kundens organisation (uden downtime) + skift af billing account.
- M7 Azure ACA — renest hvis subscription pr. kunde. Container er standard-OCI (portabel). Ren overdragelse = flyt hele subscriptionen til kundens Entra-tenant (formaliseret request/accept-flow)
- skift billing ownership → compute, DB og domæne følger med i én bevægelse. Advarsel: tenant-flyt sletter alle RBAC-tildelinger i kilde-tenanten uigenkaldeligt — planlæg det. Bruger man Neon som DB, ligger dataene hos Neon og skal overdrages separat; bruger man Azure Flexible Server, følger DB'en med.
- M6 Kubernetes — medium. Manifester er portable i teorien; ingress-annotations, CSI-storage og workload-identity er cloud-specifik lim der skal skrives om. Nemt hvis stateless + vanilla manifester.
- M4 Cloudflare — data er meget portabel, runtime mindre. D1 → standard SQLite-dump, R2 er S3-kompatibel. Men Workers-runtime er ikke fuld Node.js → Workers-native kode er delvist runtime-låst. Ingen ét-klik konto-transfer (flyt zone + redeploy).
Store platforme har alle konto-/projekt-overdragelse i 2026: Vercel (transfer/claim), AWS (direkte konto-overførsel mellem organisationer, nyt nov. 2025 — opret én AWS-konto pr. kunde), GCP (projekt-migration + billing-skift), Azure (subscription-flyt til kundens tenant + billing-transfer — en af Azures stærkeste salgsfordele over for enterprise), Cloudflare (zone-flyt + EPP-kode for domæne).
Konsekvens: isolér arbejdet i kunde-specifikke konti/projekter fra dag ét. Så bliver overdragelse en indbygget platformsoperation frem for en oprydningsøvelse.
8a. Handover-pakke (standardiseret leverance — brug som salgsargument)
Ét git-repo kunden overtager:
kundeprojekt/
├── README.md # Hvad er dette, hvordan hænger det sammen
├── RUNBOOK.md # Deploy, rollback, backup/restore, secrets-rotation, kendte fejl
├── app/ # Applikationskode (portabel, standard-framework)
├── Dockerfile # OCI-image — kører hvor som helst
├── docker-compose.yml # Lokal kørsel med ét kommando
├── infra/ # Terraform: HELE miljøet
│ └── modules/{app, cloud-specific} # cloud-specifikke ressourcer tydeligt isoleret
├── .env.example # Skabelon for ALLE env-vars (uden hemmeligheder)
├── db/ # schema.sql + migrations + pg_dump-instruktion
├── .github/workflows/ # CI/CD (GitHub Actions, portabelt)
└── HANDOVER.md # Overdragelses-checkliste (repo, platform-transfer, domæne/EPP,
# secrets, verificeret pg_dump, DNS/cert, genskabelsestest, runbook)
Salgsvinkel: skriv en "Handover-garanti" ind i kontrakten ("ved ophør leverer vi inden X dage en komplet handover-pakke og gennemfører platform-transfer til jeres egne konti"). Pak den evt. som en fast leverance — "Digital nøgle-overdragelse". Det gør det abstrakte ("ingen lock-in") til noget konkret kunden kan se og betale for — en differentiator mod bureauer der holder kunder som gidsler.
9. AI-/MCP-styrbarhed (K5, minimumskravet)
Alle seriøse kandidater kan drives af en Claude Code-agent via MCP + CLI + Terraform. Rangeret efter hvor komplet en agent kan drive hele flowet (opret → deploy → domæne → secrets → skalér) via MCP+IaC:
| # | Platform | Officiel MCP | Terraform/IaC | Samlet |
|---|---|---|---|---|
| 1 | Cloudflare | 13 servere + "Code Mode" (hele API'et via 2 tools) | v5 GA, ~100 % API-dækning | Mest komplet full-stack, mest AI-native |
| 2 | Vercel | MCP m. write (deploy/promote/rollback/env) | Officiel, write-capable | Mest friktionsfri app-deploy; "agentic infra"-strategi |
| 3 | AWS | ~50–62 servere (Cloud Control API + API-MCP = alt) | CDK/SAM + de-facto Terraform-standard | Teknisk mest komplet, men tungest/mest guardrails |
| 4 | Azure | Officiel (40+ tjenester) | Bicep/azd stærk; Terraform-i-azd beta | Meget stærk via CLI/Bicep |
| 5 | Google Cloud | Officiel (gcloud-mcp, Firebase, DB-MCP'er) |
Terraform + Infrastructure Manager | Stærk; MCP-provisionering nyere/fragmenteret |
| — | Supabase | Officiel, fuld backend-livscyklus | Officiel Terraform (alpha) | Fuldt styrbar inden for backend-scope |
| — | Neon | Officiel, fuld DB-livscyklus | Kun community-Terraform | Fuldt styrbar; IaC-forbehold |
| — | Convex | Indbygget (drift/dev-orienteret) | Ingen Terraform | Svageste IaC; stærk AI-kodningsintegration, men provisionerer ikke selve infra |
Konsekvens for os: minimumskravet er opfyldt af alle vores foretrukne modeller. Cloudflare og
Vercel er skarpest på "AI-native"; Cloud Run/Fly dækkes fuldt via gcloud/flyctl + Terraform + MCP.
Azure er faktisk stærk her: Azure MCP Server har egne deploy-værktøjer (target = ContainerApp, IaC =
bicep/terraform), og az containerapp up --source . bygger endda image i skyen uden lokal Docker —
en agent kan drive hele ACA-flowet. Advarsel: gør ikke Convex til det bærende infrastrukturvalg
hvis fuld MCP+IaC-provisionering er et hårdt krav — Convex' MCP er en glimrende udviklings-/driftsledsager,
men Terraform-historien mangler.
10. Sprogvalg (C# / TypeScript / Python) — betyder det noget?
Ja, men mest via økosystem og træningsdata — ikke via "kan agenten skrive sproget". Frontier-modeller er kompetente i alle tre.
- Standard = TypeScript. Hele den AI-native leverance-stack er TS-first (Next.js, Vercel AI SDK, Mastra, MCP/Agent SDK, Supabase/Convex-klienter). TS blev #1 på GitHub i 2025 (drevet af AI-kodning), er i topklasse i agent-træningsdata, og typesikkerhed fanger netop de fejl agenter laver (studier: ~94 % af LLM-kompileringsfejl er type-fejl) — kritisk for kode kunden skal kunne overtage. Ét sprog dækker frontend + backend + agent-orkestrering + DB-klient → færre kontekstskift for både mennesker og agenter. Enorm gevinst for et to-mands-team.
- C#/.NET — når kunden trækker os derhen, ikke som default: Azure/Microsoft-enterprise, eksisterende .NET-kodebaser, Windows-integrationer, regulerede miljøer. Host på Azure Container Apps. Vigtigt: .NET kører i OCI-containere → passer stadig ind i fabriksmodellen og forbliver overdragelig.
- Python — specialistsprog: data/ML/AI-pipelines, embeddings, ETL, scripting (fx det eksisterende CVR-script — bliver i Python). Kør som separate services/jobs ved siden af TS-kernen.
Betyder sproget noget for hosting? Kun blødt, og det bør ikke drive valget: TS/Node kører alle steder; .NET trækker mod Azure; Python-data/ML mod GCP/AWS-services. Containeren neutraliserer det — pak alt i OCI + Terraform + Postgres, så er sprog og hosting frikoblet fra overdragelses-venligheden.
11. Anbefaling
Fastlæg fabriksstandarden: OCI-container + Terraform (IaC) + standard-Postgres, isolerede
konti/projekter pr. kunde fra dag ét, TypeScript som primærsprog.
Vælg host pr. leverance-type:
| Leverance-type | Anbefalet model | Begrundelse |
|---|---|---|
| Billige websites (CVR-produktet, marketing-sites) | M1 — Vercel + Neon, projekt pr. kunde | Bedst DX, hurtigst til demo/salg, indbygget claim-overdragelse; handover mindre kritisk her |
| SaaS/apps der skal skaleres + overdrages | M2 — Cloud Run + Neon (projekt/kunde, EU) eller M3 — Fly.io + Neon (app/kunde) | Container-portabilitet + scale-to-zero + ren, indbygget overdragelse; EU/GDPR |
| Omkostnings-/skala-følsomt, edge | M4 — Cloudflare | Billigst ved skala, mest AI-native; accepter Workers-runtime-specifikke træk |
| Fuld kontrol / kunde vil eje egen server | M5 — Hetzner VPS + Docker | Laveste lock-in, hårdest isolation, EU; lidt mere OS-drift |
| Microsoft-/enterprise-/.NET-kunder | M7 — Azure Container Apps + Neon | Entra/M365-integration, subscription-overdragelse til kundens tenant, EU-compliance; brug Neon som DB, ikke Azures egen |
| Stor enkelt-kunde, hård skala/isolation | M6 — GKE Autopilot (namespace/tenant) | Kun når kompleksiteten er retfærdiggjort; ellers overkill |
Batteriet af default-valg for fabrikken (v1-forslag til ADR):
Next.js (TS) → container → Cloud Run (EU, projekt/kunde) · Neon (Postgres) · Vercel til rene websites ·
MCP-server som standardleverance · GitHub + GitHub Actions · Terraform for alt infra.
Dette matcher den eksisterende strategi ("start hvor farten er, byg portabelt") og CVR-pilottens allerede foreslåede Cloud Run-valg — men tilføjer overdragelses-kravet, som er grunden til at container+Postgres prioriteres over en ren Convex/Vercel-only-binding for de leverancer der skal kunne sælges videre.
Azure — bliver det for dyrt og kompliceret? Ærligt svar: - Prisen: Nej, ikke på compute. ACA Consumption med scale-to-zero er praktisk talt gratis for små idle kunder (~$0, indenfor gratis-grant) — på niveau med Cloud Run. Frygten er kun berettiget på databasen: Azures egen Postgres (Flexible Server) har intet ægte scale-to-zero → ~$15–19/md pr. kunde. Med Neon (nu Azure-native) falder en lille kunde til ~$1–6/md. Den billigste fornuftige Azure-opsætning er altså ACA Consumption + Neon. - Kompleksiteten: Delvist berettiget. Selve ACA er lige så enkelt som Cloud Run (3–4 CLI-kommandoer, gratis TLS, én-kommando-deploy uden lokal Docker). Men Azures tenant/subscription/RBAC-overbygning er reelt tungere end Cloud Run/Fly for et to-mands-team uden dedikeret DevOps — og fejl i tenant-flyt er uigenkaldelige. Det er den primære omkostning, ikke ACA. - Derfor: vælg Azure bevidst, ikke som default — når kunden er Microsoft-/enterprise-forankret, kører .NET, eller har formelle EU-compliance-/data-residency-krav. Til mange bittesmå non-Microsoft-kunder er Cloud Run eller Fly både billigere og enklere at drive.
12. Åbne spørgsmål (afgøres → ADR)
- Én default-host eller to spor? Vercel (websites) + Cloud Run/Fly (apps), eller konsolidér på én?
- Cloud Run vs. Fly.io vs. Azure ACA som container-default? (Fly = enklest + lavest lock-in; Cloud Run = konsolidering + EU + matcher CVR-pilot; Azure ACA = kun hvis Microsoft-/enterprise-kunder vejer tungt.)
- Neon vs. Supabase som standard-Postgres? (Neon billigst/mest portabelt for mange små; Supabase = batteries-included hvis vi vil bruge Auth/Storage.)
- Convex' rolle fremover: intern/AI-realtid kun, eller helt ud af kundeleverancer? (Reviderer
reference-stack.md§4.) - Isolationsniveau pr. kunde: projekt-grænse (billigt) vs. separat konto (dyrere, hårdest) — pr. leverance-type?
- Handover-garanti i kontrakten: ordlyd, tidsfrist, om den prissættes som selvstændig leverance.
Kilder
Priser og kapabiliteter verificeret mod leverandørernes egne sider 2026-07-18; enkelte tal fra sekundære kilder er markeret i teksten. Feltet skifter hurtigt — verificér før endelige beslutninger.
Hosting/compute: - Vercel — pricing · Transferring projects · Claim Deployments - Cloudflare — Workers pricing · Containers GA · D1 · R2 - Google Cloud Run — pricing · Cloud SQL — pricing · GKE — pricing - Fly.io — pricing · Fly Managed Postgres - Hetzner Cloud · Prisjustering 15-06-2026 · IPv4-pris - AWS EKS — pricing · Azure AKS tiers - Azure Container Apps — billing/gratis-grant · ACA environments (gratis) · ACA custom domains + managed cert · Azure Retail Prices API (West Europe, 18-07-2026)
Database: - Neon — pricing · Postgres-kompatibel eksport · Neon Azure Native Integration - Supabase — pricing · Compute and Disk - Azure PostgreSQL Flexible Server — compute/storage · Stop/start server
AI/MCP-styrbarhed: - Cloudflare — MCP-servere · 13 nye MCP-servere · Terraform v5 GA - Vercel MCP · Agentic Infrastructure - AWS — awslabs/mcp · Cloud Control API MCP - Azure MCP Server · GCP — officiel MCP-support - Supabase MCP · Neon MCP · Convex MCP
Overdragelse/lock-in: - AWS — direkte konto-overførsel (nov. 2025) - Google Cloud — projekt-migration - Azure — subscription til anden Entra-tenant · Transfer billing ownership - Cloudflare — flyt domæne mellem konti - Convex — self-hosting (open source, Postgres)
Sprog: - GitHub Octoverse — TypeScript #1 - Mastra (TS agent-framework) · Claude Agent SDK (Python + TS) - .NET på Azure Container Apps
Udarbejdet 2026-07-18 fra parallel webresearch. Beslutning fanges som ADR i adr/ når truffet.