DASH is developed on Linux because the official self-hosted server package ships as Linux containers. Other platforms can still operate the stack when they provide a real Linux Docker engine.
Recommended baseline:
- x86_64 Linux host with AVX2.
- Docker Engine with the Compose plugin.
- Local filesystem with enough IOPS for Postgres plus the selected map count.
- Public inbound UDP/TCP forwarding for game traffic.
- Private LAN/VPN-only access for the admin panel.
Known-good operator shell tools:
docker compose version
jq --version
rg --version
openssl versionUbuntu/Debian:
sudo apt-get update
sudo apt-get install -y ca-certificates curl jq ripgrep openssl rsyncFedora/RHEL-family:
sudo dnf install -y jq ripgrep openssl rsyncArch-family:
sudo pacman -S --needed jq ripgrep openssl rsyncInstall Docker from your distribution or Docker's official packages. The helper scripts call docker compose, not the legacy docker-compose binary.
Do not try to run the game containers directly on native Windows. Use one of these patterns:
- Dedicated Linux server on the LAN.
- Windows workstation with SSH into a Linux server.
- WSL2 only for repo editing and operator shell work, with Docker Engine backed by a Linux VM.
The official Steam tool can be downloaded on a Windows machine, but the image tarballs and runtime should be moved to the Linux host. Do not commit Steam package files or copied image tarballs into this repo.
Path translation matters. Put the repo and runtime data on the Linux filesystem, not under a Windows-mounted path such as /mnt/c/..., because Postgres and high-churn container I/O perform poorly there.
Use macOS as an operator workstation, not as the recommended server host. Docker Desktop can run Linux containers, but host networking, port forwarding, filesystem performance, and long-running service management differ enough that a dedicated Linux host is simpler.
Recommended pattern:
ssh dune-host.example.lan
cd /srv/DuneAwakeningSelfHost
./scripts/status.sh .envIf you edit from macOS, commit only repo files. Keep .env, data/, backups, and Steam package contents on the Linux host.
Some scripts accept:
CONTAINER_RUNTIME=podmanPodman compatibility is best-effort. Validate Compose networking, published UDP ports, container DNS, health checks, and volume ownership before trusting it for live operation.
NAS storage is fine for secondary backups. Avoid running live Postgres data over SMB/NFS unless you have already validated latency, locking semantics, and crash recovery. Prefer local SSD/NVMe for data/postgres.
Virtual machines work well when:
- CPU flags expose AVX2 to the guest.
- The VM has stable bridged networking or explicit port forwards.
- Disk cache/writeback policy is understood.
- Host shutdown hooks stop the stack cleanly or snapshots are crash-consistent.
A predictable Linux layout makes scripts and timers easier to reason about:
/opt/dash/releases/<commit> immutable packaged releases
/opt/dash/current atomically selected release
/var/lib/dash private shared runtime state/config/backups
/srv/dune-steam-server optional Steam tool mirror
/etc/dash local-only host/backup/HA configuration
A traditional repo checkout remains supported. The immutable layout is created
by scripts/install-release.sh and packaging/ansible; see
docs/deployment-packaging.md.
The repo itself assumes relative paths where possible. Installer scripts render absolute paths into systemd units so the checkout can live elsewhere.
Before startup on a new host, run:
./scripts/bootstrap-checklist.sh .envIt is read-only and reports missing tools, placeholder env values, and common packaging mistakes.