Docker for WordPress-utvikling i 2026: Kontainerisering gjørt enkelt

Hvis du er en profesjonell WordPress-utvikler i 2026, er Docker din beste venn. Tiden da man manuelt installerte PHP-versjoner på Mac-en eller kjempet mot Windows-spesifikke serverfeil er forbi. Docker har blitt det felles språket for utviklingsmiljøer, og den som jobber i dagens WordPress-økosystem bør kunne det godt.

Denne guiden går gjennom Docker i WordPress-utvikling: fra det grunnleggende og det offisielle wordpress-bildet til Compose, wp-env, feilsøking, CI/CD og overgangen fra MAMP eller LocalWP. De tekniske detaljene kommer fra den offisielle dokumentasjonen til Docker, wordpress-siden på Docker Hub, MariaDB og WordPress sin utviklerhåndbok, lenket i hver seksjon.

#Hvorfor bruke Docker til WordPress-utvikling

Unnskyldningen “det fungerer hos meg” holder ikke lenger når miljøet ligger i versjonerte filer. Kontainerisering gir likhet mellom miljøene, og det har endret hvordan WordPress-team samarbeider og leverer programvare.

#Likt miljø lokalt og i produksjon

Den lokale kontaineren din kan bruke samme Linux-distribusjon, PHP-versjon og MySQL-oppsett som produksjonsserveren. Det reduserer den mest frustrerende typen feil: de som bare dukker opp i produksjon. Når du utvikler i en kontainer med samme bilde som serveren, oppfører koden på den bærbare seg likt på staging-serveren og i produksjon.

Like miljøer handler om mer enn programvareversjoner. Det gjelder også nettverksoppsett, miljøvariabler og filrettigheter. Med Docker jobber alle på teamet i samme miljø, uansett om vertssystemet er macOS, Windows eller Linux.

#Flere PHP-versjoner i isolerte prosjekter

Prosjekt A trenger PHP 8.4, og prosjekt B trenger PHP 7.4? Ikke noe problem. Hvert prosjekt lever i sin egen “boble” og kommer aldri i konflikt med andre. Med tradisjonelle verktøy som MAMP eller XAMPP var denne isolasjonen vanskelig, fordi et bytte av PHP-versjon påvirket alle prosjekter samtidig.

Isolasjonen beskytter også vertssystemet ditt. PHP-utvidelser, systembiblioteker og prosjektavhengigheter holdes adskilt. Krever et prosjekt en eksperimentell PHP-utvidelse eller et uvanlig serveroppsett, kan du ta det i bruk uten risiko for de andre prosjektene.

#Reproduserbart miljø med filer i Git

Hvert Docker-miljø beskrives av konfigurasjonsfiler som versjoneres i Git. Et nytt teammedlem kloner repoet, kjører én kommando og har et miljø som virker, uten en trinnvis installasjonsguide som raskt blir utdatert. Dokumentasjonen av miljøet ligger i selve prosjektkoden.

#WordPress med Docker Compose

Docker Compose koordinerer flere kontainere. Et typisk WordPress-oppsett i 2026 består av flere tjenester som sammen gir et komplett utviklingsmiljø.

#Hvilke tjenester WordPress trenger i Docker Compose

1. WordPress (PHP-FPM eller Apache): motoren som kjører PHP-koden til WordPress.
2. Nginx: webserveren foran PHP-FPM, hvis du velger fpm-varianten.
3. MariaDB/MySQL: databasen der alt innholdet lagres.
4. Redis: objektbufferen, anbefalt hvis prosjektet bruker den i produksjon.
5. Mailpit: fanger utgående e-post under testing.

# Utdrag av compose.yaml med FPM-varianten
services:
  db:
    image: mariadb:11.4
    volumes:
      - db_data:/var/lib/mysql
  wordpress:
    image: wordpress:php8.4-fpm
    depends_on:
      - db
volumes:
  db_data:

fpm-varianten har ingen webserver, så den trenger en Nginx-kontainer som sender PHP-forespørslene videre. Vil du slippe å sette opp Nginx, serverer Apache-varianten (wordpress:php8.4-apache) WordPress direkte på port 80 i kontaineren.

#Bind mounts eller navngitte volumer for WordPress

Volumer i Docker Compose er sentrale i WordPress-utvikling. Tema- og utvidelsesmappene må monteres slik at du kan redigere koden direkte, mens databasedata bør ligge i navngitte volumer så ingenting går tapt mellom omstarter.

Riktig strategi veier ytelse mot funksjon. For filer du redigerer ofte (temaer, egne utvidelser), bruk bind mounts. For data som bare skal bevares (database, opplastinger), bruk navngitte Docker-volumer. Dokumentasjonen til det offisielle bildet oppgir stiene: temaer hører hjemme i /var/www/html/wp-content/themes/ og utvidelser i /var/www/html/wp-content/plugins/.

#Påloggingsdata i .env-filer med Docker Compose

Håndtering av hemmeligheter betyr noe også lokalt. Legg databasepassord og API-nøkler i .env-filer, og sørg for at filene står i .gitignore. Docker Compose leser .env-filen i prosjektmappen og erstatter variabler som ${DB_PASSWORD} i compose.yaml, slik at sensitiv konfigurasjon holdes adskilt fra den versjonerte koden.

#Miljøvariabler i det offisielle WordPress-bildet

wordpress-bildet på Docker Hub lager sin egen wp-config.php ut fra miljøvariabler. Ifølge den offisielle siden for bildet gjenkjennes disse:

Detaljen som koster mest tid: WordPress-kontaineren oppretter ikke databasen som står i WORDPRESS_DB_NAME. Det gjør databasekontaineren, med MARIADB_DATABASE i MariaDB eller MYSQL_DATABASE i MySQL. Stemmer ikke de to navnene, viser WordPress en tilkoblingsfeil selv om påloggingsdataene er riktige.

WORDPRESS_CONFIG_EXTRA brukes til konstanter som bildet ikke eksponerer, for eksempel WP_ALLOW_MULTISITE eller WP_ENVIRONMENT_TYPE. Alt du legger der kjøres med eval(), så hold det kort og versjoner det sammen med resten av konfigurasjonen.

#Slik venter du på at MariaDB er klar før WordPress

En enkel depends_on er ikke nok. Compose-dokumentasjonen om oppstartsrekkefølge forklarer at Compose venter til avhengighetens kontainer kjører, ikke til den tar imot tilkoblinger. MariaDB bruker noen sekunder på å initialisere seg første gang, og WordPress kan starte før og feile ved tilkobling.

Løsningen er en healthcheck på databasen og condition: service_healthy på WordPress. Det offisielle MariaDB-bildet har skriptet healthcheck.sh til dette, og MariaDB-dokumentasjonen viser et eksempel med WordPress. Tilpasset et utviklingsmiljø ser det slik ut:

services:
  db:
    image: mariadb:11.4
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 10s
      interval: 10s
      timeout: 5s
      retries: 3
  wordpress:
    image: wordpress:php8.4-apache
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DEBUG: '1'
    volumes:
      - wp_data:/var/www/html
      - ./mitt-tema:/var/www/html/wp-content/themes/mitt-tema
    depends_on:
      db:
        condition: service_healthy
volumes:
  db_data:
  wp_data:

Med denne filen starter docker compose up -d databasen, venter til healthchecken passerer og starter først da WordPress på http://localhost:8080. Det egne temaet monteres som bind mount, og resten av WordPress ligger i volumet wp_data.

#WordPress-bildene apache, fpm, alpine og cli

Det offisielle bildet publiseres i flere varianter. Taggene kombinerer WordPress-versjon, PHP-versjon og type, for eksempel php8.4-apache, php8.4-fpm, php8.4-fpm-alpine eller cli.

• apache: WordPress og Apache i én kontainer. Det enkleste valget for lokal utvikling.
• fpm: bare PHP-FPM, ment å stå bak Nginx eller en annen proxy.
• fpm-alpine: det samme på Alpine Linux, med mindre bilde.
• cli: WP-CLI uten webserver, for å kjøre wp-kommandoer mot en eksisterende installasjon.

cli-varianten har en felle som er dokumentert på Docker Hub: den bygger på Alpine, og brukeren www-data har UID 82, mens de Debian-baserte variantene bruker UID 33. Når du kjører wordpress:cli mot en Debian-installasjon, trengs som regel --user 33:33, og noen ganger -e HOME=/tmp, for at WP-CLI skal kunne skrive til filene.

#Slik legger du til PHP-utvidelser i det offisielle bildet

Bildet har ingen ekstra PHP-utvidelser, selv om populære utvidelser for WordPress krever dem. Docker Hub nevner som eksempel at bildet ikke kan sende e-post på egen hånd. For flere utvidelser bygger du et eget bilde med FROM wordpress:... og følger instruksjonene for php-bildet. For direktiver som upload_max_filesize holder det å kopiere en custom.ini til $PHP_INI_DIR/conf.d/:

FROM wordpress:php8.4-apache
COPY custom.ini $PHP_INI_DIR/conf.d/

Vil du bake temaer eller utvidelser inn i bildet for flere installasjoner, sier dokumentasjonen at de skal ligge i /usr/src/wordpress/. Den mappen kopieres til /var/www/html/ første gang kontaineren starter.

#wp-env, det offisielle Docker-miljøet for WordPress

Utvikler du utvidelser eller temaer og ikke trenger å gjenskape en bestemt server, slipper du med wp-env å skrive compose.yaml for hånd. Det er en Node-pakke fra Gutenberg-repoet som bruker Docker under panseret. Den installeres med npm -g i @wordpress/env og startes med wp-env start fra mappen til utvidelsen.

Miljøet kjører da på http://localhost:8888 med brukeren admin og passordet password. Konfigurasjonen ligger i en .wp-env.json i roten av prosjektet:

{
  "$schema": "https://schemas.wp.org/trunk/wp-env.json",
  "core": null,
  "phpVersion": "8.3",
  "plugins": [ "." ],
  "config": {
    "WP_DEBUG_LOG": true
  }
}

core satt til null bruker siste stabile WordPress-versjon, phpVersion låser PHP-versjonen og plugins lister utvidelsene som installeres og aktiveres. I tillegg finnes themes, mappings for å montere mapper, port (8888 som standard), testsPort (8889) og mariadbVersion.

Composer, PHPUnit og WP-CLI følger med i kontaineren cli: wp-env run cli wp plugin list eller wp-env run cli --env-cwd=wp-content/plugins/min-utvidelse composer install. Xdebug er installert, men slått av, og slås på med wp-env start --xdebug. Dokumentasjonen beskriver også en eksperimentell modus, wp-env start --runtime=playground, som kjører WordPress i WebAssembly uten Docker, med SQLite og uten kommandoen run.

Den praktiske forskjellen fra Compose: wp-env bestemmer arkitekturen for deg. For en utvidelse går det raskere. For å gjenskape en produksjonsserver med Nginx, Redis og en eksakt MariaDB-versjon er Compose fortsatt riktig verktøy.

#VS Code Dev Containers for WordPress

Mange utviklere installerer ikke lenger PHP på den bærbare. De bruker VS Code Dev Containers, som endrer måten man jobber med editoren på.

#Slik fungerer en Dev Container i VS Code

Du åpner prosjektmappen, VS Code oppdager mappen .devcontainer, starter Docker og kobler IDE-en direkte inn i kontaineren. VS Code-utvidelser, kommandolinjeverktøy og editorinnstillinger kjører inne i kontaineren.

#Ferdig oppsatte utvidelser og lintere i kontaineren

Et oppsatt arbeidsområde for hvert prosjekt, så snart mappen åpnes. Om utvikleren kom inn i teamet for fem minutter eller fem år siden, er miljøet likt for alle. PHP-utvidelser, lintere, kodeformaterere og feilsøkingsverktøy er definert i repoet.

#Dev Containers for distribuerte team

For WordPress-byråer med distribuerte team fjerner Dev Containers en vanlig kilde til friksjon: forskjeller mellom lokale miljøer. En utvikler som jobber fra et annet sted har nøyaktig samme miljø som resten av teamet, uten økter av typen “la oss sette opp den bærbare din”.

#Docker-ytelse på Mac og Windows

Docker var tregt på andre systemer enn Linux, fordi prosjektfilene må gjennom en virtuell maskin. Docker Desktop har i dag flere valg som reduserer den kostnaden.

#Slik slår du på VirtioFS i Docker Desktop

På macOS velger du VirtioFS som implementasjon for fildeling i innstillingene til Docker Desktop. Dokumentasjonen for innstillingene i Docker Desktop oppgir at VirtioFS har kortet ned tiden for filsystemoperasjoner med opptil 98%. Det erstatter de eldre valgene osxfs og gRPC FUSE.

#Synchronized file shares for store repoer

For svært store prosjekter tilbyr Docker Desktop Synchronized file shares: en synkronisert buffer av vertsfilene på et ext4-filsystem inne i den virtuelle maskinen. Docker anbefaler det for repoer med 100 000 filer eller mer, og det er tilgjengelig i abonnementene Pro, Team og Business. En WordPress-installasjon med en stor node_modules i temaet kan nærme seg det tallet.

#Hvor mye RAM Docker Desktop bruker

Den virtuelle maskinen i Docker Desktop holder av minne så lenge den kjører. Modusen Resource Saver stopper den når ingen kontainere har kjørt på 5 minutter (verdien kan justeres), og Docker oppgir en besparelse på 2 GB eller mer i minne og CPU på verten.

#Docker vs LocalWP, MAMP og DDEV

#Docker Compose sammenlignet med DDEV og Lando

DDEV og Lando gjør Docker enklere for WordPress-utviklere. De leverer ferdige oppsett og forenklede kommandoer som gjør læringskurven slakere. For prosjekter der du må styre hver del av infrastrukturen selv, er Compose med din egen fil fortsatt det mest fleksible valget.

#Når du bør velge DDEV og når Docker Compose

Valget avhenger av erfaringen din og prosjektet. Er du ny med kontainere, gir DDEV en mykere start. Har du flere prosjekter med ulike krav til infrastruktur, gir Docker Compose med egne oppsett mer handlingsrom.

#Sikkerhet i Docker-miljøer for WordPress

Docker gir isolasjon som standard, men konfigurasjonen avgjør hvor mye beskyttelse du faktisk får.

#Kontainere uten root og oppdaterte bilder

Unngå å kjøre prosesser som root i kontainerne når det ikke trengs. Hold basisbildene oppdatert for å få sikkerhetsoppdateringer; dokumentasjonen til wordpress-bildet minner selv om å bygge og rulle ut på nytt jevnlig. Skann bildene for kjente sårbarheter med verktøy som Docker Scout eller Trivy.

#Egne Docker-nettverk per prosjekt

Compose oppretter et eget nettverk for hvert prosjekt. Behold det skillet, og ikke koble kontainere fra ulike prosjekter til samme nettverk uten grunn, slik at et innbrudd i ett prosjekt ikke når de andre.

#Docker Secrets og .env-filer for passord

Legg aldri påloggingsdata direkte i Dockerfile eller compose.yaml. wordpress-bildet godtar suffikset _FILE på variablene sine: WORDPRESS_DB_PASSWORD_FILE=/run/secrets/db_password leser passordet fra en fil i stedet for en variabel. Compose monterer hver secret i /run/secrets/<navn> i kontaineren, ifølge veiledningen om secrets, som nevner en begrensning: secrets fungerer bare i Linux-kontainere.

#Hvordan sette opp CI/CD for WordPress med Docker

Den største fordelen med Docker er at CI/CD-løpet ditt (GitHub Actions, GitLab CI) kan bruke de samme bildene som du bruker lokalt. Den likheten fjerner en hel kategori av feil ved utrulling.

#Trinnene i et CI/CD-løp med Docker

1. Kjør PHPUnit-tester i kontaineren for å sjekke logikken i backend.
2. Kjør ende-til-ende-tester med Cypress eller Playwright mot kontaineren.
3. Rull ut det stabile bildet til produksjonsklyngen (Kubernetes/Swarm).

#Privat bilderegister for WordPress

Team som bygger egne WordPress-bilder, lagrer dem i et privat kontainerregister. Bildene inneholder de nødvendige PHP-utvidelsene, utviklingsverktøyene og prosjektkonfigurasjonen, slik at et nytt teammedlem laster ned bildet i stedet for å bygge det.

Docker Hub beskriver også en statisk utrulling: bygg et bilde med WordPress, tema og utvidelser i /usr/src/wordpress, kjør det med --read-only og tmpfs for /tmp og /run, og oppdater ved å rulle ut et nytt bilde i stedet for å bruke automatiske oppdateringer.

#WordPress på Kubernetes eller Docker Swarm

For WordPress-nettsteder med mye trafikk gjør orkestrering med Kubernetes eller Docker Swarm det mulig å skalere etter behov. Når trafikken øker under kampanjer eller salg, startes nye kontainere som tar belastningen.

#Hvordan feilsøke WordPress i Docker

Feilsøking av WordPress i kontainere krever noen andre teknikker enn tradisjonell lokal utvikling.

#Xdebug i kontainere

Xdebug i en kontainer krever oppmerksomhet rundt nettverket: kontaineren må nå IDE-en som lytter på verten. Mange Dev Container-oppsett har Xdebug med fra før, wp-env slår det på med --xdebug, og i et eget bilde må du installere utvidelsen og sette tilkoblingsvert og port.

#Slik ser du loggene med docker compose logs

Docker gir samlet tilgang til loggene fra alle tjenester. Bruk docker compose logs for å se samlet utdata fra WordPress, Nginx, MariaDB og Redis, eller docker compose logs -f wordpress for å følge én tjeneste. Med WORDPRESS_DEBUG slått på dukker PHP-advarslene opp i den samme utdataen. I produksjon gir verktøy som Grafana og Prometheus overvåkingspaneler.

#Query Monitor og Blackfire i Docker

Verktøy som Query Monitor og Blackfire fungerer i Docker-miljøer for WordPress. Profilering i kontaineren gir et bilde av ytelsen under forhold som ligger nær produksjon.

#Slik flytter du fra MAMP eller LocalWP til Docker

Bruker du MAMP, XAMPP eller LocalWP, er overgangen til Docker enklere enn den ser ut. Vanligvis eksporterer du databasene, skriver Compose-filer som gjenskaper dagens oppsett, og tar i bruk resten av praksisene gradvis.

#Slik flytter du et pilotprosjekt til Docker Compose

Start med ett pilotprosjekt. Lag en compose.yaml som gjenskaper dagens miljø, inkludert PHP-versjon, databasemotor og nødvendige utvidelser. Når piloten fungerer, flytter du de andre prosjektene.

#Slik importerer du databasen og wp-content

Eksporter databasene med mysqldump og importer dem i MariaDB-kontaineren. Kopier WordPress-filene (særlig wp-content) inn i volumstrukturen til Docker. Endrer adressen seg, for eksempel til http://localhost:8080, kjører du wp search-replace med WP-CLI og sjekker at medier og lenker virker i det nye miljøet.

#Konklusjon

Docker er ikke lenger bare for DevOps; det er en grunnleggende ferdighet for WordPress-utviklere i 2026. Med kontainere fjerner du miljøfeil, får nye teammedlemmer raskere i gang og bygger sikrere applikasjoner. Tiden du bruker på å lære Docker, tjener du inn igjen i produktivitet og kodekvalitet.

Sliter du fortsatt med lokale serveroppsett? Da er det på tide å kontainerisere miljøet ditt med Docker.