Hvorfor Laravel? 13 grunde til at det er mit standardvalg til webapps
Hvorfor Laravel? 13 konkrete grunde til at jeg bygger webapps i Laravel, fra køer og betaling til værktøjer, plus de ulemper du bør kende.

Freelance full-stack udvikler
- Udgivet
- Læsetid
- 14 min.
Indhold i indlægget9
Hvorfor Laravel? Kort fortalt fordi flere af de timer du betaler for, går til det der er særligt ved din løsning: login, database, baggrundsjob, abonnementsbetaling og test er løst på forhånd. Samtidig følger koden konventioner som andre Laravel-udviklere kender, så du ikke er låst til den der skrev den. Derfor er det mit standardvalg til webapps, kundeportaler og SaaS-produkter.
Jeg er selv Laravel-udvikler, så læs med det forbehold. Sidst i indlægget gennemgår jeg ulemperne og de projekter hvor jeg vælger noget andet.
Den korte version
| # | Grund | Hvad det betyder for dig |
|---|---|---|
| 1 | Det meste er med fra start | Færre timer på standardfunktioner |
| 2 | Eloquent og migrationer | Databasen kan ændres og genskabes sikkert |
| 3 | Faste konventioner | En anden udvikler kan overtage projektet |
| 4 | Frit valg af frontend | React, Vue eller Livewire efter behov |
| 5 | Køer og Horizon | Tunge opgaver får ikke siden til at hænge |
| 6 | Planlagte opgaver i koden | Faste job er synlige og versionsstyrede |
| 7 | Cashier til abonnementer | Stripe- eller Paddle-betaling uden at starte fra nul |
| 8 | Officielle pakker | Login med Google, API'er og realtid er løst |
| 9 | Spatie og Filament | Færdige pakker til rettigheder, filer og administration |
| 10 | Hosting uden låsning | Appen kan køre hvor du vil, også i EU |
| 11 | Tinkerwell og Ray | Hurtigere fejlfinding og færre timer på regningen |
| 12 | Test er indbygget | Ændringer kan laves uden at gætte |
| 13 | Fast udgivelsesplan | Du ved hvornår din version mister sikkerhedsopdateringer |
Min tommelfingerregel: skal din løsning have brugere der logger ind, data der skal gemmes, og forretningsregler der skal overholdes, er Laravel et sikkert førstevalg. Er det mest indhold der skal vises, er det sjældent det rigtige værktøj.
Vil du se hvor valget af framework passer ind i et helt forløb, så start med min gennemgang af et udviklingsprojekt fra idé til drift. Står du mellem Laravel og et JavaScript-framework, har jeg skrevet en separat sammenligning af Laravel og Next.js.
Fundamentet: det der gør hvert projekt hurtigere
1. Det meste er med fra start
Laravel kaldes ofte et "batteries included"-framework, og det er den vigtigste grund til at jeg vælger det. Login, nulstilling af adgangskode, validering af formularer, mails, notifikationer, filupload, cache og flere sprog er en del af frameworket eller de officielle startpakker. Jeg skal ikke finde og sætte ti forskellige biblioteker sammen før jeg kan begynde på det der er særligt ved din forretning.
For dig betyder det at budgettet går til din bookinglogik, din prisberegning eller dit kundeflow og ikke til at genopfinde login. En udvikler der skal bygge de samme ting selv, bruger flere timer på samme resultat, og de timer betaler du for.
2. Eloquent og migrationer holder styr på databasen
Eloquent er Laravels måde at arbejde med databasen på. I stedet for at skrive SQL i hånden beskriver jeg sammenhængene i koden: en kunde har mange ordrer, og en ordre har mange linjer. Det gør koden kortere og lettere at læse for den næste udvikler.
Migrationer er den anden halvdel. Hver ændring af databasen, fx en ny kolonne eller tabel, er en lille fil i koden. Testmiljø, produktion og en ny udviklers computer kan derfor altid bringes op på præcis samme struktur med én kommando. Ingen skal huske hvilke ændringer der blev lavet i hånden på serveren for et halvt år siden. Til at kigge i selve dataene bruger jeg TablePlus, men strukturen bor altid i koden.
3. Konventioner gør koden til at overtage
Laravel har faste svar på hvor tingene ligger: controllere ét sted, modeller et andet, ruter i deres egen fil og mails i deres egen mappe. Det lyder kedeligt, men for dig som kunde er det en af de vigtigste grunde. En anden Laravel-udvikler kan åbne projektet og hurtigt finde rundt fordi strukturen ligner den vedkommende kender fra andre projekter.
Det mindsker risikoen ved at bruge en freelancer. Hvis jeg en dag ikke er der, står du ikke med et hjemmebygget system som kun én person forstår. Dokumentationen til Laravel er også usædvanlig grundig, så en ny udvikler kan slå op hvordan tingene virker i stedet for at gætte.
4. Frit valg af frontend
Laravel låser dig ikke til én måde at bygge brugerfladen på. De officielle startpakker findes med React, Vue og Svelte via Inertia og med Livewire, alle med login, registrering og brugerindstillinger klar fra start. Jeg arbejder selv med React, så til apps med mange interaktive skærme kan jeg bruge React til brugerfladen og Laravel bagved i ét samlet projekt.
Er brugerfladen enklere, fx et internt værktøj, er Livewire ofte hurtigere at bygge med fordi det meste af logikken kan blive på serveren.
Det tunge arbejde: baggrundsjob, faste opgaver og betaling
5. Køer og Horizon tager det tunge arbejde i baggrunden
Næsten alle webapps har opgaver der tager tid: at sende 500 mails, lave PDF-fakturaer, importere en stor CSV-fil eller synkronisere med et regnskabssystem. Gør du det mens brugeren venter, hænger siden. Med Laravels køer bliver opgaven lagt til side og udført i baggrunden mens brugeren får svar med det samme.
Køerne kan køre på databasen, Redis eller Amazon SQS uden at koden skal skrives om. Fejler et job, fx fordi et eksternt API er nede, kan det automatisk prøves igen et antal gange med pause imellem. Horizon giver et overblik over køer der kører på Redis så jeg kan se hvad der venter, hvad der fejlede, og hvor lang tid tingene tager. For dig betyder det færre mystiske fejl hvor mailen "bare aldrig kom".
6. Planlagte opgaver ligger i koden
Mange systemer har ting der skal ske på faste tidspunkter: en rapport hver mandag, en påmindelse dagen før en booking eller oprydning i gamle data hver nat. Traditionelt bliver de sat op som cron-job (planlagte kommandoer) direkte på serveren hvor ingen kan se dem, og hvor de forsvinder hvis serveren bliver skiftet ud.
Laravels scheduler flytter planen ind i koden. Serveren skal kun have én enkelt linje, og resten står i projektet hvor det er versionsstyret og kan læses af den næste udvikler. Jeg kan også sikre at et job ikke starter igen før det forrige er færdigt, og at det kun kører på én server når appen vokser til flere.
7. Cashier gør abonnementsbetaling til et løst problem
Skal din platform tage betaling for abonnementer, er Laravel Cashier en af de største tidsbesparelser. Cashier findes til Stripe og Paddle og håndterer oprettelse af abonnementer, prøveperioder, skift mellem planer, rabatkoder, fakturaer som PDF og de webhooks (automatiske beskeder fra betalingsudbyderen) der holder din database opdateret når et kort bliver afvist.
Det er netop den slags kode der er dyr at lave forkert. En fejl i betalingsflowet koster enten penge eller kunder. Meget af arbejdet ligger i undtagelserne: kunden der opgraderer midt i en måned, eller kortet der udløber. Cashier har svar på de fleste af dem. Skal du bruge en dansk betalingsudbyder, skal integrationen dog bygges særskilt, for Cashier dækker kun Stripe og Paddle.
Økosystemet: pakker og hosting der sparer timer
8. Officielle pakker til login, API'er og realtid
Ud over selve frameworket vedligeholder Laravel-teamet en række officielle pakker. Sanctum styrer adgangen til et API, fx fra en mobilapp. Socialite giver login med Google, GitHub eller LinkedIn. Scout gør det enkelt at tilføje fuldtekstsøgning, og Reverb giver opdateringer i realtid så en ny besked eller ordre dukker op uden at brugeren skal genindlæse siden.
Med Laravel 13 fulgte også et officielt AI SDK til fx tekstgenerering og semantisk søgning. Fordelen ved officielle pakker er at de følger frameworkets versioner og bliver opdateret sammen med det. Du risikerer ikke at en vigtig del af din app hænger på et hobbyprojekt som ingen længere passer.
9. Spatie og Filament: et community der har løst det meste
Laravel har et stort økosystem af pakker fra tredjeparter, og to navne skiller sig ud. Spatie, et belgisk firma, vedligeholder over 500 open source-pakker til PHP og Laravel, fx til brugerroller og rettigheder, håndtering af billeder og filer og backup. Pakkerne er udsprunget af rigtige kundeprojekter og er samlet downloadet næsten 3 milliarder gange.
Filament er et open source-værktøj til at bygge administrationspaneler oven på Laravel og Livewire. Skal du og dine kolleger kunne redigere kunder, ordrer eller indhold bag om appen, kan det ofte bygges med Filament langt hurtigere end fra bunden.
10. Hosting uden låsning
En Laravel-app er en almindelig PHP-applikation. Den kan køre på en server hos stort set enhver hostingudbyder, også danske og europæiske hvis dine data skal blive i EU. Du er ikke bundet til én platform.
Vil du have mindre arbejde med driften, findes der officielle værktøjer: Forge sætter servere op og administrerer dem, Laravel Cloud er en administreret hostingplatform, og Nightwatch overvåger fejl og hastighed. Lokalt kan Herd sætte et udviklingsmiljø op på en Mac eller pc. Det er tilvalg og ikke krav, og jeg vælger hostingen ud fra dit budget og dine krav til data.
Værktøjerne der gør fejlfinding billigere
11. Tinkerwell og Ray finder fejlene hurtigere
To af de værktøjer jeg bruger mest, er udviklet med Laravel for øje. Tinkerwell er en editor hvor jeg kan køre et stykke kode direkte i sammenhæng med din app, også på en server via SSH. Skal jeg undersøge hvorfor en bestemt kunde får en forkert pris, kan jeg hente kunden frem og køre beregningen trin for trin uden at ændre koden i den kørende app.
Ray fra Spatie er et værktøj til fejlsøgning der viser output i et separat vindue: databaseforespørgsler, mails, variabler og hvor lang tid tingene tager. Jeg kan se præcis hvilke forespørgsler en side laver, og finde den der gør den langsom. Begge værktøjer er betalte, men de gør fejlsøgningen kortere, og fejlsøgning er tid du ellers betaler for.
12. Test er en del af frameworket
Laravel er bygget til at blive testet. Et nyt projekt har testopsætningen klar med PHPUnit eller Pest, og frameworket har indbyggede hjælpere til at teste hele forløb: en bruger logger ind, opretter en ordre og får en bekræftelsesmail. Mails, køer og kald til eksterne API'er kan erstattes med simulerede udgaver i testene, så de kører hurtigt og aldrig sender noget til rigtige kunder.
For dig er gevinsten at ændringer om et år kan laves med ro i maven fordi testene fanger det når en ny funktion ødelægger en gammel. Jeg har skrevet mere om hvorfor automatiserede tests sparer penge, også i små projekter.
En forudsigelig fremtid
13. Fast udgivelsesrytme og et firma bag
Laravel udgiver en ny hovedversion cirka én gang om året. Hver version får fejlrettelser i 18 måneder og sikkerhedsopdateringer i 2 år ifølge Laravels egen supportpolitik. Laravel 13 udkom i marts 2026, og samme måned holdt Laravel 11 op med at få sikkerhedsopdateringer. Du kan altså planlægge dine opgraderinger i stedet for at blive overrasket af dem. Opgraderingen til Laravel 13 kræver desuden kun få ændringer i de fleste apps, fordi teamet bevidst har holdt ændringer der bryder eksisterende kode på et minimum.
Bag frameworket står også et firma. I 2024 investerede Accel 57 millioner dollars i Laravel, og pengene går blandt andet til hosting- og overvågningsprodukter og flere udviklere på open source-delen. Det er ingen garanti, men det er et bedre udgangspunkt end et framework der hviler på få frivillige.
Ulemperne, og hvornår jeg vælger noget andet
Ulemper du skal kende
- Det er let at skrive langsom kode. Eloquent gør det nemt at hente data, næsten for nemt, og en klassisk fejl er en side der laver hundredvis af små databaseforespørgsler i stedet for én. Laravel garanterer ikke god kode, så kig efter tegnene på en sund kodebase uanset hvem der har bygget den.
- Meget sker automatisk bag kulisserne. Det gør en erfaren Laravel-udvikler hurtig, men en udvikler uden Laravel-erfaring kan have svært ved at gennemskue hvorfor tingene virker.
- Opgraderinger skal tages løbende. Den årlige rytme er kun en fordel hvis du følger med. Springer du tre versioner over, bliver opgraderingen et projekt i sig selv.
- PHP har stadig et ry fra gamle, rodede hjemmesider. Moderne PHP er noget helt andet, og jeg har skrevet om hvorfor PHP stadig er et godt valg. Ryet kan dog påvirke hvem der søger hvis du vil ansætte en udvikler selv.
- Mange af de bedste værktøjer koster penge, fx Forge, Nova og Tinkerwell. Beløbene er typisk små i forhold til udviklingstimer, men de skal med i budgettet.
Projekter hvor jeg vælger noget andet
- En hjemmeside der mest består af indhold, fx en virksomhedsside eller en blog. Her er et CMS eller en statisk side typisk billigere at bygge og drive.
- Projekter hvor kernen er tung databehandling eller maskinlæring. Python har det stærkeste økosystem til den slags, og har appen også brugere og forretningsregler, kan Laravel kalde en Python-tjeneste.
- Et team der allerede kører en anden teknologi, fx .NET, Django eller Node. Så er det sjældent fornuftigt at indføre et nyt sprog bare fordi jeg foretrækker det.
- Apps hvor næsten alt sker i browseren, og hvor serveren kun skal gemme lidt data. Her kan en ren JavaScript-løsning være enklere.
Næste skridt: passer Laravel til dit projekt?
Har du en idé til en webapp, en kundeportal eller en SaaS, handler spørgsmålet sjældent kun om hvilket framework der er bedst. Det handler om hvad løsningen skal kunne, hvem der skal vedligeholde den, og hvad den må koste. Laravel er mit udgangspunkt fordi det dækker de fleste af de behov uden at låse dig.
Tre ting du kan gøre nu:
- Skriv ned hvad brugerne skal kunne de første tre måneder. Det afgør mere end valget af framework.
- Spørg din udvikler hvilke dele der løses med færdige pakker, og hvilke der bygges fra bunden.
- Sørg for at koden ligger i dit eget repository (kodearkiv) fra første dag.
Vil du vide mere om rollen, kan du læse om hvad en Laravel-udvikler laver, og hvornår du skal vælge en. På siden om Laravel-udvikling kan du se hvordan jeg arbejder: et forprojekt til fast pris før større opgaver, direkte kontakt med mig og kode du ejer fra første dag.
Ofte stillede spørgsmål
Er Laravel gratis at bruge?
Ja, Laravel er open source og gratis at bruge, også i kommercielle projekter. Det du betaler for, er udviklingstimerne, hosting og eventuelle betalte tilvalg som Forge, Nova eller Laravel Cloud. Der er ingen licens pr. bruger, og du er ikke afhængig af at en leverandør bliver ved med at sælge produktet fordi koden er frit tilgængelig.
Er Laravel sikkert?
Laravel har god beskyttelse indbygget mod de mest almindelige angreb: beskyttelse mod falske formularindsendelser (CSRF), automatisk escaping af output mod XSS, parametriserede databaseforespørgsler mod SQL-injektion og sikker hashing af adgangskoder. Sikkerheden afhænger dog af to ting frameworket ikke kan klare for dig: at koden er skrevet ordentligt, og at appen holdes opdateret med sikkerhedsrettelser.
Kan Laravel klare mange brugere?
Ja, Laravel kan sagtens bære apps med mange brugere når de er bygget og hostet fornuftigt. Flaskehalsen er sjældent frameworket, men typisk ineffektive databaseforespørgsler, manglende cache eller tunge opgaver der burde ligge i en kø. Laravel kan køre på flere servere samtidig, og pakken Octane kan holde appen i hukommelsen mellem forespørgsler for ekstra fart hvis der bliver brug for det.
Hvad er forskellen på Laravel og WordPress?
WordPress er et CMS, altså et system til at udgive indhold som sider og blogindlæg. Laravel er et framework til at bygge specialudviklede applikationer med egne data, brugere og forretningsregler. Begge er skrevet i PHP, men de løser forskellige opgaver. Til en indholdstung hjemmeside er WordPress ofte det billigste valg. Til en kundeportal, et bookingsystem eller en SaaS er Laravel typisk det bedre fundament.