Migrationsguide · Från Heroku
Migrera från Heroku till SIAX
Heroku gjorde deploys enkla innan någon annan gjorde det, och delar av den enkelheten är fortfarande svår att slå. Det som får team att flytta är sällan tekniken utan ekonomin: priset per dyno, add-ons som var för sig ser billiga ut och tillsammans blir en betydande post, och en plattform som utvecklats långsamt de senaste åren.
Hos oss kör ni webbprocessen och bakgrundsprocesserna som containrar på App Hosting, databasen som Managed Postgres och det som saknar managed motsvarighet på en VPS. Månadskostnaden blir förutsägbar och ni får rootåtkomst där ni behöver den.
Det krångliga är inte appen utan add-on-ekosystemet. Heroku har gjort det enkelt att klicka in en tjänst, och de flesta team har fler add-ons än de minns. Varje sådan måste ersättas för sig, och några har ingen självklar motsvarighet. Räkna med att den delen tar mer tid än själva applikationsflytten.
Tidsåtgång
En dag för en app med en webbprocess och en Postgres. En till två veckor om ni har fem eller fler add-ons, bakgrundsjobb och schemalagda körningar.
Stillestånd
Appen kan flyttas utan avbrott om ni kör parallellt. Databasen kräver ett skrivfönster: några minuter med dump och restore på en liten databas, längre för stora. Med logisk replikering kommer ni ner i sekunder.
Så gör du
- 1
Inventera dynos, add-ons och config vars
Kör heroku ps, heroku addons och heroku config för varje app och spara utdata. Notera dynotyp och antal per processtyp, samt vilken plan varje add-on ligger på. Den här listan är kravspecifikationen för den nya miljön, och den är nästan alltid längre än teamet gissar.
- 2
Ersätt buildpacken med en Dockerfile
Heroku gör mycket åt er osynligt: installerar beroenden, kompilerar assets, sätter PORT och startar det som står i Procfile. Allt det ska stå explicit i er Dockerfile. Bind till den PORT som miljön anger i stället för en hårdkodad port. Alternativt kan ni köra Cloud Native Buildpacks med pack CLI om ni vill behålla buildpack-modellen ett tag till.
- 3
Ersätt varje add-on för sig
Gå igenom listan post för post. Heroku Postgres blir Managed Postgres. Heroku Data for Redis blir Redis eller Valkey på en VPS, som ni själva uppdaterar och säkerhetskopierar. Papertrail och liknande logg- och uptidstjänster ersätts av vår övervakning för kontroller och en loggmottagare ni väljer. Utgående e-post via SendGrid byts mot vår e-posttjänst eller en extern SMTP-leverantör. Add-ons utan motsvarighet måste antingen behållas som fristående prenumeration eller driftas av er.
- 4
Migrera Postgres
Kontrollera först vilka extensions ni faktiskt använder, inte vilka som råkar vara installerade. Ta en pg_dump i custom-format och kör pg_restore mot den nya instansen, och testa hela vägen mot en kopia innan ni rör produktion. För databaser över några tiotals gigabyte sätter ni upp logisk replikering och byter connection string när replikan är ikapp. Tänk på att Herokus DATABASE_URL kan roteras och att sslmode-inställningen ofta skiljer sig.
- 5
Flytta worker-processer och schemalagda jobb
Varje processtyp i Procfile blir en egen körning hos oss. Worker-dynos blir separata containrar mot samma kö. Heroku Scheduler ersätts av cron i containern eller ett schemalagt CI-jobb. Engångskörningar som ni gjorde med heroku run behöver en ny rutin, exempelvis ett skal i den körande containern eller ett manuellt triggat jobb.
- 6
Sätt upp deploy och hemligheter
Koppla repot till Git och CI så att push till main bygger imagen och deployar. Flytta alla config vars till hemlighetshanteringen och rotera dem i samband med flytten, eftersom de nu passerat en export. Verifiera att appen startar med exakt den uppsättning variabler ni tänkt köra i produktion, inte en delmängd.
- 7
Kör parallellt, byt DNS och avveckla
Låt Heroku-appen fortsätta ta produktionstrafik medan den nya miljön ligger på en staging-adress. Jämför loggar, felfrekvens och svarstider under minst ett dygn med verklig trafik. Sänk sedan TTL, byt DNS och behåll Heroku igång ytterligare någon vecka innan ni skalar ner dynos till noll och avslutar add-ons.
Vad som faktiskt är krångligt
- Add-ons ersätts inte med en knapp. Varje tjänst måste utvärderas, ersättas och testas för sig, och några har ingen bra motsvarighet alls. Detta är regelmässigt den största posten i tidsplanen.
- Vi har ingen managed Redis som produkt. Behöver ni Redis eller Valkey kör ni den på en VPS från 59 kr per månad, med uppdateringar, minnesgränser och backup på ert ansvar.
- Buildpack-magin är osynlig tills den försvinner. Automatisk assetkompilering, PORT-bindning och injicerade miljövariabler slutar hända av sig själva och måste skrivas ut i Dockerfilen.
- Heroku startade om era dynos dagligen. Kod med långsamma minnesläckor kan ha maskerats av den cykeln och blir synlig först när containern får leva i veckor.
- Review apps och pipelines finns inte som färdig funktion. Ni kan bygga motsvarande med branch-deployer i CI, men det är arbete ni behöver planera in, inte en inställning.
Kostnadsexempel
En app med en webbprocess, en worker, en Postgres, Redis och daglig backup: App Hosting från 99 kr för webben och 99 kr för workern, Managed Postgres från 89 kr, en VPS för Redis från 59 kr och backup 19 kr för 100 GB, alltså cirka 365 kr per månad exklusive moms. Motsvarande hos Heroku med två Standard-dynos, Postgres Standard-0 och en Redis-plan ligger på cirka 1 200 till 1 400 kr per månad till listpris, och priserna ändras löpande.
Vanliga frågor
- Kan vi behålla våra buildpacks?
- Inte direkt, vi kör containrar. Antingen skriver ni en Dockerfile, vilket vi rekommenderar på sikt, eller så bygger ni en OCI-image från era befintliga buildpacks med pack CLI. Det andra alternativet kortar migrationen men skjuter arbetet framför sig.
- Har ni managed Redis?
- Nej. Redis och Valkey får köras på en VPS eller dedikerad server. Det blir billigare än en Heroku-plan men ni tar över driften: uppdateringar, minnespolicy, persistens och backup.
- Följer våra Postgres-extensions med?
- De vanliga gör det, inklusive pg_stat_statements, pgcrypto, uuid-ossp och PostGIS. Ovanliga eller Heroku-specifika tillägg måste verifieras innan ni planerar cutover, inte efter. Skicka listan från din databas så svarar vi konkret.
- Vad gör vi med Heroku Connect eller andra add-ons som saknar motsvarighet?
- Antingen behåller ni tjänsten som fristående prenumeration hos leverantören, eller så ersätter ni funktionen med något ni själva driver. Vi låtsas inte att allt går att flytta rakt av, och den bedömningen bör göras innan ni bestämmer flyttdatum.