Docker game server: draaien in een draagbare container

Een Docker game server opzetten maakt je server los van afhankelijkheid van één besturingssysteem of één machine: elke dependency, versie en configuratie wordt in een image verpakt, zodat de server overal waar je hem heen verplaatst op dezelfde manier draait. Je zegt nooit meer "het werkte op mijn machine maar wilde niet starten op de VPS". In dit artikel bekijken we de logica achter het containeriseren van een game server, hoe je persistente savedata beschermt, port mapping, automatisch herstarten, en hoe je alles back-upt en naar een andere machine verhuist — allemaal met praktische voorbeelden.

Waarom een game server containeriseren?

In een klassieke opzet zet je de server op een kale machine, installeer je handmatig de juiste runtime (Java, .NET, een specifieke glibc-versie, enz.) en schrijf je servicebestanden. Het probleem is dat deze opzet specifiek is voor die machine. Docker draait dat om:

• Draagbaarheid: dezelfde image draait identiek op je ontwikkelmachine, op een VPS en op een back-upserver.
• Isolatie: de server draait in zijn eigen container; hij vervuilt het hostsysteem niet en botst niet met andere services over versies.
• Reproduceerbaarheid: je configuratie leeft in een Dockerfile en een compose.yaml; je kunt de hele opzet met één commando opnieuw bouwen.
• Makkelijk versiebeheer: image-tags (:1.20, :latest) zetten de serverversie vast en laten je terugrollen wanneer nodig.

Een kant-en-klare image of je eigen Dockerfile?

Voor de meeste populaire games bestaan er community-images. Voor Minecraft is bijvoorbeeld itzg/minecraft-server een volwassen en breed gebruikte image die EULA, versie en geheugen via omgevingsvariabelen regelt. Als er een kant-en-klare image is, is die gebruiken de snelste weg. Maar voor een aangepaste of zelfgeschreven server moet je je eigen image bouwen. Voor een eenvoudige Linux-serverbinary ziet een typische Dockerfile er zo uit:

FROM debian:12-slim

# Runtime-afhankelijkheden
RUN apt-get update && apt-get install -y --no-install-recommends \
        ca-certificates libstdc++6 \
    && rm -rf /var/lib/apt/lists/*

# Een aparte gebruiker in plaats van root
RUN useradd --system --create-home --uid 1000 gameserver
USER gameserver
WORKDIR /home/gameserver

# Kopieer de serverbestanden
COPY --chown=gameserver:gameserver ./server/ ./

# Game-poort (voorbeeld: UDP 27015)
EXPOSE 27015/udp

CMD ["./game_server", "--config", "server.cfg"]

Hier zitten een paar goede gewoontes in: bouwen vanaf een -slim basis houdt de image klein, --no-install-recommends schrapt onnodige pakketten, en de server draaien als een niet-root-gebruiker is belangrijk voor de beveiliging. Root binnen een container vergroot het risico op de host.

Persistente data: saves moeten in een volume leven

Dit is het meest kritieke punt. Een container is vluchtig; als hij met docker rm wordt verwijderd, verdwijnt zijn bestandssysteem mee. Als de wereld-save, spelersdata en configuratie binnen de container blijven, raak je bij een update alles kwijt. De oplossing is die mappen te koppelen aan een volume of een hostmap:

docker run -d \
  --name game-server \
  -p 27015:27015/udp \
  -v /srv/game/data:/home/gameserver/data \
  --restart unless-stopped \
  mijn-server:1.0

De clausule -v /srv/game/data:/home/gameserver/data koppelt een persistente map op de host aan de datamap van de container. Nu blijven de saves aan de hostkant, ook als je de container verwijdert, bijwerkt of naar een andere machine verplaatst. Zorg er bij het configureren van je server voor dat het savepad ook echt naar deze gekoppelde map schrijft.

Port mapping: TCP of UDP?

Game servers gebruiken meestal UDP, omdat bij realtime spelen lage latentie belangrijker is dan het opnieuw versturen van verloren pakketten. Sommige servers openen daarnaast een TCP query/RCON-poort. In de -p-vlag moet je het protocol correct opgeven:

• -p 27015:27015/udp — de UDP-poort voor gameverkeer.
• -p 27015:27015/tcp — de TCP-poort voor RCON / queries (indien nodig).

Het getal links is de hostpoort, dat rechts de containerpoort. Als de server van buitenaf niet bereikbaar is, is dit de eerste plek om te kijken: of het protocol is verkeerd (TCP/UDP verwisseld), of de VPS-firewall (bijvoorbeeld ufw) blokkeert de poort.

Een nette opzet met Compose

In plaats van lange docker run-regels op de commandoregel te typen, is het veel duurzamer om de configuratie naar een compose.yaml-bestand te verplaatsen. De volledige definitie van de server staat in één bestand en komt op met docker compose up -d:

services:
  game:
    build: .
    container_name: game-server
    ports:
      - "27015:27015/udp"
    volumes:
      - ./data:/home/gameserver/data
    environment:
      MAX_PLAYERS: "32"
      SERVER_NAME: "Aslain Server"
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "2.0"

De restart: unless-stopped hier zorgt dat de container automatisch weer opkomt, zelfs als de server crasht of de machine herstart — een cruciale instelling voor een game server. Het blok deploy.resources.limits voorkomt dat één game server alle CPU en RAM opslokt en de host vastzet.

Back-uppen en naar een andere server verhuizen

Het mooiste aan de containeraanpak is dat migratie neerkomt op weinig meer dan het kopiëren van de datamap. Omdat de image overal hetzelfde is, hoef je op de nieuwe server alleen de image te pullen/bouwen en de datamap te herstellen:

# Momentopname van de datamap (het veiligst terwijl de server gestopt is)
docker compose stop game
tar czf backup-$(date +%F).tar.gz ./data
docker compose start game

# Op de nieuwe server:
tar xzf backup-2026-06-28.tar.gz
docker compose up -d

Voor minder downtime op een live server kun je eerst het in-game "save"-commando triggeren zodat alles naar schijf wordt geschreven, en daarna de back-up maken. Je kunt deze back-upstap ook koppelen aan een cron-taak om automatisch dagelijkse back-ups te maken.

Veelgestelde vragen

Is er prestatieverlies bij een Docker game server?

Op Linux is Docker geen virtuele machine; het gebruikt een lichte isolatielaag die de kernel met de host deelt. De meetbare overhead voor CPU en geheugen is zeer laag en veroorzaakt geen latentie die spelers zouden voelen. Aan de netwerkkant voegt het standaard bridge-netwerk een kleine NAT-overhead toe; wil je dat niet, dan kun je poorten direct op de host openstellen met network_mode: host.

Verdwijnt mijn wereld-save als de container wordt verwijderd?

Nee, als je de data aan een volume of een hostmap hebt gekoppeld. Mappen die met -v naar buiten zijn gemount, staan los van de levenscyclus van de container; zelfs als je de container verwijdert en opnieuw aanmaakt, blijven de saves op hun plek. De data buiten de container houden is de allerbelangrijkste regel.

Kan ik ook een Windows game server containeriseren?

Docker is op zijn sterkst op Linux-servers. Een serverbinary die alleen op Windows draait, vereist Windows-containers, een beperktere en omslachtigere weg. In de meeste gevallen haal je het meeste uit Docker door servers te kiezen die een Linux-build hebben.

Wil je je game server naar een container verhuizen? Om de hele opzet samen te plannen — van het schrijven van de Dockerfile tot persistente data, back-ups en VPS-deployment — neem contact met me op.