How to run two MU Online servers on the same machine

Running two completely independent MU Online servers on the same machine is a common need: hosting a "main" server and a "test" one, operating a classic Season 6 server alongside a high-rate server, or simply making use of a robust VPS for two distinct projects. The good news is that MU Online is perfectly capable of this — the process architecture (DataServer, JoinServer, GameServer, ConnectServer) is modular and each instance can have its own ports, its own configuration files and its own database. The bad news is that any slip in duplicate ports, an accidentally shared DSN or a crossed database produces frustrating conflicts, with processes that won't start, characters disappearing or two servers writing to the same base. This guide shows how to set up two truly isolated instances, covering distinct ports, SQL databases/instances, separate ConnectServer and GameServer, resource sizing and how to diagnose the most common conflicts.

Difference between "two servers" and "subservers"

First of all, align the concept, because the two things are often confused:

• Subservers / channels (multi-server): several GameServers that share the same database and appear together on the selection screen. The character is the same on any channel. This is about the capacity and load balancing of a single project.
• Two independent servers (this tutorial): two separate projects, each with its own database, its accounts, its characters and its ConnectServer. A player with an account on Server A has nothing on Server B.

If your goal is to increase the capacity of a single server, you want subservers. If you want two separate worlds, it is this here.

Prerequisites

• A machine (VPS or dedicated) with resources to spare — running two servers requires, in practice, almost double the RAM and CPU of one. Treat 4 GB and 2 vCPUs as the absolute minimum for two small servers; more is better.
• Windows Server (2016/2019/2022 are common) with administrative access.
• SQL Server installed and functional, with permission to create a second database (or a second instance).
• Two packs/emulators already downloaded — they can be the same Season or different Seasons.
• The ODBC Data Source Administrator (32-bit) accessible, since most emulators use a 32-bit DSN.
• A backup of any existing server before you touch anything.
• Good mental (or spreadsheet) tracking of the port map, which is the heart of this process.

> The number-one cause of failure here is reusing Server A's configuration files in Server B without changing the ports and the DSN. Always review config by config on the second server.

Planning the port map

Since both servers live on the same IP, every port in use must be unique between them. Plan this before touching any file. The exact ports vary by emulator, so treat the table below as an organization example — what matters is the principle of separate ranges:

A good practice is to shift the second server by a fixed block (e.g., +10 or +100) across all ports, to make it easy to remember. The values above are illustrative; use your emulator's file headers to find the real key names.

Step 1 — Isolated folder structure

Never mix the two servers in the same folder. Create completely separate trees:

E:\MU\
├── ServidorA\
│   ├── DataServer\
│   ├── JoinServer\
│   ├── GameServer\
│   └── ConnectServer\
└── ServidorB\
    ├── DataServer\
    ├── JoinServer\
    ├── GameServer\
    └── ConnectServer\

Each folder has its own set of binaries and configs. This prevents an update in one from affecting the other and makes backups trivial (just copy each one's root folder).

Step 2 — Separate databases

You have two options:

Option A — Two databases on the same instance (recommended for most)

Simpler and lighter. On the same SQL Server instance, restore/create two databases with distinct names:

-- Create the two databases (or restore from your pack's backups)
CREATE DATABASE MuOnlineA;
CREATE DATABASE MuOnlineB;
GO

-- Verify that both exist
SELECT name, database_id, create_date
FROM sys.databases
WHERE name IN ('MuOnlineA', 'MuOnlineB');

Then configure two distinct 32-bit ODBC DSNs, one pointing to each database:

ODBC (32-bit):
- DSN "MuOnlineA"  ->  database MuOnlineA
- DSN "MuOnlineB"  ->  database MuOnlineB

Option B — Two SQL Server instances

Worth it if you need strong resource isolation, different SQL Server versions, or per-instance memory limits. Each instance has its own port (e.g., the default instance on 1433, a named instance SQLEXPRESS2 on another port). It is heavier and more complex to maintain — only choose it if you have a concrete reason.

> Classic pitfall: pointing both DSNs (or both DataServers) to the same database by mistake. If that happens, the two servers write characters to the same base and you will get logical data corruption. Check DSN by DSN.

Step 3 — Configure Server A

Adjust Server A's files with its ports and DSN. Generic examples (keys vary by emulator):

; ServidorA\DataServer\DataServer.ini
[DataServer]
DataServerPort=55557
[Database]
DSN=MuOnlineA

; ServidorA\GameServer\GameServer.ini
[Network]
GameServerPort=55901
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55555
[Database]
DSN=MuOnlineA

; ServidorA\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44405
[GameServer1]
IP=YOUR_PUBLIC_IP
Port=55901

Step 4 — Configure Server B (the step everyone gets wrong)

Now repeat for Server B, but changing all the ports and the DSN. This is where most beginners fail by copying Server A's files without reviewing them:

; ServidorB\DataServer\DataServer.ini
[DataServer]
DataServerPort=55567         ; <- different from A
[Database]
DSN=MuOnlineB                ; <- different database

; ServidorB\GameServer\GameServer.ini
[Network]
GameServerPort=55911         ; <- different from A
[JoinServer]
JoinServerIP=127.0.0.1
JoinServerPort=55565         ; <- different from A
[Database]
DSN=MuOnlineB

; ServidorB\ConnectServer\ConnectServer.ini
[ConnectServer]
Port=44415                   ; <- different from A
[GameServer1]
IP=YOUR_PUBLIC_IP
Port=55911

Review line by line: if any port matches Server A's, Server B's process will not start.

Step 5 — Firewall and public ports

Open in the firewall only the ports players need to reach (each server's ConnectServer and GameServer). The DataServer and JoinServer ports are internal and must stay closed to the internet:

# Server A - public ports
netsh advfirewall firewall add rule name="MU-A Connect" dir=in action=allow protocol=TCP localport=44405
netsh advfirewall firewall add rule name="MU-A Game"    dir=in action=allow protocol=TCP localport=55901

# Server B - public ports
netsh advfirewall firewall add rule name="MU-B Connect" dir=in action=allow protocol=TCP localport=44415
netsh advfirewall firewall add rule name="MU-B Game"    dir=in action=allow protocol=TCP localport=55911

# DataServer/JoinServer (55557,55555,55567,55565): do NOT open to the internet

Step 6 — Startup order

Each server starts in the canonical order, and you start one full server before the other to make diagnosis easier. A .bat per server helps:

@echo off
echo Starting Server A...
start "" "E:\MU\ServidorA\DataServer\DataServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\JoinServer\JoinServer.exe"
timeout /t 3
start "" "E:\MU\ServidorA\GameServer\GameServer.exe"
timeout /t 5
start "" "E:\MU\ServidorA\ConnectServer\ConnectServer.exe"
echo Server A is up.

Make an equivalent IniciarB.bat pointing to the ServidorB folder. Bring up A, confirm it is stable, and only then bring up B.

Resource sizing and conflicts

Two servers on the same machine compete for CPU, RAM, disk and network. Points of attention:

• RAM: each GameServer and SQL Server consume memory. Configure SQL Server's max server memory so it does not swallow all the RAM and starve the GameServers.
• CPU: on a VPS with few vCPUs, a heavy event on Server A can cause lag on B. If possible, use CPU affinity to separate loads.
• Disk: both databases write to the same disk; an SSD is practically mandatory for two servers.
• Ephemeral ports/DSN: re-verify there is no overlap at all. Use netstat -ano | findstr LISTENING to check what is already listening before bringing up the second server.

Common errors and fixes

Launch checklist

• Machine sized with spare RAM/CPU/disk for two servers
• Backup of any pre-existing server done
• Port map planned and documented (no overlap)
• Fully separate folders for Server A and Server B
• Two databases created (or two instances) and verified
• Two distinct 32-bit ODBC DSNs, each on the correct database
• Server A configs reviewed (ports + DSN A)
• Server B configs reviewed line by line (ports + DSN B)
• Firewall opening only each server's ConnectServer and GameServer
• Internal ports (DataServer/JoinServer) closed to the internet
• Startup .bat for each server, in the correct order
• Server A comes up and stabilizes on its own before bringing up B
• Account test: create a character on A and confirm it does NOT appear on B
• Load test: an event on one without taking down the other
• SQL Server max server memory limited so it does not starve the GameServers

With unique ports, separate databases and isolated folders, two MU Online servers coexist peacefully on the same machine. The secret is discipline: plan the port map beforehand, review the second server file by file, and validate the isolation with real account and load tests before opening it to players.

Frequently asked questions