Migreringsguide · Fra Vercel
Migrer fra Vercel til SIAX
Vercel er bygget til at komme hurtigt i gang, og det lykkes fint. Smerten kommer senere: pris pr. sæde i teamet, båndbreddeafregning der er svær at forudsige før måneden er omme, funktionskald der tælles enkeltvis, og en platform hvor du hverken kan gennemskue, hvordan noget er bygget, eller flytte det uden at skrive dele af appen om.
Hos os kører du den samme app som en container på App Hosting, med en fast månedspris og en database, du kan koble dig til med psql. Alt under motorhjelmen er open source, og al data ligger i EU. Til gengæld får du ikke Vercels globale edge-netværk. Det er værd at sige lige ud: sidder jeres publikum i Sydøstasien, og I måler TTFB i titals millisekunder, er vi det forkerte valg.
Guiden tager udgangspunkt i en Next.js-app, fordi det er den mest almindelige. Mønsteret er det samme for Remix, Astro, SvelteKit og Nuxt. Forskellen ligger i, hvor meget af Vercels platformsfunktioner I har ladet snige sig ind i koden.
Tidsforbrug
En halv dag for en app, der bare er en app. En til to uger, hvis I læner jer op ad ISR, Edge Middleware, Vercel Blob eller KV.
Nedetid
Ingen for appen, hvis du kører parallelt under DNS-skiftet. Databaseflytningen kræver et skrivestop: minutter for en lille database, længere hvis du ikke sætter logisk replikering op.
Sådan gør du
- 1
Kortlæg hvad I rent faktisk bruger fra Vercel
Gennemsøg koden for det, der kun findes hos Vercel: Edge Middleware, runtime = edge, request.geo, waitUntil, ISR med on-demand-revalidering, Vercel Cron, Blob, KV og Postgres. Skriv hvert fund ned. Den liste er hele migrationens sværhedsgrad; resten er rutine. Nul fund betyder et par timers arbejde.
- 2
Byg appen som en container
Sæt output til standalone i next.config, og skriv en Dockerfile i to trin: byg med devDependencies, kør med et slanket node-alpine-image. Verificér at appen starter lokalt med de samme miljøvariabler som i produktion. Tjek at sharp følger med, hvis I bruger next/image — ellers falder billedoptimeringen tilbage på ubetalt CPU ved hver koldstart.
- 3
Erstat de Vercel-specifikke funktioner
Edge Middleware kører hos os som almindelig Node-middleware i appen, ikke på edge. Geo- og IP-felter fra Vercel findes ikke og skal erstattes med headers fra vores proxy eller en GeoIP-database, I selv drifter. Vercel Cron erstattes med et planlagt job i CI eller en cron i containeren. Blob udskiftes med vores objektlagring via S3-API'et, hvilket er en reel kodeændring og ikke bare en konfigurationslinje.
- 4
Flyt databasen og lagringen
Opret Managed Postgres, og kør en pg_dump med efterfølgende pg_restore mod den nye instans. Tjek at alle extensions findes, før I går i gang — ikke bagefter. Til større databaser sætter I logisk replikering op, lader den komme ajour og skifter derefter connection string under et kort skrivestop. Filer i Vercel Blob kopieres med rclone mod vores S3-endpoint.
- 5
Sæt build og deploy op
Kobl repoet til Git og CI, og lad en pipeline bygge imagen og deploye ved push til main. Læg alle miljøvariabler i hemmelighedshåndteringen, aldrig i imagen. Husk at rotere de nøgler, der har ligget i Vercels projektindstillinger, når I alligevel eksporterer dem.
- 6
Kør parallelt og stem af
Lad det nye miljø ligge bag en staging-subdomæne, mens Vercel fortsat tager produktionstrafikken. Sammenlign svartider, cache-headers, redirects og 404-adfærd side for side. Tjek især at sider, I troede var statiske, faktisk bliver renderet statisk, og at cachen ikke bliver tømt ved hver deploy.
- 7
Skift DNS og udfas
Sæt TTL ned til 60 sekunder et døgn i forvejen, og skift derefter A- eller CNAME-posten. Behold Vercel-projektet et par uger som fallback og for at fange eventuelle hårdkodede vercel.app-URL'er. Først derefter opsiger I abonnementet.
Hvad der faktisk er besværligt
- ISR fungerer selvhostet, men cachen er pr. instans. Kører I mere end én instans, får brugerne forskellige versioner af samme side, indtil I peger på en delt cache-handler i Next.js. Den enkleste vej er én instans, indtil videre.
- Edge Middleware bliver til Node-middleware. Latensprofilen ændrer sig, og alt der byggede på Vercels geo- eller landefelter, skal erstattes eller fjernes.
- Preview pr. commit findes ikke som færdig funktion. I får prod-, staging- og dev-miljøer og kan bygge branch-deploys i CI, men en unik URL pr. pull request er noget, I selv skal sætte op.
- Vercel KV har ingen pendant hos os. Har I brug for en nøgle-værdi-cache, kører I Redis eller Valkey på en VPS og ejer så selv opdateringer og backup.
- Vores netværk er EU-regionalt, ikke globalt. For et nordisk eller europæisk publikum er forskellen marginal. For et globalt publikum med hårde latenskrav er den ikke.
Omkostningseksempel
En lille produktionsapp med staging, en Postgres og 100 GB filer: App Hosting fra 99 kr, staging-miljø 49 kr, Managed Postgres fra 89 kr og objektlagring 25 kr, altså cirka 262 kr om måneden ekskl. moms. Større instanser koster mere. Det tilsvarende hos Vercel med tre udviklere på Pro plus en managed Postgres lander på cirka 1.000 til 1.500 kr om måneden, før båndbredde- og funktionsoverforbrug, og deres priser ændrer sig løbende.
Ofte stillede spørgsmål
- Fungerer Next.js fuldt ud hos jer?
- Ja, i Node-tilstand med standalone-output. Det, der ikke følger med, er platformsfunktionerne omkring den: edge runtime, Vercels geo-headers, Blob, KV og Cron. Appen fungerer, men de kald skal skrives om.
- Har I et CDN foran appen?
- Vi cacher statiske assets og kan lægge cache foran sider, men vi har ikke hundredvis af PoP'er verden over. Vores regioner er Helsinki, Falkenstein og Nürnberg. For nordiske besøgende er latensen sammenlignelig med Vercel; for besøgende i Asien eller Sydamerika er den ikke.
- Er I ISO 27001- eller SOC 2-certificerede?
- Nej. Vi har hverken ISO 27001 eller SOC 2. Det, vi har, er GDPR-compliance, databehandleraftale, al data i EU og en stack bygget på open source, som I kan gennemgå. Kræver jeres kundeaftale en certificering, er det en reel blokering, og det siger vi hellere lige ud.
- Hvad sker der, hvis vi vil tilbage?
- Appen er en container, og databasen er almindelig Postgres. I tager en dump og kører videre et andet sted. Det er den praktiske konsekvens af, at vi ikke bygger vores egne proprietære primitiver.