--- title: "Zero downtime WordPress-deployments med Trellis: sådan virker atomic releases i praksis" url: "https://helloblog.io/da/zero-downtime-wordpress-deployments-med-trellis/" date: "2025-10-02" modified: "2026-01-20" author: "Mads Jensen" language: "da_DK" categories: ["WordPress-økosystem"] tags: ["Bedrock", "Deployments", "DevOps", "Trellis", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/14/2026/01/featured-2-1024x572.png" excerpt: "Hvis du stadig deployer WordPress ved at overskrive filer på en live server, har du sikkert set de klassiske “lige i et øjeblik”-fejl. Trellis løser det med atomic deployments og rollback på sekunder – uden at du behøver at skifte hele dit lokale setup ud." --- # Zero downtime WordPress-deployments med Trellis: sådan virker atomic releases i praksis I moderne app-udvikling er *zero downtime deployments* efterhånden baseline: nye versioner bliver gjort klar ved siden af den kørende version, og der skiftes over i ét hug. I WordPress-verdenen ser jeg stadig masser af deploy-flows, der reelt er “kopiér filer op og kryds fingre”. Roots’ Trellis kommer med en atomic deployment-strategi ud af boksen, og den er en af de mest undervurderede opgraderinger, du kan give dit WordPress-driftssetup. Det interessante er, at du ikke behøver at adoptere Trellis til hele din udviklingsworkflow for at få værdien. Mange bruger Trellis primært som deploy-værktøj til Bedrock-baserede projekter, mens de fortsætter lokalt med fx Valet, Lando eller DDEV – og deployer til alt fra managed hosts til mere klassiske Linux-servere. ## Hvad “zero downtime” egentlig betyder i WordPress-kontekst Når vi taler *zero downtime*, handler det ikke om, at der aldrig kan opstå en fejl i en release. Pointen er, at selve deploy-processen ikke efterlader sitet i en halv-opdateret tilstand, hvor brugere rammer fatale errors, manglende filer eller en blanding af gammel og ny kode. Den klassiske WordPress-deploy er ofte “in-place”: filer overskrives direkte i den mappe, webserveren serverer fra. Det kan være hurtigt, men det er også den perfekte opskrift på transient fejl, når en request rammer midt i en upload. ## Hvorfor traditionelle WordPress-deploys går galt De fleste WordPress-sites ender i én af de her tre deploy-kategorier: - **FTP/SFTP-uploads:** Man uploader ændringer manuelt og overskriver eksisterende filer. Undervejs serverer sitet en blanding af gammelt og nyt. - **Synkronisering med fx `rsync`:** Typisk hurtigere end FTP, men det er stadig “overskriv live filer”, så problemet er det samme. - **Plugin-baseret deployment på managed hosts:** Ofte super nemt i UI’et, men mange løsninger opdaterer stadig filer in-place og uden en reel rollback-mekanisme. Fællesnævneren er, at du kan få mærkelige fejl under deploy-vinduet, og at rollback typisk er en manuel øvelse (eller i praksis “deploy igen og håb”). ## Trellis’ løsning: atomic og immutable deployments Trellis deployer ikke ved at overskrive den kørende release. I stedet arbejder den med *atomic deployments* (skift i ét hug) og et *immutable* release-princip (en release ændres ikke efter den er lagt ud). Det betyder i praksis, at hver deploy skaber en helt ny release-mappe, gør den klar i isolation og skifter derefter webserverens “pegepind” til den nye release. Ingen mellemfaser, hvor brugere ser en halvt opdateret kodebase. ### Mappestrukturen: “current”, “releases” og “shared” Når Trellis deployer til en server, etablerer den en struktur, der er designet til netop atomic releases: ``` /srv/www/example.com/ ├── current/ # Symlink til aktiv release ├── releases/ # Alle deployede releases │ ├── 20250930124530/ │ ├── 20250930083045/ │ └── 20250930141622/ # Nyeste ├── shared/ # Delte filer på tværs af releases │ └── uploads/ └── logs/ ``` Nøglen er `current`, som ikke er en “rigtig” mappe, men et symlink (symbolsk link). Webserveren peger altid på `current`, og Trellis kan derfor skifte aktiv release ved blot at opdatere symlinket. ### Hvad der sker, når du kører en deploy Når du kører `trellis deploy production`, gennemfører Trellis en serie trin, hvor den nye release bygges op adskilt fra den live kode: 1. **Initialize:** Struktur sikres, og en ny release-mappe oprettes (typisk timestamp-baseret). 2. **Update:** Nyeste kode hentes fra dit Git-repository til et separat område, ikke direkte ind i live path. 3. **Prepare:** Koden kopieres over i release-mappen. 4. **Build:** Dependencies installeres (fx via `composer install`). 5. **Share:** Delte paths (typisk uploads) linkes ind fra `shared` til den nye release. 6. **Finalize:** `current`-symlinket opdateres til at pege på den nye release. Overgangen bliver dermed et øjebliksskift: det ene sekund serverer sitet fra en gammel release-mappe, og det næste sekund serverer det fra den nye. #### Hvorfor “shared” betyder noget WordPress er ikke kun kode. Medieuploads skal overleve på tværs af releases, og derfor holdes typisk `uploads/` uden for releases og symlinkes ind. Det er en central detalje i at gøre releases reelt udskiftelige. ## Database: zero downtime for kode er ikke det samme som schema-ændringer Atomic deployments løser fil- og kodeproblemet, men databasen er en separat udfordring. Trellis’ deploy inkluderer ikke database-migrations som en automatisk del af processen, hvilket også er tydeligt nævnt i Trellis-dokumentationen. Hvis du arbejder med Acorn, kan du bruge Laravel migrations (migrations = versionsstyrede schema-ændringer) til WordPress-sites og sørge for, at de bliver kørt i forbindelse med deployment. Pointen er, at du stadig skal tænke i *backwards compatible* schema-ændringer, hvis du vil holde en “ingen nedetid”-oplevelse hele vejen igennem. ## Rollback på sekunder: den praktiske gevinst ved immutable releases Når hver release ligger i sin egen mappe og aldrig modificeres efter deploy, bliver rollback pludselig trivielt: du peger bare `current` tilbage på den forrige release. ``` trellis rollback production ``` Trellis beholder som standard flere af de seneste releases på serveren, så rollback ikke kræver en ny build eller re-upload. Det er i praksis en af de største forbedringer i driftssikkerhed, du kan få for WordPress. ## Deploy hooks: gør deployment til et kontrolleret flow Trellis har et sæt hooks (hooks = indstikspunkter i processen), så du kan koble egne tasks på før/efter bestemte deploy-trin. Blandt andet findes der hooks til build- og finalize-faserne, og derudover hooks omkring de større deploy steps (initialize, update, prepare, build, share, finalize). I praksis betyder det, at du kan standardisere ting, der ellers ofte ligger som manuelle tjeklister: - Tage database-backup lige inden der skiftes release - Rydde caches efter deploy (page cache, object cache osv.) - Sende en deployment-notifikation til teamet - Køre simple smoke tests mod den nye release ## Kom i gang: minimal opskrift til zero downtime deploys Hvis du vil i gang uden at vende hele din udviklingsstack på hovedet, er den korte vej typisk: 1. Brug Bedrock for en mere robust projektstruktur og dependency management. 2. Installér Trellis og konfigurér dine deployment-indstillinger. 3. Udfyld `wordpress_sites.yml` med dit Git-repository (og relevante deploy-settings). 4. Kør `trellis deploy production`. Første deploy tager typisk længst tid, fordi serverens struktur og dependencies skal etableres. Derefter handler det primært om, at hver release bygges isoleret og aktiveres atomisk. #### Det vigtigste take-away Hvis du kan skifte fra “overskriv filer på live site” til “byg en release og skift symlink”, får du både færre deploy-fejl og en rollback, der faktisk er brugbar i praksis. ## Referencer / Kilder - [Zero Downtime WordPress Deployments with Trellis](https://roots.io/zero-downtime-wordpress-deployments-with-trellis/) - [Trellis documentation: Deployments](https://roots.io/trellis/docs/deployments/) - [Bedrock](https://roots.io/bedrock/) - [Trellis](https://roots.io/trellis/) - [Acorn documentation: Creating and running Laravel migrations](https://roots.io/acorn/docs/creating-and-running-laravel-migrations/)