Migrationsguide · Från Vercel
Migrera från Vercel till SIAX
Vercel är byggt för att komma igång snabbt, och det gör det bra. Smärtan kommer senare: pris per seat i teamet, bandbreddsdebitering som är svår att förutse innan månaden är slut, funktionsanrop som räknas styckvis, och en plattform där du varken kan granska hur något är byggt eller flytta det utan att skriva om delar av appen.
Hos oss kör du samma app som en container på App Hosting, med fast månadskostnad och en databas du kan ansluta till med psql. Allt under huven är öppen källkod och all data ligger i EU. Du får däremot inte Vercels globala edge-nät. Det är värt att säga rakt ut: sitter er publik i Sydostasien och ni mäter TTFB i tiotals millisekunder är vi fel val.
Guiden utgår från en Next.js-app eftersom det är den vanligaste. Mönstret är detsamma för Remix, Astro, SvelteKit och Nuxt. Skillnaden ligger i hur mycket av Vercels plattformsfunktioner ni har låtit krypa in i koden.
Tidsåtgång
En halvdag för en app som bara är en app. En till två veckor om ni lutar er på ISR, Edge Middleware, Vercel Blob eller KV.
Stillestånd
Ingen för appen om du kör parallellt under DNS-bytet. Databasflytten kräver ett skrivstopp: minuter för en liten databas, längre om du inte sätter upp logisk replikering.
Så gör du
- 1
Inventera vad ni faktiskt använder av Vercel
Sök igenom koden efter det som bara finns hos Vercel: Edge Middleware, runtime = edge, request.geo, waitUntil, ISR med on-demand-revalidering, Vercel Cron, Blob, KV och Postgres. Skriv ner varje träff. Den listan är hela migrationens svårighetsgrad; resten är rutin. Noll träffar betyder ett par timmars arbete.
- 2
Bygg appen som en container
Sätt output till standalone i next.config och skriv en Dockerfile i två steg: bygg med devDependencies, kör med en slimmad node-alpine-image. Verifiera att appen startar lokalt med samma miljövariabler som i produktion. Kontrollera att sharp följer med om ni använder next/image, annars faller bildoptimeringen tillbaka på obetald CPU vid varje kallstart.
- 3
Ersätt de Vercel-specifika funktionerna
Edge Middleware körs hos oss som vanlig Node-middleware i appen, inte på edge. Geo- och IP-fält från Vercel finns inte och måste ersättas med headers från vår proxy eller en GeoIP-databas ni själva driver. Vercel Cron ersätts med ett schemalagt jobb i CI eller en cron i containern. Blob byts mot vår objektlagring via S3-API, vilket är en riktig kodändring och inte en konfigurationsrad.
- 4
Flytta databasen och lagringen
Provisionera Managed Postgres och kör en pg_dump med efterföljande pg_restore mot den nya instansen. Kontrollera att alla extensions finns innan ni börjar, inte efteråt. För större databaser sätter ni upp logisk replikering, låter den komma ikapp och byter sedan connection string under ett kort skrivstopp. Filer i Vercel Blob kopieras med rclone mot vår S3-endpoint.
- 5
Sätt upp bygg och deploy
Koppla repot till Git och CI och låt en pipeline bygga imagen och deploya vid push till main. Lägg alla miljövariabler i hemlighetshanteringen, aldrig i imagen. Passa på att rotera de nycklar som legat i Vercels projektinställningar, eftersom ni ändå exporterar dem.
- 6
Kör parallellt och stäm av
Låt den nya miljön ligga bakom en staging-subdomän medan Vercel fortsatt tar produktionstrafik. Jämför svarstider, cache-headers, redirects och 404-beteende sida för sida. Kontrollera särskilt att sidor ni trodde var statiska faktiskt renderas statiskt, och att cachen inte blivit tom vid varje deploy.
- 7
Byt DNS och avveckla
Sänk TTL till 60 sekunder ett dygn i förväg, byt sedan A- eller CNAME-posten. Behåll Vercel-projektet i ett par veckor som fallback och för att fånga eventuella hårdkodade vercel.app-URL:er. Först därefter avslutar ni prenumerationen.
Vad som faktiskt är krångligt
- ISR fungerar självhostat, men cachen är per instans. Kör ni fler än en instans får användare olika versioner av samma sida tills ni pekar ut en delad cache-handler i Next.js. Enklaste vägen är en instans till att börja med.
- Edge Middleware blir Node-middleware. Latensprofilen ändras, och allt som byggde på Vercels geo- eller land-fält måste ersättas eller tas bort.
- Förhandsvisningar per commit finns inte färdigt. Ni får prod-, staging- och dev-miljöer och kan bygga branch-deployer i CI, men en unik URL per pull request är något ni får sätta upp själva.
- Vercel KV har ingen motsvarighet hos oss. Behöver ni en nyckel-värde-cache kör ni Redis eller Valkey på en VPS och äger då uppdateringar och backup själva.
- Vårt nät är EU-regionalt, inte globalt. För en nordisk eller europeisk publik är skillnaden marginell. För en global publik med hårda latenskrav är den inte det.
Kostnadsexempel
En liten produktionsapp med staging, en Postgres och 100 GB filer: App Hosting från 99 kr, staging-miljö 49 kr, Managed Postgres från 89 kr och objektlagring 25 kr, alltså cirka 262 kr per månad exklusive moms. Större instanser kostar mer. Motsvarande hos Vercel med tre utvecklare på Pro plus en managed Postgres landar på cirka 1 000 till 1 500 kr per månad innan bandbredds- och funktionsöverdrag, och deras priser ändras löpande.
Vanliga frågor
- Fungerar Next.js fullt ut hos er?
- Ja, i Node-läge med standalone-output. Det som inte följer med är plattformsfunktionerna runtomkring: edge runtime, Vercels geo-headers, Blob, KV och Cron. Appen fungerar, men de anropen måste skrivas om.
- Har ni ett CDN framför appen?
- Vi cachar statiska tillgångar och kan lägga cache framför sidor, men vi har inte hundratals PoP:er världen över. Våra regioner är Helsingfors, Falkenstein och Nürnberg. För nordiska besökare är latensen jämförbar med Vercel; för besökare i Asien eller Sydamerika är den inte det.
- Är ni ISO 27001- eller SOC 2-certifierade?
- Nej. Vi har varken ISO 27001 eller SOC 2. Det vi har är GDPR-efterlevnad, personuppgiftsbiträdesavtal, all data i EU och en stack byggd på öppen källkod som ni kan granska. Kräver ert kundavtal en certifiering är det en verklig blockerare och vi säger hellre det direkt.
- Vad händer om vi vill tillbaka?
- Appen är en container och databasen är vanlig Postgres. Ni tar en dump och kör vidare någon annanstans. Det är den praktiska innebörden av att vi inte bygger egna proprietära primitiver.