How to orchestrate your MU Online server's services with Docker Compose

MU Online servers traditionally run as a collection of loose processes on a Windows machine: ConnectServer, JoinServer, GameServer, database, and sometimes a separate web panel. That works, but it makes consistent backups, zero-downtime updates, and replicating the environment on another machine harder. Docker Compose solves this by orchestrating all these services as containers defined in a single declarative file, with isolated internal networks and persistent volumes. This tutorial shows how to structure that orchestration in practice, with configuration examples and specific considerations for a MU server stack.

Why containerize a MU Online server

Containerizing brings three concrete gains: (1) reproducibility — the entire environment (database versions, dependencies) is described in a file, not stored in the memory of whoever originally configured the machine; (2) isolation — a database problem doesn't take down the GameServer, and vice versa; (3) portability — moving the whole server to another machine or provider comes down to copying the configuration files and data volumes.

Overview of the service architecture

Recommended directory structure

mu-infra/
├── docker-compose.yml
├── .env
├── db/
│   └── init/            # schema initialization scripts
├── connectserver/
│   └── Data/
├── gameserver/
│   └── Data/
└── web/
    └── (panel code)

Keeping each service in its own folder with a dedicated volume makes both individual backups and isolated component replacement easier.

Example docker-compose.yml

version: "3.9"

services:
  db:
    image: mysql:8.0
    container_name: mu_db
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
      MYSQL_DATABASE: mu_online
    volumes:
      - db_data:/var/lib/mysql
      - ./db/init:/docker-entrypoint-initdb.d
    networks:
      - mu_internal

  connectserver:
    build: ./connectserver
    container_name: mu_connectserver
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "44405:44405"
    networks:
      - mu_internal

  gameserver:
    build: ./gameserver
    container_name: mu_gameserver
    restart: unless-stopped
    depends_on:
      - db
      - connectserver
    ports:
      - "55901:55901"
    volumes:
      - ./gameserver/Data:/app/Data
    networks:
      - mu_internal

  web:
    build: ./web
    container_name: mu_web
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    networks:
      - mu_internal

networks:
  mu_internal:
    driver: bridge

volumes:
  db_data:

Environment variables and the .env file

Never leave database passwords or tokens hardcoded in docker-compose.yml. Centralize them in a .env file at the project root:

DB_ROOT_PASSWORD=change-this-password
DB_USER=mu_app
DB_PASSWORD=another-strong-password
GAMESERVER_PORT=55901

Compose automatically reads the .env file in the same folder and substitutes the ${...} variables referenced in the YAML.

Internal networks and port exposure

All services share the mu_internal network, allowing them to communicate with each other by service name (for example, the GameServer reaches the database via the db host, not localhost). Only the ports actually needed by the game client and the web panel should be mapped to the host with ports: — the database must not have a port exposed externally in production, only accessible through Compose's internal network.

Persisting data with volumes

The named volume db_data ensures the database content survives container recreation (docker compose down followed by up). Bind-mount volumes (like ./gameserver/Data:/app/Data), on the other hand, let you edit GameServer configuration files directly from the host without entering the container — essential for quick adjustments to drop rate, experience, and events.

Database backup routine

Add an auxiliary scheduled backup service, or run a command externally via cron, such as:

docker exec mu_db mysqldump -u root -p"$DB_ROOT_PASSWORD" mu_online > backups/mu_online_$(date +%Y%m%d_%H%M).sql

Automate this with a cron job on the host (or a dedicated container with cron running the same command) and maintain a retention policy — for example, daily backups for the last 14 days and weekly ones for the last 3 months.

Updating services without full downtime

To update just the web panel, for example, without affecting the GameServer:

docker compose build web
docker compose up -d --no-deps web

This rebuilds and restarts only the web container, keeping gameserver, connectserver, and db running normally. Database schema changes, however, require careful coordination — always test in a staging environment with a copy of the database before applying it to production.

Basic container monitoring

Essential commands for day-to-day operation:

Common errors and fixes

Docker Compose orchestration checklist

• Service architecture mapped out (db, connectserver, joinserver, gameserver, web).
• docker-compose.yml with internal networks and only necessary ports exposed.
• Sensitive variables centralized in .env and kept out of version control.
• Named volumes for persistent database data.
• Automated backup routine tested (restore validated at least once).
• Isolated per-service update process documented.
• Basic log and resource-usage monitoring configured.

With the stack orchestrated and reproducible, the natural next step is applying that same infrastructure rigor to the rest of the project — see the tutorial on how to create a MU Online server to review the full configuration of the services you've now containerized.

Frequently asked questions