vmangos core: a progressive World of Warcraft server core

An independent continuation, not a fork of the official code

vmangos core is an independent continuation of the Elysium and LightsHope codebases, and the README states its focus directly: delivering the most complete and accurate content progression system possible, including support for the patch appropriate game clients.

Progression is the whole point. A vanilla progression realm is one where content unlocks the way it did when the game was live, so a new character starting in patch 1.5 territory meets quests, spells and items that a character on a modern realm would never see. That goal is what separates this project from a server that simply offers a wide catalogue of endgame content.

The audience is therefore quite specific. You need a C++ toolchain, a MySQL database, and the patience to run a content project measured in database scripts rather than in configuration files. The primary language is C++, the licence is GPL-2.0, and the default branch is development rather than a stable branch, which is the usual arrangement for a project whose database content changes weekly.

The last push was on 2026-10-17, so the code is being worked on currently, and the community around it is organised around a wiki and a Discord channel.

This is not an emulator of the client in the sense of running the game itself. It is a server: it accepts connections from a real game client, and the client version you connect with determines what the server can show you.

Supported client builds, and the ones still commented out

The list of supported builds is the single most important fact for an operator, and the README enumerates it:

- 1.12.1.5875+ - 1.11.2.5464 - 1.10.2.5302 - 1.9.4.5086 - 1.8.4.4878 - 1.7.1.4695 - 1.6.1.4544 - 1.5.1.4449

Notice the shape of that list. The top entry is an open ended 1.12.1.5875+, so the newest client line is supported and continues to be. The bottom entry is 1.5.1.4449, and everything below it, the 1.4.2.4375, 1.3.1.4297 and 1.2.4.4222 lines, sits inside a comment block in the README rather than in the active list.

That matters because the project's stated goal is complete progression starting from patch 1.2 through 1.12. The goal covers the full range, but the currently supported builds do not yet reach back to 1.2. So the direction of travel is upward through the patches, from the oldest client support towards the newest, and the oldest three lines are the ones not yet usable.

For anyone planning a deployment, this is a hard constraint rather than a preference. The client build your players use has to be one of the eight listed, and if you are aiming at a 1.3 or 1.2 era realm, this core is not there yet.

Accuracy first: custom behaviour goes behind a config option

The project publishes four guidelines, and the first one explains the philosophy.

Accuracy is the stated point of an emulator, whose job is to recreate the functionality of what it emulates as closely as possible. The consequence is spelled out: any custom behaviour should be behind a config option and off by default. That is a strong position for a server that other people will run. If a change alters original game behaviour, it is not free to do so, and the default has to match the original.

The second guideline is about where content lives, and the third is about the goal behind it.

Full progression is the ultimate goal, and it has a precise technical consequence: every piece of data must be marked with the patch in which it was added, or changed to its current state. That single requirement is what makes the content model work across eight client builds. A spell introduced in patch 1.9 does not exist for a 1.6 client, and the patch tagging is the mechanism that decides this.

The fourth guideline is about tools: content creation should not require programming knowledge, with the hope of eventually providing tools that let people edit database scripts and content with all data presented in human readable form. Two such tools are already linked from the README, a Script Editor at brotalnia/scripteditor and a Script Converter in the vmangos organisation, alongside the wiki and the Discord channel.

Content lives in the database, not in the C++ core

The DB scripting guideline says content should be separate from the core itself, so hardcoding scripts should be avoided where possible, and when database scripting functionality is insufficient, the project simply expands it.

This is the architectural decision that makes vmangos different from a server whose quests and spawns are compiled into the binary. Here, the SQL is the content, and the repository layout shows it clearly. There is a sql/ directory at the top level for the scripts, alongside src/ for the C++ core, CMakeLists.txt with a cmake/ directory for the build system, dep/ for dependencies, and contrib/ for supporting material. The presence of .clang-format, .editorconfig and .idea/ directories shows a project with an enforced code style and a configured IDE experience.

The operational consequence is significant. Changing what the game contains means running SQL against the database, not rebuilding and redeploying a server binary. That makes content iteration fast, and it makes content mistakes equally easy to make, since a bad script can take a realm down in a way a bad C++ patch cannot.

It also explains the release artefacts. The project ships two separate downloads rather than one. The latest tag holds a development build for Linux, macOS and Windows, and the db_latest tag holds a development database snapshot for MySQL 5.6, described as needing no updates. A fresh operator therefore pulls a server binary and a matching database, and the pairing of those two artefacts is part of the workflow.

Getting a realm running without documented install commands

The README does not give install commands, and that is a real gap for anyone starting from scratch. It points to the wiki for the full documentation, and to the two release tags for the binaries, so the practical path is: take the latest development build for your platform from the latest tag, take the MySQL 5.6 snapshot from db_latest, then follow the wiki for the configuration and build steps.

For people who prefer to compile, the repository is a CMake project. CMakeLists.txt sits at the root with a cmake/ directory for modules, dep/ for vendored dependencies, contrib/ for extras and src/ for the code itself, which is the layout you would expect from a project of this size. The contributing guide is a separate document at the root, and the wiki and Discord links are the places where build details live.

Two things to keep in mind. The default branch is development, and the release tag is called latest rather than carrying a version number, so it points at the newest development build rather than a stable release. A deployment that pins a commit and pairs it with a dated db_latest snapshot is the only reproducible combination the project offers.

The database snapshot is dated separately from the binaries, and the two snapshots in the release list are a day apart and a couple of weeks apart respectively, so an operator who mixes an old dump with a new core should expect missing or extra content rather than a clean error.

GPL-2.0, two release tags and a database that changes weekly

The licence is GPL-2.0, which matters more here than in most projects because the entire product is a server that players connect to. Anyone planning to modify and redistribute the core, or to run a modified server as a service, needs to read what that licence requires for their distribution model. This is a description of the licence, not advice.

The release model has two moving parts, both named after what they are. The latest tag carries a development build dated 2026-10-17 for Linux, macOS and Windows, and db_latest carries a development database snapshot dated 2026-09-28. Neither is a numbered release, and neither carries semantic version information.

That design follows from the guidelines. Content progress is continuous, so the database snapshot is a rolling artifact, and the core changes alongside it. A fixed release would freeze content at a point that the project explicitly does not consider finished, since full progression from 1.2 through 1.12 is still the stated goal and the oldest supported client is 1.5.1.4449.

The practical upshot for an operator is that upgrades are a routine operation rather than an event, and that you should treat the database as the part that carries the game. If you are evaluating this project, the honest question is not whether the C++ core is good, but whether you are prepared to run a content project that is still filling in its oldest patches.

Editorial conclusion

vmangos core fits server operators who want a realm whose progression follows the original patch rules from 1.2 through 1.12, and it does not fit anyone who wants a modern client or a quick to build demo server, since the content work lives in the database rather than in code. Verify first which client build you intend to connect, because the currently supported list starts at 1.5.1.4449 with 1.2 through 1.4 commented out, and confirm that the db_latest MySQL 5.6 snapshot matches your database version before importing.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. vmangos/core on GitHub