Opdatering af framework og pakker: hvad det koster at lade være

Opdatering af framework og pakker er det der holder din webapp sikker og nem at bygge videre på: du lukker kendte sikkerhedshuller, bliver på versioner der stadig får rettelser, og gør næste opdatering lille. Lader du være, forsvinder regningen ikke. Den vokser for hver måned, og den kommer typisk på et tidspunkt du ikke selv har valgt.

Jeg skriver det her som freelanceudvikler der vedligeholder Laravel- og JavaScript-projekter, så jeg har en interesse i at du får det gjort. Men det meste nedenfor kan en intern udvikler bruge direkte.

Den korte version

Der findes fire slags opdateringer, og de har vidt forskellig risiko. Tabellen viser hvordan jeg typisk griber dem an i en Laravel-app.

Beslutningsreglen er enkel. Patch og minor kører du løbende. En ny major-version tager du inden for et halvt år efter udgivelsen, og du lader aldrig en version løbe ud af sikkerhedssupport. Opdateringer er kun én del af at holde en webapp kørende, og resten finder du i den samlede guide til drift og vedligehold af webapps.

Hvad du egentlig opdaterer

En moderne webapp er ikke ét program. Den er din egen kode oven på flere lag af andres kode:

• Frameworket, fx Laravel eller Next.js, der giver dig login, databaseadgang, routing og meget andet.
• Pakker (også kaldet afhængigheder), som er færdige byggeklodser til betaling, PDF, billedbehandling, e-mail og lignende. I PHP hentes de med Composer, i JavaScript med npm.
• Sproget, altså PHP eller Node.js, som koden kører i.
• Serveren: styresystem, database og webserver.

Det mange overser er at pakker har deres egne pakker. Tæller du de indirekte med, trækker et nyt Laravel-projekt et sted omkring hundrede pakker ind, og frontenden trækker ofte endnu flere npm-pakker ind. Hver af dem kan få en sikkerhedsrettelse, og hver af dem kan blive opgivet af sin udvikler.

Versionsnumre følger som regel semantisk versionering: tre tal, fx 13.4.2. Det sidste tal (patch) dækker fejlrettelser. Det midterste (minor) dækker nye funktioner uden at eksisterende kode går i stykker. Det første (major) må gerne ændre ting, så din kode skal tilpasses. Derfor kræver major-opgraderinger planlægning. Resten kan køre løbende.

Fire grunde til at opdateringer ikke kan vente

Sikkerhedshuller bliver offentlige

Når en sårbarhed i en pakke bliver fundet og rettet, bliver den samtidig beskrevet offentligt. Det er godt for dem der opdaterer, og en angrebsopskrift mod alle der ikke gør. Fra det øjeblik er det ikke længere en hemmelighed hvordan man angriber en app der kører den gamle version.

OWASP, der står bag den mest brugte liste over sikkerhedsrisici i webapps, har i 2025-udgaven samlet sårbare, forældede og ikke-understøttede komponenter under A03: Software Supply Chain Failures. I OWASP's egen undersøgelse blandt fagfolk satte præcis halvdelen af deltagerne den på førstepladsen.

Behandler appen persondata, er det også et GDPR-spørgsmål. Forordningen kræver sikkerhedsforanstaltninger der passer til risikoen og det aktuelle tekniske niveau (artikel 32), og efter min vurdering er det svært at forsvare at køre software der ikke længere får sikkerhedsrettelser. Er du i tvivl om jeres juridiske forpligtelser, så spørg en rådgiver.

Support har en udløbsdato

Laravel giver hver major-version fejlrettelser i 18 måneder og sikkerhedsrettelser i 2 år, ifølge Laravels egen supportpolitik. Laravel 11 mistede sine sikkerhedsrettelser i marts 2026, og Laravel 12 gør det i februar 2027. PHP følger en lignende cyklus med 2 års aktiv support og 2 års sikkerhedssupport, og PHP 8.2 har sikkerhedssupport til 31. december 2026.

Når supporten udløber, holder appen ikke op med at virke. Den holder bare op med at blive lappet. Næste gang der bliver fundet et hul, findes der ingen rettelse til din version. Hvilke versioner der er dækket lige nu, gennemgår jeg i oversigten over Laravel-versioner og support.

Gamle versioner låser resten fast

Opdateringer hænger sammen i en kæde. Laravel 13 kræver mindst PHP 8.3. En ny version af en betalingspakke kræver måske en nyere Laravel. Og din hostingudbyder holder på et tidspunkt op med at tilbyde den gamle PHP-version. Står du stille ét sted, kan du ikke flytte dig de andre steder, heller ikke når en betalingsudbyder eller et API udfaser den integration du bruger.

Viden og folk forsvinder

Dokumentation, svar på nettet og pakker til gamle versioner bliver sværere at finde år for år. Det er min vurdering at mange udviklere enten siger nej til meget forældede projekter eller lægger usikkerheden ind i prisen. Det er forståeligt, for på et forældet system tager selv små ændringer længere tid.

Små løbende opdateringer eller store spring

Her ligger den største forskel i pris. Laravel skriver selv at de stræber efter at en opgradering til en ny major-version kan klares på en dag eller mindre. Det holder typisk når du går én version ad gangen og appen har tests. Det holder ikke når du skal fra Laravel 8 til 13 i ét hug.

Ved et stort spring arbejder du dig gennem fem opgraderingsguides i træk. Samtidig skal PHP flere versioner op, nogle pakker er opgivet af deres udviklere, og fejlene fra de forskellige trin blander sig. Det er ikke fem gange så meget arbejde som én opgradering. Det er ofte mere fordi det er svært at se hvilket trin der fik hvad til at gå i stykker.

Min tommelfingerregel er hellere lidt hver måned end meget hvert tredje år. Kører appen allerede på en meget gammel version, kan det være billigere at modernisere end at opgradere trin for trin. Det skriver jeg mere om i tegnene på at et gammelt PHP-system skal moderniseres.

Hvad det koster at lade være

Prisen for at vente dukker sjældent op på en faktura med det samme. Den kommer typisk i en af disse former:

• En tvungen opgradering under tidspres fordi hostingudbyderen fjerner den gamle PHP-version eller en integration holder op med at virke. Du betaler for det samme arbejde, bare med kortere frist og mindre plads til at teste.
• Et sikkerhedsbrud. Ud over nedetid og oprydning skal et brud på persondatasikkerheden som udgangspunkt anmeldes til Datatilsynet inden for 72 timer.
• Langsommere udvikling. Nye funktioner tager længere tid når udvikleren skal arbejde uden om gamle begrænsninger eller ikke kan bruge nyere pakker.
• En større regning senere. Det spring du udskyder, bliver ikke mindre. Det vokser med hver major-version der udkommer.

Forældede afhængigheder er en klassisk form for teknisk gæld der bliver dyrere jo længere du venter. Og hvis det værste sker, og appen går ned efter en mislykket opdatering, har jeg skrevet om hvad du gør når din hjemmeside eller app er nede.

Sådan opdaterer du sikkert i 6 trin

Rækkefølgen er den samme uanset om det er en lille patch eller en stor opgradering. Forskellen er hvor meget tid hvert trin tager.

1. Lav et overblik. Find ud af hvilken version af framework, PHP og Node appen kører. Kommandoerne composer outdated og npm outdated viser hvilke pakker der er bagud, og npm audit og Composers audit-kommando viser hvilke der har kendte sikkerhedshuller. Composer viser også pakker der er opgivet af deres udvikler.
2. Prioritér. Sikkerhedsrettelser først, derefter versioner der er tæt på at miste support, og til sidst resten.
3. Sørg for et sikkerhedsnet. Tag en backup, og hav et testmiljø (staging) der ligner produktion. Har appen ingen automatiske tests, så skriv i det mindste nogle få der dækker login, betaling og de forløb kunderne bruger mest.
4. Opdatér i små bidder. Én major-version ad gangen, og følg den officielle opgraderingsguide. Værktøjer som Laravel Shift kan klare en del af det mekaniske arbejde, men nogen skal stadig gennemgå og teste resultatet.
5. Test og udgiv. Kør testene på staging, klik de vigtigste forløb igennem, og udgiv på et roligt tidspunkt med en plan for at rulle tilbage hvis noget går galt.
6. Gør det til en rytme. Tag sikkerhedsrettelser så snart de udkommer, sæt de øvrige patch- og minor-opdateringer i kalenderen hver måned, og planlæg en major-opgradering en gang om året. Dependabot eller Renovate kan automatisk oprette forslag til opdateringer så ingen skal huske det.

Hvornår du ikke behøver at opdatere (eller hyre nogen til det)

Opdateringer er vigtige, men de er ikke lige vigtige alle steder. Her er de situationer hvor jeg selv ville bruge pengene anderledes:

• Er det en statisk hjemmeside uden backend, login eller formularer, er risikoen meget lavere. Et par opdateringer om året er som regel nok.
• Skal systemet lukkes inden for få måneder, er en opgradering sjældent pengene værd. Begræns i stedet adgangen og hold øje med det til det er slukket.
• Har du en intern udvikler med tid og erfaring, kan vedkommende klare det med tjeklisten ovenfor. Så har du ikke brug for en freelancer.
• Er systemet bygget i noget helt andet end PHP, Laravel eller JavaScript, er jeg ikke den rigtige at spørge. Find en specialist i den teknologi.
• Er appen så gammel at det i praksis kræver en ombygning, er det et andet projekt end en opdatering, og det skal vurderes for sig.

Næste skridt

Start med at finde ud af hvilken version appen kører og hvornår supporten udløber. Har du allerede en udvikler, så spørg om der er en fast rytme for opdateringer og om den står i jeres aftale. Jeg har lavet en tjekliste over hvad en serviceaftale med en udvikler bør dække så opdateringer ikke falder mellem to stole.

Vil du have hjælp til selve arbejdet, kan du se hvordan jeg arbejder med Laravel-udvikling, opgraderinger og videreudvikling. Du får direkte kontakt med mig, der skriver koden, og svar inden for én hverdag.

Ofte stillede spørgsmål

Kan jeg slå automatiske opdateringer til og glemme det?+

Kun for de mindste opdateringer, og kun hvis appen har tests der kører automatisk. Patch-opdateringer kan med fordel flettes ind automatisk når testene er grønne. Minor-opdateringer bør en udvikler kigge på, og major-opdateringer skal altid planlægges og testes manuelt. Automatik uden tests flytter bare risikoen fra en app der er for gammel til en app der gik i stykker i nat.

Hvad gør man hvis en pakke ikke længere bliver vedligeholdt?+

Så skal den erstattes, fjernes eller i sjældne tilfælde overtages. Composer markerer pakker der er opgivet, og ofte peger den oprindelige udvikler selv på et alternativ. Er pakken lille, er det nogle gange hurtigere at skrive funktionen selv. Det vigtige er at opdage det tidligt, for en opgivet pakke er tit den der blokerer næste opgradering.

Kan man springe en Laravel-version over?+

Ja, i den forstand at du kan gå fra Laravel 11 til 13 i ét projekt. Men ændringerne fra Laravel 12 skal stadig laves, så du følger opgraderingsguiderne i rækkefølge. Jeg foretrækker at udgive hvert trin for sig så det er tydeligt hvilket trin der skabte en eventuel fejl. Tjek også PHP-kravet først, for Laravel 13 kræver mindst PHP 8.3.

Bliver min app hurtigere af at blive opdateret?+

Nogle gange, men det er sjældent den bedste grund til at gøre det. Nye PHP-versioner har ofte givet forbedringer i ydeevne, og nyere pakker kan være mere effektive. En langsom app skyldes dog typisk databaseforespørgsler, manglende cache eller hosting, ikke frameworkets version. Opdatér for sikkerhedens skyld, og se hastighed som en mulig bonus.