Overview

This page explains the pieces dzo works with. The rest of the documentation uses these terms.

Building blocks

Host

One Debian trixie machine. dzo runs as the service user dayz. All game servers run as rootless podman containers described by quadlets (systemd unit files for containers) that dzo generates.

Product

A kind of server that Steam delivers, for example dayz-stable (Steam app 223350) or dayz-experimental (app 1042420). Each product is downloaded once and shared by all servers that use it.

Generation

An immutable, downloaded copy of a server build or a workshop mod. A new download always creates a new generation, so the files under a running server never change. Servers switch to a new generation when they restart. Unreferenced generations are cleaned up automatically.

Instance

One DayZ server: its product, map, mods, ports, mission, schedules and data. Every instance has its own btrfs subvolume.

Site repository

A git repository with your configuration: shared mod integrations, overlays and one directory per instance. dzo reads it from a checkout and can commit changes it makes on your behalf, so every change has an author and a history.

Mission

The DayZ mission folder (mpmissions/<map>). The pristine mission comes from a git repository per instance. The live mission is where the game stores the world, and dzo never wipes it. See Missions, integrations and overlays.

Render

The step before every server start: dzo combines the pristine mission, the mod integrations and your overlays into the files the server needs, checks them, and only then writes them into the live mission.

How a start works

  1. systemd starts dzo-<name>.service (generated by dzo).

  2. Before the container starts, dzo renders the instance. If anything fails to validate, the start is aborted and the live mission stays untouched.

  3. The container starts DayZServer with the rendered command line. The server files and each mod are mounted read-only from their generations.

  4. A startup health check waits until the server answers Steam queries (the mission is loaded). Only then does systemd report the service as started.

  5. A liveness check keeps probing. A hung server is killed and restarted.

What runs on the host

Unit

Purpose

dzo-<name>.service

one game server (container)

dzo-restart-<name>.timer

scheduled graceful restarts

dzo-update-check.timer

hourly check for mod updates and new server builds

dzo-backup-prune.timer

daily snapshot retention and database backup

dzo-exporter.service

/metrics for Prometheus and /status for Icinga

dzo-serve.service

the API and the endpoint of the dzo-admin mods (dzo serve); written when an instance runs dzo-admin

dzo-web.service

optional web interface (dzo web), written once the web interface is set up (web.api or web.token)

All periodic work runs as systemd timers. dzo never uses cron.

Principles

  • The live mission is never wiped. It holds the game world and mod data. dzo only updates the files it manages, and backs up a file before it overwrites a change it did not make.

  • Server builds are never updated automatically. A new DayZ version often needs a wipe or new mods, so an administrator upgrades each server on purpose. Mods update automatically according to each instance’s policy.

  • Snapshots before changes. Updates and destructive operations take a btrfs snapshot of the instance first.

  • Everything is observable. Metrics, a status endpoint, Discord notifications and structured logs in journald.