How to document the architecture of your MU Online server

A MU Online server isn't a single program — it's a small ecosystem of processes that talk to each other. The ConnectServer receives players and routes them; the GameServer runs the game world; the DataServer is the bridge to the database; SQL Server holds accounts, characters and items; and the website publishes rankings and the player area. Each piece listens on specific ports, depends on others to function, and has its own way of starting, stopping and failing. While everything is running, that complexity stays invisible. The problem shows up on incident day: the GameServer won't come up, and you can't remember which port the DataServer listens on, or which component depends on which, or the right restart order. Documenting the architecture is exactly building the map you'll need at precisely that moment — and that anyone who takes over the server in the future will need too. This tutorial shows how to map each component, record ports and dependencies in clear tables, write an operational runbook any administrator can follow, and draw a readable architecture diagram. The port numbers and component names cited are examples and vary by emulator/version; the method of documenting does not.

Why documentation is worth the effort

Architecture documentation feels like bureaucracy until the first time it saves you. The concrete gains:

• Faster incident response: with ports and dependencies at hand, diagnosis stops being guesswork.
• Onboarding: a new administrator understands the server in hours, not weeks.
• Continuity: if you need to step away, the server doesn't die along with your knowledge.
• Error prevention: by mapping dependencies, you see the fragile points before they become incidents.
• A basis for automation: deployment and monitoring scripts arise naturally from a well-documented architecture.

Documentation is, at its core, the server's external memory. And external memory doesn't forget details at three in the morning.

Prerequisites

• Full access to the server to inspect processes, ports and configuration files.
• Knowledge of the components that make up your server (or the willingness to discover them).
• A versioned location to keep the documentation, preferably a private Git repository separate from the server machine.
• A diagramming tool: it can be Mermaid (text), draw.io, Excalidraw or similar — all free.
• A text or Markdown editor to write the tables and the runbook.

If you're building the server right now, it's worth documenting in parallel with the build, following a guide on how to create a MU Online server. Documenting during the build is much easier than reconstructing the map later, from memory.

Step 1 — Inventory the components

Start by listing everything that makes up the server. For each component, record: the name, its function, the corresponding executable or service, the folder where it lives and how it's started. A typical MU server has this backbone:

Fill the executable column with the real names from your emulator — they vary by emulator/version. Some emulators merge components, others split them further (for example, separating a chat or ranking server). The goal here is to leave no piece out: everything that must be up for a player to log in should be on the list.

Step 2 — Map the ports

Ports are where documentation most pays off in practice. Each component listens on one or more ports, and port conflicts or blocks are among the most common causes of a server being down. Build a dedicated table.

Two golden rules here. First: internal components like DataServer and SQL Server must never be exposed to the internet. If they are, it's a serious security flaw — the firewall must block them from the outside. Second: document your server's real ports, verifying them instead of copying values from tutorials. To find out what's listening, on Windows use:

netstat -ano | findstr LISTENING

Cross-reference the returned PIDs with Task Manager to see which process opened each port. The values in the table above are just common examples and vary by emulator/version and by configuration.

Step 3 — Document the dependencies and the startup order

Once you know what exists and where it listens, record how the pieces depend on one another. This defines the startup and shutdown order, which is critical: bringing things up in the wrong order makes components fail because what they need isn't ready yet.

The typical dependency chain is:

SQL Server  →  DataServer  →  GameServer  →  ConnectServer
                                   ↓
                          JoinServer / events

Translated into operational rules:

• Startup order: SQL Server first, then DataServer, then GameServer, and ConnectServer last. The foundations before what players touch.
• Shutdown order: exactly the reverse — ConnectServer first (closing the front door), then GameServer, then DataServer.
• Failure points: if SQL Server goes down, everything behind it goes down. If the DataServer goes down, the GameServer loses the database. Document these cascade effects so you don't waste time diagnosing the symptom when the cause is at the base.

Also record external dependencies: the website depends on SQL Server; some event service may depend on synchronized time; new-account registration may go through the same database. Every arrow in the dependency diagram is a future diagnostic clue.

Step 4 — Write the operational runbook

The runbook is the operations manual — the "how to do it" that complements the "what it is" of the inventory and the diagram. It should be so clear that someone under pressure can follow it without improvising. Structure it by procedure.

Procedure: start the server from scratch

1. Confirm the SQL Server service is running.
2. Start the DataServer and wait for the database connection message.
3. Start the GameServer and confirm it registered with the DataServer.
4. Start the ConnectServer and verify it lists the GameServer.
5. Start the auxiliary services (events, join).
6. Bring up the website.
7. Do a test login with a reserved account.

Procedure: stop the server safely

1. Announce the maintenance to players.
2. Stop the ConnectServer to block new logins.
3. Wait a few minutes for online players to leave.
4. Stop the GameServer.
5. Stop the DataServer.
6. Only then, if necessary, stop SQL Server.

Procedure: quick diagnosis when "the server went down"

1. Check which processes are up (Get-Process).
2. Verify the expected ports are listening (netstat).
3. Read each component's logs, starting from the base (SQL → DataServer → GameServer).
4. Identify the component furthest "down" the chain that failed — the cause is usually there.

Include in the runbook the exact log paths, the test accounts, the verification commands and the contacts to reach in an emergency. A good runbook answers questions before you need to think of them.

Step 5 — Draw the architecture diagram

The diagram turns tables into an image you grasp at a glance. You don't need an expensive tool; a text-based diagram with Mermaid works very well and can even be versioned alongside the rest of the documentation.

flowchart TD
    Player([Game client]) -->|44405| CS[ConnectServer]
    Player -->|55901| GS[GameServer]
    CS -->|registration| GS
    GS -->|55960| DS[DataServer]
    DS -->|1433| SQL[(SQL Server)]
    Site[Website / Panel] -->|1433| SQL
    Player -->|80/443| Site

What a good architecture diagram shows:

• The components as named boxes.
• The connections between them, ideally annotated with the port used.
• The direction of flow (who initiates the connection with whom).
• The exposure boundary: make it visually clear what is public (client, website) and what is internal (DataServer, SQL). A dashed rectangle around the internal components communicates this well.

Keep the diagram simple. The goal is quick orientation, not capturing every detail. Details live in the tables; the diagram gives the overall view. And, crucially, update the diagram whenever the architecture changes — a wrong diagram is worse than none, because it leads to bad decisions.

Step 6 — Store and keep the documentation alive

Documentation isn't a project that ends; it's an organism that has to keep pace with the server.

• Store it in a versioned location external to the server machine, like a private Git repository. If the documentation lives only inside the server and it goes down, you lose the map exactly when you need it most.
• Treat the update as part of the change: opened a new port? Document it at the same moment. Added a component? Update the inventory, the port table and the diagram before considering the task done.
• Review periodically: schedule a quarterly review to catch drift that slipped through.
• Give the team read access: documentation nobody can find is useless.

Living documentation is worth ten perfect documents frozen in time. The quality criterion is simple: can someone who has never seen the server, with these documents alone, understand the structure and operate it safely?

Common errors and fixes

Launch checklist

• Complete component inventory with function and executable
• Port table with protocol and exposure (public vs. internal)
• Ports verified with netstat, not copied from tutorials
• Internal components (DataServer, SQL) confirmed as not exposed
• Dependency chain documented
• Startup and shutdown order recorded in the runbook
• Start, stop and diagnose procedures written step by step
• Log paths and test accounts included in the runbook
• Architecture diagram drawn with annotated ports
• Public/internal boundary visible in the diagram
• Documentation stored in a versioned, external repository
• A process defined to update the docs with every change

Documenting the server's architecture is an investment whose return arrives at the worst possible moment — and that's exactly why it's so valuable. When the GameServer won't come up at three in the morning, the difference between fixing it in five minutes and spending the whole night groping in the dark is precisely having, at hand, the component inventory, the port map, the dependency chain and a runbook that says what to do. Start with the inventory, verify the ports for real, draw a simple diagram and keep everything alive and versioned. Adapt each port and component name to the reality of your emulator, because those details always vary by emulator/version.

Frequently asked questions