How to Containerize Your MU Online Server with Docker

Running a MU Online server directly on the operating system works, but it creates a recurring problem: MySQL, .NET/VC++ redistributable, and emulator binary dependencies end up scattered and hard to reproduce on another machine. Containerizing the server with Docker solves this — each component (database, ConnectServer, JoinServer, GameServer, DataServer) runs isolated, with its own dependencies, and the whole environment can be recreated in minutes with a single command. This tutorial shows how to structure a complete docker-compose setup for a MU server, from individual Dockerfiles to data persistence and the internal network between services.

Why containerize a MU Online server

A traditional MU server (based on emulators like MuEmu or IGCN) is made up of several processes that need to run simultaneously and communicate with each other: MySQL, DataServer, JoinServer, ConnectServer, and GameServer. Without containers, migrating this whole set to another machine means manually reinstalling every dependency, reconfiguring paths, and hoping the versions match. With Docker, each piece becomes a versioned image with its dependencies declared in a Dockerfile — the entire environment becomes reproducible, testable on a development machine, and migratable to a new server with docker-compose up.

Prerequisites

• Docker Engine and Docker Compose installed (native Linux, or Docker Desktop with WSL2 on Windows).
• MU emulator binaries (GameServer, ConnectServer, JoinServer, DataServer) already working outside a container, to serve as the base for the Dockerfiles.
• A complete backup of the current database before migrating to the containerized environment.
• Basic knowledge of Docker networking (bridge networks, port exposure).

Overview of the container architecture

All services share an internal Docker network (mu-network), which lets them communicate by service name instead of a fixed IP — essential for portability between development and production environments.

Structuring the docker-compose.yml

version: "3.8"

services:
  mu-mysql:
    image: mysql:5.7
    container_name: mu-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: "strong_password_here"
      MYSQL_DATABASE: "MuOnline"
    volumes:
      - mu-db-data:/var/lib/mysql
      - ./sql/init:/docker-entrypoint-initdb.d
    networks:
      - mu-network
    ports:
      - "3306:3306"

  mu-gameserver:
    build: ./gameserver
    container_name: mu-gameserver
    restart: unless-stopped
    depends_on:
      - mu-mysql
    environment:
      DB_HOST: mu-mysql
      DB_USER: root
      DB_PASS: "strong_password_here"
    volumes:
      - mu-game-logs:/app/logs
    networks:
      - mu-network
    ports:
      - "55901:55901"

networks:
  mu-network:
    driver: bridge

volumes:
  mu-db-data:
  mu-game-logs:
  mu-data-files:

This file is the central piece: it describes every service, their dependencies (depends_on), environment variables, and the shared network.

Writing the GameServer Dockerfile

FROM mcr.microsoft.com/windows/servercore:ltsc2022

WORKDIR /app
COPY ./bin/GameServer.exe .
COPY ./bin/Data/ ./Data/
COPY ./bin/Config/ ./Config/

EXPOSE 55901

CMD ["GameServer.exe"]

For emulators compiled in C++/Delphi for Windows, this is the simplest route: use a Windows Server Core base image and copy the already-compiled binaries. In Linux environments, many admins choose to run the Windows binaries under Wine inside a Linux container, which reduces resource usage compared to a full Windows image.

Data persistence with volumes

Never leave the database or configuration files inside the container's "ephemeral" filesystem. A docker-compose down without named volumes wipes out all player progress. Always declare named volumes (mu-db-data, mu-game-logs) and, when possible, mount host folders directly for configuration files you edit frequently:

volumes:
  - ./config/GameServerInfo.dat:/app/Config/GameServerInfo.dat

This lets you edit the configuration on the host without needing to rebuild the image for every small tweak.

Configuring the internal network between services

Inside the mu-network, each container sees the others by the service name defined in Compose. This means that, in the GameServer's connection string to the database, instead of 127.0.0.1 you use mu-mysql:

[Database]
Host = mu-mysql
Port = 3306
User = root
Password = strong_password_here

This is the most common adjustment when migrating an existing configuration to Docker: any reference to localhost for the database needs to become the corresponding service name.

Backing up and restoring the containerized database

# Backup
docker exec mu-mysql mysqldump -u root -pstrong_password_here MuOnline > backup_$(date +%F).sql

# Restore
docker exec -i mu-mysql mysql -u root -pstrong_password_here MuOnline < backup_2026-07-30.sql

Automate this command with a cron job on the host, writing the .sql files outside the container — that way, even if you destroy and recreate the MySQL container, the backup stays safe on the host.

Logs and container monitoring

Use docker logs -f mu-gameserver to follow the GameServer's behavior in real time, and docker stats to monitor CPU/memory usage of each service. For production, it's worth integrating an observability stack (Prometheus + Grafana) collecting container metrics, especially GameServer CPU usage during peak hours, which tends to be the bottleneck on servers with many simultaneous players.

Updating the server without long downtime

When releasing a new emulator version or a configuration fix, the recommended flow is: rebuild only the changed service's image (docker-compose build mu-gameserver), then recreate only that container (docker-compose up -d --no-deps mu-gameserver), keeping MySQL and the other services running. This reduces downtime to seconds, instead of taking down the whole stack for a single fix.

Common errors and fixes

Containerization checklist

• Docker and Docker Compose installed and tested.
• Dockerfiles created for each service (MySQL, GameServer, ConnectServer, JoinServer).
• docker-compose.yml with internal network and named volumes defined.
• Connection strings updated to service names.
• Automated and tested database backup routine.
• Logs and metrics for each container being monitored.
• Zero-downtime update process documented and tested.

With the server running in containers, the natural next step is standardizing this environment as the base for new deployments — even for those setting up the project from scratch. See the MU Online server creation tutorial to align this containerized infrastructure with the emulator fundamentals.

Frequently asked questions