MangosZero: a server for the last three patches of Vanilla WoW

One branch for the last three Vanilla patches

MangosZero is a server for World of Warcraft, and the README is precise about which one. It aims to be 100% compatible with the 3 final versions of Vanilla World of Warcraft, namely patch 1.12.1, patch 1.12.2 and patch 1.12.3.

The framing is nostalgia with a technical specification attached. If you liked the original incarnation of World of Warcraft and still want to play it, this is the branch for you. The project provides an authentication server where you can manage your users, and a world server which serves game content just like the original did back then.

So it is two services with two jobs. The authentication server is the account side, and the world server is the game itself, and both are part of this repository.

The underlying Mangos project is described as an open source project written in C++, fast, running on multiple platforms, storing game data in MySQL or MariaDB, with optional support for SOAP, which is how external tools and web services talk to a running server.

The licence is GPL-3.0, the default branch is master, and the last push was on 2026-10-07. The recent release tags carry a curious numbering, v22.04.481, v22.04.480 and v22.04.479, and their titles show what the work actually is, a fix bounding custody maintenance and preserving recovery, a RealmDB change requiring a Cata Warden identity schema, and a CI bump of the Windows OpenSSL installer to 3.6.4.

The 1.13 boundary is stated in capitals

One line in the README is worth quoting for its directness: IT DOES NOT SUPPORT 1.13.x and beyond which is the newly released Classic Experience, NuClassic.

That is the single most important fact for an evaluator, and it is the first thing to check. The client protocol changed with the Classic Experience release, and a server that implements the 1.12 wire protocol will not talk to a 1.13 client, no matter how much configuration you do afterwards. This is a protocol difference, not a content difference.

The practical consequence is that MangosZero and the Classic Experience are two different projects with different audiences. If what you want is to play the game as it was in 2005, with the talents, the world and the systems of that era, this is the right branch. If what you want is the modern Classic release, you need the other one, and this repository is the wrong tool regardless of how well maintained it is.

That distinction also explains why the project can be both old in lineage and current in maintenance. The 1.12 protocol and the 1.13 protocol differ, so a project that targets one does not need to follow the other, and the release activity in this repository is about the 1.12 era rather than about the newest client.

One more point about scope. The README notes that the server serves full world content including authentication and scripts support, and the topic list includes lua, which points at the Eluna scripting engine discussed below.

CMake, C++17, and two compilers on every push

The build requirements are stated in a way that leaves no ambiguity, which is the mark of a project with a lot of failed installs behind it.

The code is C++17, built strictly with GNU extensions off, and the C parts are C11. The build system is CMake, version 3.18 and newer, used to adapt the build to the operating system and compiler you choose. The README says the server supports a wide range of operating systems and various compiler platforms, and that it uses various free cross-platform libraries and CMake to provide a cross-platform build system.

The operating system list is specific. Windows 32 and 64 bit, with Windows Server 2008 or newer, or Windows 8 or newer, recommended. Linux 32 and 64 bit, in practice Debian 10 or newer and Ubuntu 18.04 LTS or newer, and the note is emphatic that older releases cannot build this at all, whatever their package versions. And BSD 32 and 64 bit, with FreeBSD, NetBSD and OpenBSD recommended.

The compilers are Visual Studio from 2015 upwards, although support for 2015 through 2022 is end of life, GCC version 8 or newer for complete C++17 support, and Clang 32 and 64 bit.

The build policy is the part worth remembering. Every push is built by GitHub Actions with both GCC and Clang on Linux, and by AppVeyor with MSVC on Windows, and the README explains why the two Linux compilers are not redundant: their standard libraries do not leak the same headers, so a missing #include can pass on one and fail on the other. The stated preference is simple, they do love green builds, and working things.

Six vendored libraries, and the two that were dropped

The dependency list explains how the server reads a client's data files and talks to the client, and it has been pruned deliberately.

The server stands on the shoulders of several well known open source libraries, plus a few less known ones to prevent inventing the wheel again. MySQL or MariaDB store the content and the user data. Recast creates navigation data from the client's map files and provides functions for rendering and pathing, which is how the server knows where a character can walk. Stormlib provides an abstraction layer for reading from the client's data files. Zlib provides compression used in both MPQ archive handling and the client and server protocol, Bzip2 provides compression for MPQ archives, and OpenSSL provides the encryption used when authenticating clients.

Two of the choices are explained in the README. utf8cpp handles UTF-8 for names and chat, where the README notes that a wrong answer is a disconnect rather than a crash, which is a fair way to describe a bug class in a protocol server. And Lua is the runtime the optional Eluna scripting engine is built on, linking GNU Readline on Unix, a dependency that exists only when Eluna is enabled.

The pruning is the interesting part. Recast, Stormlib, utf8cpp, Lua, Zlib and Bzip2 are included in the standard distribution because specific versions are relied upon, and the README says so directly. ACE and G3D are gone, the networking is the C++ standard library, and the geometry is the project's own.

That is a substantial rewrite of the server's foundation, and it explains why the build requirements are as strict as they are.

Eluna gives you a scripting engine inside the world

The scripting support is the feature that turns a game server into a server people build on.

The README notes that the server serves full world content including authentication and scripts support, and the dependency list identifies the mechanism: Lua is the runtime the optional Eluna scripting engine is built on. So the game logic, quests, events and behaviours can be scripted in Lua rather than compiled into the C++ core. On Unix it links GNU Readline, and the README is careful to note that this dependency only exists when Eluna is enabled, which is the right way to keep an optional feature from becoming a mandatory one.

This is the kind of extension point that changes who a project is for. Without it, running a realm means running a fixed server that behaves the way the developers decided. With it, the behaviour of the world is data, written by people who are not C++ programmers, and the server becomes a platform. A private realm operator who wants custom events, custom loot behaviour or a modified quest chain writes Lua instead of patching and rebuilding C++.

The optional dependencies section adds one more item, Doxygen, for exporting HTML or PDF formatted documentation for the Mangos API. That is a developer-facing feature, and it fits the picture of a project where the internals are the product.

Data in MySQL or MariaDB, with optional SOAP

The persistence and integration story is short and worth reading carefully.

Mangos stores game data in MySQL or MariaDB, and the README is clear that these databases are used to store content and user data. So the world, the items, the quests, the accounts, the characters, all of it lives in a relational database, and a realm operator's backup story is a database backup story.

The optional integration is SOAP support, which is the mechanism by which external software drives the server. In practice that means web panels, administrative tools and scripts can act on the realm over a defined interface rather than through a human at the console, and it is the difference between a private server you sit in front of and one that other systems can talk to.

The repository structure reflects the same division. There is a src/ directory for the server code, a dep/ directory for the vendored dependencies, a cmake/ directory for the build system definitions, a win/ directory for the Windows side, and an extra/ directory. The Doxyfile.in at the root is the template for the API documentation, and CMakeLists.txt is the top level build definition. There is a .gitmodules file, which is how the vendored libraries are pinned, a .codacy.yml for the automated code review configuration, a .dockerignore, and a CLAUDE.md file for tooling.

The support material is also project specific. The bug tracker is at getmangos.eu for Mangos Zero, the wiki holds the repository of as much information as the maintainers can pack in, including the database, file type definitions and packet definitions, and there is a Discord server and an official website.

Where MangosZero is the wrong project

The limits here are clear and mostly about who should not be running this.

The first is the client version, and it is the one that ends a decision. If you want the Classic Experience, or anything newer than 1.12.3, this branch is not a starting point that you can configure your way into, because the protocol differs. The project is explicit and the honest response is to look elsewhere.

The second is that this is a server to run, not a service to sign up for. There is no managed offering here in the documentation, so somebody is responsible for compiling it, running the authentication and world processes, hosting the MySQL or MariaDB instance, applying database migrations, backing it up, and keeping up with releases. The release titles are a good illustration of what that work involves, a Cata Warden identity schema change and a RealmDB requirement are not things a player notices and are things an operator has to apply.

The third is the toolchain requirement, and it is real. C++17 with a GCC of version 8 or newer, a Clang, or a recent Visual Studio, with CMake 3.18 and newer, and the strictness of a build with GNU extensions off and the C parts held to C11. That is a normal native build, but it is a native build.

The fourth is the data dependency. Recast and Stormlib exist to read the client's data files and map files, which means the server needs the data the client uses, and a realm operator is dependent on obtaining and keeping that data in step with the client version. The project handles it, but it is a coupling rather than a self-contained system.

The fifth is community shape. The README describes a small but extremely friendly and helpful community managed by two people, with a motto printed in the README itself:

'Be nice or Be somewhere else'

That is the tone of a volunteer project, and for a private realm operator that is usually a plus. It also means the roadmap and the bug fixing capacity are the commitment of a small number of people, which is worth weighing before you put a realm on it.

Editorial conclusion

Adopt MangosZero if you want to run a private Vanilla era World of Warcraft realm and you are prepared to compile the server, seed a MySQL or MariaDB database and run the authentication and world services yourself. Do not adopt it if you want the Classic Experience, because the 1.13 and later clients are explicitly not supported, and do not adopt it if you need a managed hosting product. Verify first that your compiler is C++17 capable, that the CMake version is 3.18 or newer, and that you have the client data files and map files the Recast and Stormlib dependencies expect.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mangoszero/server on GitHub
4. README
5. Releases