Migreringsguide · Fra Vercel
Migrer fra Vercel til SIAX
Vercel er bygget for å komme raskt i gang, og det gjør det bra. Smerten kommer senere: pris per plass i teamet, båndbreddefakturering som er vanskelig å forutse før måneden er over, funksjonskall som telles stykkvis, og en plattform der du verken kan inspisere hvordan noe er bygget eller flytte det uten å skrive om deler av appen.
Hos oss kjører du samme app som en container på App Hosting, med fast månedskostnad og en database du kan koble til med psql. Alt under panseret er åpen kildekode, og all data ligger i EU. Det du derimot ikke får, er Vercels globale edge-nett. Det er verdt å si rett ut: sitter publikummet deres i Sørøst-Asia og dere måler TTFB i titalls millisekunder, er vi feil valg.
Guiden tar utgangspunkt i en Next.js-app fordi det er den vanligste. Mønsteret er det samme for Remix, Astro, SvelteKit og Nuxt. Forskjellen ligger i hvor mye av Vercels plattformfunksjoner dere har latt krype inn i koden.
Tidsbruk
En halv dag for en app som bare er en app. En til to uker om dere støtter dere på ISR, Edge Middleware, Vercel Blob eller KV.
Nedetid
Ingen for appen dersom du kjører parallelt under DNS-byttet. Databaseflyttingen krever en skrivestopp: minutter for en liten database, lenger om du ikke setter opp logisk replikering.
Slik gjør du det
- 1
Kartlegg hva dere faktisk bruker av Vercel
Søk gjennom koden etter det som bare finnes hos Vercel: Edge Middleware, runtime = edge, request.geo, waitUntil, ISR med on-demand-revalidering, Vercel Cron, Blob, KV og Postgres. Skriv ned hvert treff. Den listen utgjør hele vanskelighetsgraden i migreringen; resten er rutine. Null treff betyr et par timers arbeid.
- 2
Bygg appen som en container
Sett output til standalone i next.config og skriv en Dockerfile i to trinn: bygg med devDependencies, kjør med et slankt node-alpine-image. Verifiser at appen starter lokalt med de samme miljøvariablene som i produksjon. Kontroller at sharp følger med hvis dere bruker next/image, ellers faller bildeoptimaliseringen tilbake på ubetalt CPU ved hver kaldstart.
- 3
Erstatt de Vercel-spesifikke funksjonene
Edge Middleware kjører hos oss som vanlig Node-middleware i appen, ikke på edge. Geo- og IP-felt fra Vercel finnes ikke og må erstattes med headere fra vår proxy eller en GeoIP-database dere selv drifter. Vercel Cron erstattes med en skedulert jobb i CI eller en cron i containeren. Blob byttes mot vår objektlagring via S3-API, noe som er en reell kodeendring og ikke bare en konfigurasjonslinje.
- 4
Flytt databasen og lagringen
Provisjoner Managed Postgres og kjør en pg_dump etterfulgt av pg_restore mot den nye instansen. Kontroller at alle extensions finnes før dere starter, ikke etterpå. For større databaser setter dere opp logisk replikering, lar den ta igjen, og bytter deretter connection string under en kort skrivestopp. Filer i Vercel Blob kopieres med rclone mot vår S3-endpoint.
- 5
Sett opp bygg og deploy
Koble repoet til Git og CI, og la en pipeline bygge imaget og deploye ved push til main. Legg alle miljøvariabler i hemmelighetshåndteringen, aldri i imaget. Sørg for å rotere nøklene som har ligget i Vercels prosjektinnstillinger, siden dere uansett eksporterer dem.
- 6
Kjør parallelt og kontroller
La det nye miljøet ligge bak en staging-subdomene mens Vercel fortsatt tar imot produksjonstrafikk. Sammenlign svartider, cache-headere, redirects og 404-oppførsel side for side. Kontroller spesielt at sider dere trodde var statiske, faktisk rendres statisk, og at cachen ikke blir tom ved hver deploy.
- 7
Bytt DNS og avvikle
Senk TTL til 60 sekunder ett døgn i forveien, bytt deretter A- eller CNAME-posten. Behold Vercel-prosjektet i et par uker som fallback og for å fange opp eventuelle hardkodede vercel.app-URL-er. Først deretter sier dere opp abonnementet.
Hva som faktisk er vrient
- ISR fungerer selvhostet, men cachen er per instans. Kjører dere flere enn én instans, får brukerne ulike versjoner av samme side inntil dere peker ut en delt cache-handler i Next.js. Den enkleste veien er én instans til å begynne med.
- Edge Middleware blir Node-middleware. Latensprofilen endres, og alt som bygde på Vercels geo- eller landfelt, må erstattes eller fjernes.
- Forhåndsvisninger per commit finnes ikke ferdig. Dere får prod-, staging- og dev-miljøer og kan bygge branch-deployer i CI, men en unik URL per pull request er noe dere må sette opp selv.
- Vercel KV har ingen tilsvarende tjeneste hos oss. Trenger dere en nøkkel-verdi-cache, kjører dere Redis eller Valkey på en VPS og eier da oppdateringer og backup selv.
- Vårt nett er EU-regionalt, ikke globalt. For et nordisk eller europeisk publikum er forskjellen marginal. For et globalt publikum med harde latenskrav er den ikke det.
Kostnadseksempel
En liten produksjonsapp 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å rundt 262 kr per måned eksklusive mva. Større instanser koster mer. Tilsvarende hos Vercel med tre utviklere på Pro pluss en managed Postgres lander på rundt 1 000 til 1 500 kr per måned før båndbredde- og funksjonsoverforbruk, og prisene deres endres fortløpende.
Ofte stilte spørsmål
- Fungerer Next.js fullt ut hos dere?
- Ja, i Node-modus med standalone-output. Det som ikke følger med, er plattformfunksjonene rundt: edge runtime, Vercels geo-headere, Blob, KV og Cron. Appen fungerer, men disse kallene må skrives om.
- Har dere et CDN foran appen?
- Vi cacher statiske ressurser og kan legge cache foran sider, men vi har ikke hundrevis av PoP-er verden over. Våre regioner er Helsingfors, Falkenstein og Nürnberg. For nordiske besøkende er latensen sammenlignbar med Vercel; for besøkende i Asia eller Sør-Amerika er den ikke det.
- Er dere ISO 27001- eller SOC 2-sertifisert?
- Nei. Vi har verken ISO 27001 eller SOC 2. Det vi har, er GDPR-etterlevelse, databehandleravtale, all data i EU og en stack bygget på åpen kildekode som dere kan inspisere. Krever kundeavtalen deres en sertifisering, er det en reell blokkerer, og vi sier heller det rett ut.
- Hva skjer hvis vi vil tilbake?
- Appen er en container, og databasen er vanlig Postgres. Dere tar en dump og kjører videre et annet sted. Det er den praktiske betydningen av at vi ikke bygger egne proprietære primitiver.