Docker Desktop fylder stadig samme plads på udviklerens maskine som for ti år siden, men værktøjet under motorhjelmen har ændret sig markant. Den nyeste udgave, version 4.88.0, udkom den 24. august 2026 og bygger videre på en AI-satsning, der startede med agenten Gordon og siden er vokset til et helt økosystem af lokale sprogmodeller og MCP-servere. For danske og nordiske udviklerteams, der stadig kører containere lokalt frem for udelukkende i skyen, er det blevet en reel fordel at kende de nye funktioner, inden en kollega spørger, hvorfor byggejobbet pludselig tager dobbelt så lang tid som i sidste uge. Denne guide går trin for trin gennem installation, konfiguration og de AI-drevne dele af platformen, så du både ender med en fungerende opsætning og en idé om, hvornår de nye funktioner rent faktisk sparer dig tid frem for blot at være endnu en menu at klikke forbi.

Vi tester hvert trin op imod den aktuelle 4.88-udgivelse, inkluderer output du selv kan sammenligne med, og runder af med en liste over faldgruber, fejlfindingstrin og et komplet projekt, du kan genbruge på egen maskine. Målgruppen er udviklere, der allerede kender til containere i grove træk, men som vil have et opdateret overblik over, hvad der er ændret siden sidste gang de tjekkede indstillingerne. Er du helt ny til containere, kan du sagtens følge med fra Trin 1, men forvent at bruge lidt ekstra tid på at forstå, hvorfor et image og en container ikke er det samme, før du når til de AI-drevne trin sidst i guiden. Har du derimod kørt containere i årevis og blot vil have styr på Model Runner, MCP Toolkit og Gordon, kan du roligt springe frem til Trin 7 og bruge resten som opslagsværk.

Hvad er nyt i platformen i 2026?

Docker har skiftet til en ugentlig udgivelsestakt i 2026, hvilket forklarer spring som 4.85.0 (3. august), 4.86.0 (10. august), 4.87.0 (17. august) og 4.88.0 (24. august), som blandt andet opdaterer containerd til version 2.3.3. Den fulde liste over udgivelsesnoter viser en støt strøm af mindre rettelser snarere end store spring, hvilket i praksis betyder, at du sjældent bliver overrasket af brudte funktioner mellem to opdateringer.

Det store skifte handler dog ikke om versionsnumre. Model Runner lader dig køre sprogmodeller lokalt direkte fra det grafiske interface, MCP Toolkit giver adgang til over 100 færdigkonfigurerede MCP-servere uden ekstra opsætning, og AI-agenten Gordon er gået fra eksperiment til en integreret del af den daglige arbejdsgang. Kombinationen gør værktøjet til andet end en container-motor. Det er blevet et sted, hvor du kan bygge, teste og fejlsøge AI-drevne funktioner uden at forlade det miljø, du allerede kender og har tillid til.

Vil du følge samme udvikling for et andet værktøj i dit team, har vi tidligere gennemgået opsætning af MCP-servere til fire andre AI-assistenter, som deler en del af de samme principper som MCP Toolkit her.

Forudsætninger: Dette skal du bruge

Før du installerer noget, skal maskinen leve op til nogle grundlæggende krav. Softwaren læner sig op ad virtualisering, uanset om du kører Windows, macOS eller Linux, så manglende hardware-understøttelse er den hyppigste årsag til fejlslagne installationer. Sidder du bag en virksomheds-VPN eller en streng firewall, kan det desuden give problemer med at hente images fra Docker Hub, så tjek proxy-indstillingerne, før du melder fejl.

KravWindowsmacOSLinux
Understøttet OSWindows 10/11 (64-bit)Nyere macOS-versioner (Intel og Apple Silicon)Ubuntu, Debian, Fedora m.fl.
VirtualiseringWSL2 eller Hyper-VApple Hypervisor FrameworkKVM
Anbefalet RAMMin. 8 GB, mere ved AI-modellerMin. 8 GB, 16 GB+ ved lokale LLM’erMin. 8 GB
DiskpladsFlere GB frit plus plads til images og modellerFlere GB frit plus plads til images og modellerFlere GB frit plus plads til images og modeller
GPU-acceleration (AI)Delvis, afhænger af backendApple Silicon med Metal (vLLM-Metal)Afhænger af drivere

Docker anbefaler selv, at du tjekker den officielle side for systemkrav, før du går videre, da minimumskravene justeres løbende i takt med nye funktioner som Model Runner. Har du en Mac med Apple Silicon, får du den bedste AI-ydelse, fordi virksomheden har bygget understøttelse af vLLM-Metal specifikt til den chipfamilie. Kører du en ældre bærbar med kun 8 GB RAM i alt, kan du sagtens bruge byggefunktionerne, men du bør vente med Model Runner, til du enten opgraderer eller arbejder fra en kraftigere maskine.

Trin 1: Download og installer

Gå til den officielle downloadside og hent installationsfilen til dit styresystem. Undgå at hente filen fra tredjepartssider, uanset hvor hurtigt det virker, fordi manipulerede installere er en kendt vektor for malware rettet mod udviklere med adgang til produktionssystemer. På Windows kører du den downloadede .exe-fil og følger guiden. På Mac trækker du .dmg-filen til Programmer-mappen. På Linux henter du den relevante pakke (.deb eller .rpm) til din distribution og installerer den via din pakkehåndtering fremfor at bygge fra kildekode.

# Verificér installationen efter genstart
docker --version
docker compose version

En vellykket kørsel giver output i stil med dette:

Docker version 28.x.x, build a1b2c3d
Docker Compose version v2.x.x

Får du to versionsnumre tilbage uden fejlmeddelelser, er kernen på plads. Første opstart tager typisk et minuts tid, fordi programmet initialiserer sin interne virtuelle maskine og henter et par baggrundskomponenter, før ikonet i statusbaren skifter fra gul til grøn.

Trin 2: Konfigurer WSL2 eller hypervisor

På Windows er WSL2 rygraden i hele opsætningen. Er WSL2 ikke installeret, beder installationsguiden dig om at aktivere det, men du kan også gøre det manuelt fra en administrator-terminal, hvilket er hurtigere, hvis du allerede ved, at maskinen mangler komponenten.

wsl --install
wsl --set-default-version 2
wsl --status

Kør derefter en genstart, åbn programmet igen og bekræft under Settings > General, at “Use the WSL 2 based engine” er markeret. På Mac skal du blot sikre, at ingen anden hypervisor, som ældre VirtualBox-opsætninger, blokerer Apples eget hypervisor-framework. På Linux afhænger konfigurationen af, om du kører Docker Engine direkte eller en Desktop-variant til Linux, som pakker det hele ind i en letvægts-VM med sin egen ressourcestyring adskilt fra resten af systemet.

Trin 3: Vælg den rigtige licens

Docker Desktop er gratis for enkeltpersoner, undervisning, non-kommerciel open source og små virksomheder under 250 ansatte og 10 millioner dollar i årlig omsætning. Er din virksomhed større end det, kræver kommerciel brug et betalt abonnement, uanset hvor lidt platformen reelt bruges i det daglige arbejde. Priserne i 2026 ser sådan ud ifølge den officielle prisside:

PlanPris pr. bruger/md. (månedlig)Pris pr. bruger/md. (årlig)Målgruppe
Personal$0$0Enkeltpersoner, studerende, små virksomheder
Pro$11$9Udviklere med behov for flere Docker Hub-træk
Team$16$15Teams med SSO og samarbejdsfunktioner
Business$24$24Virksomheder med centraliseret styring og sikkerhed

Vælg din plan under det første login, eller skift senere via Settings. Alle fire planer inkluderer selve applikationen med samme container-motor under motorhjelmen. Forskellen ligger i Docker Hub-grænser, administrationsværktøjer til teams og sikkerhedsfunktioner som centraliseret politikstyring, ikke i selve evnen til at bygge og køre containere.

Trin 4: Kør din første container

Test installationen med et klassisk eksempel, før du kaster dig over egne projekter. Åbn en terminal og kør:

docker run -d -p 8080:80 --name mit-testsite nginx:latest
docker ps

docker ps bør nu vise noget i denne stil:

CONTAINER ID   IMAGE          STATUS         PORTS                  NAMES
a1b2c3d4e5f6   nginx:latest   Up 8 seconds   0.0.0.0:8080->80/tcp   mit-testsite

Går du til localhost:8080 i browseren, ser du nginx’s standardside. Det bekræfter, at netværk, portmapping og selve container-runtime fungerer sammen som forventet. Stop containeren igen med docker stop mit-testsite, når du er tilfreds, så den ikke ligger og optager en port i baggrunden.

Trin 5: Skriv din første Dockerfile

De fleste projekter starter med en Dockerfile, der beskriver, hvordan applikationen bygges fra bunden. Her er et simpelt eksempel til en Node.js-app:

FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Byg og kør den med:

docker build -t min-app:1.0 .
docker run -d -p 3000:3000 min-app:1.0

Læg mærke til rækkefølgen af kommandoerne. Ved at kopiere package.json før resten af koden udnytter du lag-cachen, så genopbygninger går markant hurtigere, hver gang du kun ændrer kildekode og ikke afhængigheder. Ombytter du rækkefølgen, ryger hele cachen ved hver eneste kodeændring, og du ender med at vente på en fuld genopbygning, selv for en enkelt linjes rettelse.

Trin 6: Docker Compose til flere containere

De fleste rigtige applikationer består af mere end én container. Compose, som følger med installationen, lader dig beskrive hele stakken i én fil i stedet for at huske en lang række separate docker run-kommandoer.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: skiftmig
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Start hele stakken med docker compose up -d og tjek status med docker compose ps, som viser begge tjenester med status “running”, hvis alt gik godt. Compose-versionen følger med selve installationen, så kør docker compose version, hvis du vil se præcis, hvilken build du kører, inden du fejlretter en syntaksfejl, der reelt skyldes en forældet version. Vil du følge logfilerne fra begge tjenester samtidig, mens du udvikler, holder docker compose logs -f dem samlet i én strøm i stedet for at du skal skifte mellem to terminalvinduer hver gang noget fejler.

Trin 7: Aktivér Model Runner til lokale AI-modeller

Model Runner giver dig mulighed for at køre sprogmodeller lokalt gennem samme værktøj, du allerede bruger til containere, uden at du selv skal styre Python-miljøer eller GPU-drivere manuelt. Funktionen understøtter blandt andet vLLM-Metal-backenden på Mac med Apple Silicon, hvilket giver GPU-accelereret inferens via Metal-API’et frem for at falde tilbage på CPU alene. Aktivér den under Settings > Features in development > Enable Docker Model Runner, og hent derefter en model:

docker model pull ai/llama3.2
docker model run ai/llama3.2 "Skriv tre linjer om containere"

Modellen kører i baggrunden, og du kan integrere den i dine egne applikationer via en lokal API-endpoint i stedet for at sende kildekode og forespørgsler til en ekstern sky-tjeneste. Det er relevant for teams med krav om, at kode og data ikke forlader virksomhedens netværk, hvilket flere nordiske virksomheder har skærpet fokus på efter øget GDPR-håndhævelse i 2025 og 2026. En lokal model svarer typisk langsommere end en stor sky-model, men for interne værktøjer som logfilsanalyse eller kodeforklaring er forskellen sjældent mærkbar i praksis.

GDPR og lokale AI-modeller i praksis

For danske og nordiske virksomheder er spørgsmålet om, hvor kildekode og kundedata rent fysisk befinder sig, sjældent akademisk. Sender du en logfil med personhenførbare oplysninger til en ekstern sky-model for at få den forklaret, har du potentielt overført persondata til en tredjepart uden en klar databehandleraftale. Kører den samme analyse gennem Model Runner, forlader dataene aldrig din egen maskine eller virksomhedens interne netværk, hvilket flytter en stor del af den juridiske risikovurdering fra “hvilken databehandleraftale dækker dette” til “er vores egen infrastruktur sikret ordentligt”. Det gør ikke automatisk alt lovligt, men det fjerner et helt lag af tredjepartsafhængighed, som ellers kræver dokumentation, hver gang Datatilsynet eller en revisor spørger ind til, hvor virksomhedens data reelt bevæger sig hen. Brug derfor lokale modeller til opgaver, hvor data er følsomme, og gem de større sky-modeller til opgaver, hvor svarkvalitet vejer tungere end datastedet.

Trin 8: Opsæt MCP Toolkit og forbind til din AI-klient

MCP Toolkit er samlingen af Model Context Protocol-servere, som du kan køre lokalt og koble til AI-værktøjer som Claude Desktop eller MCP-understøttede udvidelser i VS Code. Docker beskriver selv fordelen sådan i deres officielle blog om udgivelse 4.42:

“Integrationen giver øjeblikkelig adgang til over 100 MCP-servere uden ekstra opsætning, så du kan eksperimentere med AI-funktioner direkte i din Docker-workflow.”

Docker, produktteam (docker.com)

Sådan slår du det til: Åbn Gordon, klik på knappen “Tools”, og slå MCP Toolkit-indstillingen til. Herefter viser fanen MCP Toolkit alle værktøjer fra de MCP-servere, du har konfigureret, sorteret efter kategori. Vil du forbinde en server til Claude Desktop, tilføjer du serverens lokale adresse i Claude Desktop’s konfigurationsfil under MCP-servere, og genstarter derefter klienten, så den henter den nye værktøjsliste ved næste opstart.

{
  "mcpServers": {
    "docker-toolkit": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

Gemmer du filen og genstarter Claude Desktop, dukker et nyt værktøjsikon op i chatvinduet, som viser antallet af tilgængelige MCP-værktøjer. Er tallet nul, er gateway-processen typisk ikke startet, hvilket vi vender tilbage til i fejlfindingsafsnittet. Har du flere projekter, der hver især skal bruge forskellige MCP-servere, kan du oprette separate konfigurationsprofiler i stedet for at slå alle servere til samtidig, hvilket både holder værktøjslisten overskuelig og reducerer den mængde ressourcer, Gordon skal holde styr på i baggrunden.

Trin 9: Brug Gordon, den indbyggede AI-agent

Gordon gik i beta i marts 2026 og er blevet Docker’s svar på, at fejlsøgning af containere ofte kræver kontekst, som en generisk chatbot ikke har adgang til. Den officielle dokumentation formulerer det kort:

“Gordon er en AI-drevet assistent, der handler direkte på dine Docker-workflows.”

Docker, officiel dokumentation (docs.docker.com)

I praksis betyder det, at Gordon kender dine kørende containere, dine images og din lokale konfiguration, når du beder om hjælp. Skriver du “generér en Dockerfile til denne mappe” eller “hvorfor fejler dette build”, trækker agenten på den lokale kontekst i stedet for at gætte ud fra generiske eksempler, den er trænet på. Kombineret med MCP Toolkit fra Trin 8 kan Gordon også kalde eksterne værktøjer, som for eksempel slå op i en database eller læse en logfil, uden at du selv skal skrive integrationskoden. Docker’s egen marts-opdatering understreger, at retningen er “sikre fundamenter og AI-agenter i produktion”, hvilket signalerer, at Gordon er tænkt som mere end et sjovt sidetilbud.

Trin 10: Styr ressourcer, CPU og diskgrænser

Lokale AI-modeller og MCP-servere lægger et andet pres på maskinen end almindelige web-containere. Gå til Settings > Resources og sæt eksplicitte grænser for CPU-kerner, RAM og diskstørrelse i stedet for at lade programmet bruge standardværdierne, som ofte er sat konservativt til almindelig webudvikling. Kører du Model Runner med større modeller, bør du reservere mindst 8 GB RAM alene til AI-arbejdsbelastningen, oven i det, resten af dine containere kræver. Uden den grænse kan en tung model spise så meget hukommelse, at resten af systemet begynder at swappe, hvilket mærkes som generel træghed i hele operativsystemet, ikke kun i terminalen.

Trin 11: Netværk og volumes til vedvarende data

Containere er som udgangspunkt flygtige, så data, der skal overleve en genstart, hører hjemme i et volume, ikke i selve containerens filsystem. I Compose-eksemplet fra Trin 6 sørger db-data-volumet for, at PostgreSQL-databasen beholder sine data, selv om du genstarter containeren eller opdaterer imaget til en nyere version. Til netværk opretter Compose automatisk et internt netværk, hvor web kan nå db på tjenestenavnet alene, uden at du selv skal styre IP-adresser manuelt. Skal flere Compose-projekter dele netværk, kan du oprette et eksternt netværk med docker network create og referere til det som external: true i dine compose-filer, så to separate projekter kan tale sammen uden at blive slået sammen til én stak.

Trin 12: Sikkerhed, opdateringer og image-scanning

Docker offentliggør ikke en løbende liste over specifikke CVE-numre for skrivebordsklienten i deres marketingmateriale, så den mest pålidelige kilde til aktuelle sårbarheder er de officielle sikkerhedssider og de tilhørende sikkerhedsrådgivninger på GitHub. Det du selv kan gøre proaktivt: Hold installationen opdateret til seneste build, da den ugentlige udgivelsestakt i 2026 typisk indeholder sikkerhedsrettelser sammen med nye funktioner, så en forsinket opdatering også er en forsinket patch. Brug desuden Docker Scout til at scanne dine images for sårbare afhængigheder, før du sender dem videre til et register, dine kolleger trækker fra:

docker scout cves min-app:1.0

Kør containere uden root, hvor det er muligt, ved at tilføje en USER-linje i din Dockerfile, og undgå at mountede volumes deler mere af filsystemet, end applikationen faktisk skal bruge. Begge dele er små ændringer, der reducerer, hvad en angriber kan nå at gøre, hvis en container alligevel bliver kompromitteret.

Trin 13: Byg det komplette projekt

Med de forrige trin på plads kan du samle det hele i ét fungerende projekt: en Node.js-webapp, en PostgreSQL-database og en lokal AI-model, der besvarer spørgsmål om projektets egne logfiler via Gordon og MCP Toolkit. Strukturen ser sådan ud:

mit-projekt/
├── Dockerfile
├── docker-compose.yml
├── package.json
├── server.js
└── mcp/
    └── log-server.js

Kør docker compose up -d for at starte web-appen og databasen, aktivér Model Runner fra Trin 7 til selve AI-svarene, og registrér din lokale log-server som en MCP-server, så Gordon kan læse logfiler direkte, når du spørger om fejl i produktionen. Resultatet er en lokal udviklingsstak, hvor kode, database og AI-assistance kører side om side uden afhængighed af en ekstern sky-tjeneste. Det er en solid base at bygge videre på, uanset om det endelige mål er en produktionsdeployering til Kubernetes eller blot et hurtigere loop i det daglige udviklingsarbejde.

Del billeder via Docker Hub

Når imaget fra Trin 5 fungerer lokalt, vil de fleste teams dele det, så andre kan trække samme version uden selv at bygge den. Log ind fra terminalen, tag imaget med dit brugernavn, og skub det op:

docker login
docker tag min-app:1.0 dittbrugernavn/min-app:1.0
docker push dittbrugernavn/min-app:1.0

Personal-planen giver et begrænset antal gratis træk pr. dag fra offentlige repositories, mens Pro og opefter hæver den grænse markant. Arbejder du med private images i et team, bør du oprette en organisation på Docker Hub i stedet for at dele login-oplysninger til en personlig konto, da det gør det langt nemmere at fjerne en enkelt medarbejders adgang, den dag vedkommende skifter job. Vil du undgå Docker Hub helt, kan du i stedet pege Compose-filerne mod et privat register, hvad enten det er en selvhostet løsning eller en skytjenestes indbyggede container-registry, uden at ændre noget i selve Dockerfilen.

Automatisér byg og scanning med GitHub Actions

Skal projektet fra Trin 13 bygges automatisk ved hvert commit, er en simpel GitHub Actions-workflow ofte nok til at komme i gang. Eksemplet herunder bygger imaget og kører en sårbarhedsscanning, før noget bliver skubbet videre:

name: build-and-scan
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Byg image
        run: docker build -t min-app:${{ github.sha }} .
      - name: Scan for sårbarheder
        run: docker scout cves min-app:${{ github.sha }}

Fejler scanningen på en kritisk sårbarhed, stopper workflowet automatisk, før imaget når frem til et register, resten af teamet trækker fra. Det flytter sikkerhedsarbejdet fra en manuel opgave, nogen glemmer under tidspres, til et trin, der kører hver eneste gang, uden at nogen skal huske det.

Almindelige faldgruber

De fleste problemer, nye brugere støder på, handler ikke om buggy software, men om vaner, der ikke er opdateret til, hvordan platformen fungerer i 2026. Flere af dem koster kun et par minutters irritation, men et par af dem, som licens-faldgruben, kan koste en virksomhed en ubehagelig samtale med indkøbsafdelingen måneder senere. Her er de mest almindelige:

FaldgrubeKonsekvensLøsning
For lav RAM-grænse ved kørsel af Model RunnerModellen crasher eller svarer meget langsomtSæt en eksplicit RAM-grænse på mindst 8 GB til AI-arbejdsbelastning
Flere hypervisorer aktive samtidigProgrammet starter ikke, eller virtualisering fejlerDeaktivér konkurrerende hypervisorer som ældre VirtualBox-opsætninger
Ingen oprydning af gamle images og volumesDiskplads forsvinder gradvist over ugerKør docker system prune jævnligt og gennemgå ubrugte volumes
Kører containere som root uden grundUnødvendig sikkerhedsrisiko ved kompromitteringTilføj en dedikeret USER-linje i Dockerfilen
Overser licenskravet for større virksomhederKommerciel brug uden gyldigt abonnementTjek om organisationen ligger over 250 ansatte eller 10 mio. dollar i omsætning
Ignorerer ugentlige opdateringerGår glip af sikkerhedsrettelser og nye AI-funktionerOpdatér løbende i stedet for at vente på store versionsspring
Blander bind mounts og navngivne volumes tilfældigtUforudsigelig performance og svært at rydde opBrug navngivne volumes til data, bind mounts kun til kildekode under udvikling

Fejlfinding: Løsninger på typiske problemer

Støder du på fejl, er det som regel én af følgende ti scenarier, der er årsagen. Gennemgå listen, før du bruger tid på at søge efter en mere eksotisk forklaring, da langt de fleste supportsager i praksis løses af et af de ti punkter nedenfor uden behov for at grave i logfiler eller åbne en sag hos Docker selv:

ProblemSandsynlig årsagLøsning
WSL2-installation fejler på WindowsVirtualisering slået fra i BIOSAktivér Virtualization Technology i BIOS, kør derefter wsl --install igen
“Docker Desktop starting…” hænger fastKonflikt med Hyper-V eller korrupt VM-stateGenstart Docker-tjenesten, eller nulstil til fabriksindstillinger under Troubleshoot
Port allerede i brugEn anden proces eller container bruger samme portSkift portmapping, f.eks. -p 8081:80, eller stop den konfliktende proces
“No space left on device”Den virtuelle disk er fyldt opKør docker system prune -a --volumes og øg diskgrænsen under Settings > Resources
Langsom filsynkronisering på MacBind mounts over store mappetræerBrug navngivne volumes til afhængigheder som node_modules i stedet for direkte bind mounts
MCP-server vises ikke i GordonMCP Toolkit ikke aktiveret, eller gateway-processen ikke startetGenaktivér MCP-indstillingen under Gordons Tools-menu og genstart programmet
Model Runner finder ikke GPU på Apple SiliconvLLM-Metal-backend ikke valgtVælg vLLM-Metal eksplicit i Model Runner-indstillingerne
Compose-fil giver versionsfejlForældet syntaks fra ældre Compose-versionerFjern det gamle version:-felt og kør docker compose version for at bekræfte aktuel build
“Permission denied” mod Docker-socket på LinuxBrugeren er ikke i docker-gruppenKør sudo usermod -aG docker $USER og log ud og ind igen
Build går langsomt trods cacheDårlig laglægning i DockerfileFlyt sjældent ændrede kommandoer (afhængigheder) øverst, kildekode nederst

Avancerede tips til produktion

Når projektet skal videre fra din lokale maskine, er der et par vaner, der betaler sig over tid. Brug multi-stage builds, så det endelige image kun indeholder det, applikationen faktisk skal bruge for at køre, ikke hele build-værktøjskæden med kompilatorer og testrammer. Sæt eksplicitte ressourcegrænser (--memory, --cpus) på dine containere i produktionslignende miljøer, så en enkelt lækkende proces ikke kan spise hele hostens kapacitet og trække andre tjenester med sig ned. Automatisér Docker Scout-scanning som en del af din CI-pipeline, i stedet for kun at køre det manuelt en gang imellem, så sårbare baseimages fanges før merge, ikke efter udrulning. Vælg desuden faste versionstags frem for latest i produktionsmiljøer, da latest kan pege på et andet image i morgen, end det gør i dag, hvilket gør en fejl svær at reproducere, når to teammedlemmer tilsyneladende kører “det samme” image.

Overvej desuden at holde Model Runner og MCP Toolkit adskilt fra dine produktionscontainere. De to funktioner er tænkt til lokal udvikling og fejlsøgning, ikke som en del af den kørende produktionsstak, og de kan trække ressourcer, der ellers var reserveret til den faktiske applikation. Kør i stedet dine sprogmodeller på dedikeret infrastruktur, hvis de skal indgå i en produktionsflow, og brug den lokale opsætning udelukkende til udvikling og test. Log desuden hvilke MCP-servere og modeller, der er aktive i teamets fælles udviklingsmiljøer, så en ny sikkerhedsgennemgang ikke skal starte med at kortlægge, hvad der overhovedet kører.

Ydeevne: Sådan holder du build-tider nede

Langsomme builds er den klage, der oftest lander i teamets Slack-kanal, og løsningen ligger sjældent i at købe en kraftigere maskine. Start med at slå BuildKit til, hvis det ikke allerede er standard i din installation, da det bygger lag parallelt i stedet for i streng rækkefølge. Brug .dockerignore aktivt, så mapper som node_modules, .git og lokale testrapporter aldrig bliver sendt med ind i build-konteksten, hvilket alene kan barbere flere sekunder af hver eneste build på et mellemstort projekt. Genbrug baseimages på tværs af projekter i stedet for at lade hvert team vælge sit eget, så Docker kan genbruge de samme cachede lag frem for at hente identiske afhængigheder igen og igen. Endelig er det værd at rydde build-cachen med jævne mellemrum, ikke fordi den er farlig, men fordi en meget stor cache i sig selv kan begynde at bremse selve cache-opslaget. Kør docker builder prune som en fast rutine hver anden uge, i stedet for at vente til disken er fuld og du alligevel er tvunget til at rydde op midt i en deadline.

Onboarding af nye teammedlemmer

En overset del af opsætningen er, hvor let det er at give en ny kollega samme miljø som resten af teamet. Skriv en kort README med de præcise kommandoer fra Trin 1 til Trin 6, i stedet for at forudsætte, at alle kender rækkefølgen. Læg gerne en delt .env.example-fil ved siden af docker-compose-filen, så nye medlemmer ikke skal gætte, hvilke miljøvariabler der forventes. Vil den nye kollega også bruge Gordon og MCP Toolkit fra dag ét, er det en god idé at dele den fungerende MCP-konfiguration fra Trin 8 som en del af projektets opsætningsdokumentation, i stedet for at lade alle finde deres egen vej til de samme indstillinger. Det sparer typisk en hel formiddags frem-og-tilbage i chatten, sammenlignet med at overlade det til trial and error.

Docker Desktop vs Podman Desktop

Podman Desktop nævnes ofte som det gratis alternativ, når licensvilkårene for større virksomheder kommer på tale. Forskellen ligger primært i arkitektur og pris, ikke i grundfunktionerne, som begge dækker godt for almindelig containerudvikling.

EgenskabDocker DesktopPodman Desktop
Pris for store virksomheder$9-$24 pr. bruger/md.Gratis
Rootless som standardNej som standardJa
Indbygget AI-agentJa, Gordon (beta)Nej, kræver eksterne værktøjer
MCP-integrationJa, MCP Toolkit med 100+ servereBegrænset, afhænger af tredjepartsudvidelser
Compose-understøttelseIndbyggetVia podman-compose eller kompatibilitetslag

Er dit team under grænsen for gratis kommerciel brug, og lægger du vægt på AI-funktionerne, giver Docker mest værdi for pengene lige nu. Er I en større organisation, der primært vil undgå licensomkostninger, er Podman Desktop et reelt alternativ, men uden Gordon og MCP Toolkit skal AI-delen af arbejdsgangen bygges op af andre værktøjer i stedet, hvilket ofte betyder mere selv-konfiguration. En pragmatisk mellemvej, flere teams vælger, er at lade den enkelte udvikler bruge det værktøj, vedkommende allerede er tryg ved, så længe begge dele understøtter samme Compose-filformat og dermed ikke splitter projektets konfiguration i to spor.

Migrering fra en ældre version

Kører du stadig en installation fra 2024 eller tidligt 2025, er springet til 4.88.0 større, end versionsnummeret antyder. Tag et bevidst valg om rækkefølgen, i stedet for blot at klikke “opdatér” midt i en travl uge. Eksportér først dine eksisterende Compose-projekter og notér, hvilke navngivne volumes de bruger, så du kan bekræfte, at data er intakt efter opgraderingen. Opdatér derefter selve applikationen, og genstart maskinen, før du rører ved noget andet. Kontrollér, at WSL2-integrationen fra Trin 2 stadig peger på de rigtige Linux-distributioner under Settings > Resources > WSL Integration, da denne indstilling af og til nulstilles ved større opdateringer. Til sidst kan du aktivere de nyere funktioner som Model Runner og MCP Toolkit én ad gangen, så du kan isolere eventuelle problemer til den specifikke funktion, du netop har slået til, i stedet for at fejlsøge tre nye ting på samme tid.

Sådan passer opsætningen ind i resten af værktøjskassen

De fleste teams kombinerer containerplatformen med en editor og en AI-kodeassistent. Kører du allerede VS Code med en opdateret opsætning, kan MCP-serverne fra Trin 8 genbruges direkte i editorens egne AI-udvidelser, så du ikke skal konfigurere de samme værktøjer to gange. Bruger du i stedet en CLI-baseret assistent som Codex CLI eller Gemini CLI, kan disse pege på de samme lokale MCP-gateways, hvilket betyder, at investeringen i at sætte MCP Toolkit op korrekt betaler sig på tværs af hele udviklingsmiljøet, ikke kun inde i selve containerværktøjet. Kører nogen i teamet i stedet GitHub Copilot med agent-plugins, kan de samme MCP-servere ofte tilføjes der også, så et team, der bruger tre forskellige AI-assistenter, stadig kan dele én fælles kilde til værktøjer og kontekst i stedet for at vedligeholde tre separate opsætninger med samme funktion.

Ofte stillede spørgsmål

Er Docker Desktop gratis?
Ja, for enkeltpersoner, undervisning, non-kommerciel open source og små virksomheder under 250 ansatte og 10 millioner dollar i årlig omsætning. Større virksomheder skal bruge Pro, Team eller Business.

Hvad er forskellen på Docker Desktop og Docker Engine?
Engine er selve container-runtimet, mens Desktop-applikationen er en fuld pakke med grafisk interface, indbygget Compose, Model Runner, MCP Toolkit og Gordon oven på Engine.

Hvad gør Gordon konkret?
Gordon er den indbyggede AI-agent, der kender din lokale container-kontekst og kan generere Dockerfiles, fejlsøge builds og foreslå rettelser direkte i det grafiske interface.

Kræver Model Runner internetadgang?
Kun til at hente modellen første gang. Selve inferensen kører lokalt på din maskine, hvilket er relevant, hvis din organisation har krav om, at kode og data ikke forlader netværket.

Hvor mange MCP-servere er der i MCP Toolkit?
Ifølge Docker giver integrationen adgang til over 100 MCP-servere uden ekstra opsætning, klar til brug i Gordon eller andre MCP-kompatible AI-klienter.

Hvorfor fejler installationen på Windows lige efter opsætning?
Den hyppigste årsag er, at WSL2 eller virtualisering i BIOS ikke er aktiveret. Tjek begge dele, før du fejlsøger videre i selve applikationen.

Er det sikkert at køre lokale AI-modeller gennem platformen?
Modellens kørsel isoleres i samme container-arkitektur som resten af platformen. Hold dog installationen opdateret, og følg de officielle sikkerhedsrådgivninger for at være ajour med kendte sårbarheder.

Kan jeg bruge MCP Toolkit sammen med VS Code?
Ja, MCP-kompatible udvidelser i VS Code kan pege på de samme lokale MCP-servere, som du kører gennem Docker, så du ikke behøver at duplikere opsætningen i to forskellige værktøjer.

Kan jeg køre applikationen på en billig bærbar uden dedikeret GPU?
Ja til almindelig containerudvikling, som kun kræver CPU og RAM. Vil du også køre Model Runner med større modeller, mærker du dog hurtigt forskellen uden en Apple Silicon-chip eller en dedikeret GPU, så overvej at holde AI-arbejdsbelastningen til mindre modeller på ældre hardware.

Hvordan opdaterer jeg til den nyeste version?
Applikationen tjekker selv for opdateringer og viser en notifikation, når en ny build som 4.88.0 er klar. Du kan også tjekke manuelt under Settings, eller gå direkte til den officielle udgivelsesside for at se, hvad der er ændret, før du opdaterer en maskine, der kører vigtige lokale tjenester.

Relateret dækning

Se også vores samlede dækning af udviklerværktøjer og AI-kodning for flere opsætningsguider i samme kategori.