MaNGOS Zero Runs Vanilla Server Auth Plus World

By Indie Kings | October 11, 2026

Updated October 11, 2026: MangosZero server core remains the open source Vanilla World of Warcraft server core for patches 1.12.1 through 1.12.3, built in strict C++17 with auth plus world servers, MySQL or MariaDB storage, and GCC plus Clang builds on GitHub Actions. This guide explains what it is, what it supports, and what you need to run it.

Overview: Vanilla server core

MangosZero is an open source server core for Vanilla World of Warcraft, per the official repository README. It recreates the server side of the original game experience so that players who prefer the earliest era of Blizzard design can operate their own compatible server environment. The project is part of the broader MaNGOS family and it focuses specifically on Vanilla rather than later expansions or later Classic branches. That focus shapes every technical choice in the repository, from database layout to supported client versions to scripting options.

Per README, the code is written in C++ and the current language standard is C++17, built strictly with GNU extensions off while the C parts use C11. That detail matters because it signals a modern and portable codebase rather than a frozen snapshot of early 2000s code. Strict standard compliance helps the same source build across Windows, Linux, and BSD with different compilers while catching missing includes and nonportable assumptions early. The README explicitly notes that every push is built by GitHub Actions with both GCC and Clang on Linux, plus MSVC on Windows through AppVeyor, because the two Linux compilers do not leak the same headers and a missing include can pass on one while failing on the other.

The project describes itself as fast, multiplatform, and database backed. Per README, game data and account data live in MySQL or MariaDB, with optional support for SOAP for external tooling and integration. It provides an authentication server where operators manage users, plus a world server which serves game content much like the original did. That two server split mirrors how the live game separated login and account handling from the persistent world simulation. For operators, it means user management, realm listing, and world simulation are distinct responsibilities with distinct configuration and distinct logs.

Attribution is explicit here because accuracy matters for server software. Per README, MangosZero aims for full compatibility with the three final Vanilla versions, namely patch 1.12.1, patch 1.12.2, and patch 1.12.3. Per README, it does not support 1.13 and beyond, which the project identifies as the newly released Classic Experience, sometimes called NuClassic. That boundary is load bearing for anyone planning a server. A Vanilla 1.12 client is a different product from a later Classic client, with different data files, different protocol expectations, and different content. MangosZero chooses the earlier side of that line.

Image: mangoszero server repository card. Credit: GitHub, mangoszero.

This article describes the server core only. It does not provide a game client, game data, compiled server binaries, database dumps with proprietary content, or installation files from any third party. You need your own legal 1.12 client and extracted data from that client to use this software in the manner the README intends. The README points to installation guides and a wiki for operator documentation, while the repository itself supplies source code, build scripts, schema direction, and tooling. Readers should treat client acquisition, data extraction, and server operation as separate steps with separate legal and technical requirements.

The audience for this core is broader than it first appears. Hobbyists run it to learn how massively multiplayer server architecture works, including authentication flows, world state, persistence, pathing, and scripting. Preservationists value it as a way to study Vanilla era systems using open code rather than memory alone. Small private communities use it to host familiar Vanilla content for friends with era appropriate rules. Developers use it as a base for custom content, bug fixes, database work, and tooling. Each of those uses benefits from the same traits: readable C++17, cross platform builds, relational storage, and active continuous integration.

Server facts

The following table summarizes the core facts about MangosZero server core. Per README is the standing source for each row, which means the repository README is the authority if any secondary summary differs. The table is intentionally conservative and sticks to what the README head verifies directly.

Several rows deserve extra context. The strict C++17 setting is not cosmetic. It forces explicit includes, standard conforming code, and fewer compiler specific shortcuts, which in turn makes community patches easier to review and easier to keep building on newer toolchains. The dual compiler CI is similarly deliberate. GCC and Clang ship different standard libraries with different transitive includes, so building with both catches portability bugs that a single compiler would hide. Operators benefit indirectly because cleaner source means fewer surprises when distributions update compilers or libraries.

The storage choice is equally deliberate. MySQL and MariaDB are mature relational databases with broad tooling, replication options, backup stories, and admin familiarity. A Vanilla world contains accounts, characters, inventory, quests, spawns, waypoints, scripts, and logs, all of which map naturally to relational tables with clear ownership and transactions. The optional SOAP interface then allows external programs to interact with the running server in controlled ways, which is useful for account tools, status pages, and administrative automation. Operators who do not need that surface can leave it disabled and keep the deployment simpler.

The license posture also deserves plain language. Per README, the program is free software under the GNU General Public License as published by the Free Software Foundation, either version 3 or any later version at the operator option, without warranty including implied warranty of merchantability or fitness for a particular purpose. The README adds a special exception permitting linking with the OpenSSL library and distributing the linked executables, while requiring compliance with the GNU General Public License for all other code. Contributors are asked to feed improvements back upstream after investing hundreds of hours of volunteer time. That request is social rather than a substitute for license terms, but it explains the contribution culture.

Supported patches

Patch compatibility is the most misunderstood part of Vanilla server operation, so it gets its own table. Per README is again the standing source. The rule is simple: MangosZero targets the three final Vanilla patches and draws a hard line before later Classic.

The practical takeaway is to match the client to the core. An operator needs their own legal 1.12 client from the supported line, not a later Classic client and not files mixed across eras. Data extraction, maps, navigation meshes, and database content all assume that era. Mixing clients across the 1.12 and 1.13 boundary invites protocol mismatches, missing or altered assets, and subtle gameplay differences that are difficult to diagnose. When something fails to connect or fails to load, the first check should be whether the client lineage matches the supported patch set above.

The README framing also helps set expectations about content completeness. Aiming for full compatibility with 1.12.1 through 1.12.3 is a goal that guides development, testing, and bug reports. It does not promise that every quest, script, spawn, or edge case behaves exactly like launch era live servers on day one. Private server operation always involves configuration, database state, optional modules, and local fixes. The value of a focused patch target is that bugs become reproducible: reporters can state the exact client patch, the exact commit, the exact database state, and the exact steps, and maintainers can test against the same narrow baseline.

Architecture: auth plus world

Per README, MangosZero provides two main server roles. The authentication server handles users and login, while the world server serves game content like the original did. That separation keeps concerns clean. Authentication deals with accounts, credentials, realm lists, and access control. The world process deals with maps, entities, combat, quests, movement, persistence, and scripting. Logs from each role point to different failure domains, which simplifies troubleshooting when login works but world entry fails, or vice versa.

Persistence sits underneath both roles. MySQL or MariaDB stores accounts, characters, world content references, and operational data. Relational storage gives operators familiar backup and restore workflows, query access for diagnostics, and transactional safety for character progression. It also means database setup and upkeep are first class operator skills, alongside building the binaries and configuring the realm. The README treats databases as required dependencies rather than optional extras, which is the correct mental model. Without a healthy database, neither login nor world simulation can function.

Navigation and client data handling round out the architecture. Per README, Recast creates navigation data from client map files and provides functions for rendering support, pathing, and related movement logic. Stormlib provides an abstraction layer for reading from client data files. Compression and encryption come from familiar libraries: Zlib and Bzip2 for archive and protocol compression needs, plus OpenSSL for encryption used when authenticating clients. UTF8 handling uses utf8cpp for names and chat, where the README notes that a wrong answer leads to disconnect rather than crash. Lua appears as the runtime behind the optional Eluna scripting engine, with GNU Readline linked on Unix only when Eluna is enabled.

Two modernization notes matter for developers. Per README, Recast, Stormlib, utf8cpp, Lua, Zlib, and Bzip2 ship in the standard distribution because the project relies on specific versions. Also per README, older ACE and G3D dependencies are gone: networking now uses the C++ standard library and geometry uses project owned code. Removing heavy external frameworks reduces build friction, shrinks the dependency surface, and keeps behavior closer to standard C++ semantics. Contributors should still expect a large codebase with game logic complexity, but the build graph is more approachable than older MaNGOS era setups that required those frameworks.

Optional SOAP support deserves a brief operational note. SOAP is not required to log in or to explore the world, but it can help operators who want programmatic access for account management or status tooling. Like any remote interface, it should be configured deliberately, bound carefully, credentialed strongly, and exposed only where needed. Operators who do not have a concrete use for it should keep it off until they do. That keeps the attack surface small while preserving the option for later automation.

Platforms and compilers

Per README, MangosZero supports a wide range of operating systems and compiler platforms through free cross platform libraries and a CMake based build system. CMake version 3.18 or newer adapts the build to the chosen operating system and compiler. That approach is standard for portable C++ projects because it separates source configuration from platform specifics. Operators pick their OS and toolchain, CMake generates the native build files, and the compiler builds the auth and world binaries plus tools.

On operating systems, per README, Windows is supported in 32 bit and 64 bit, with Windows Server 2008 or newer or Windows 8 or newer recommended. Linux is supported in 32 bit and 64 bit, where in practice the compiler must support complete C++17, which the README maps to Debian 10 or newer and Ubuntu 18.04 LTS or newer, with older releases unable to build the project regardless of package versions. BSD is supported in 32 bit and 64 bit, with FreeBSD, NetBSD, and OpenBSD recommended. Newer versions should also work, and matching server versions of Windows should work too. That matrix covers most self hosting and virtual private server scenarios without forcing a single distribution.

On compilers, per README, Microsoft Visual Studio is supported in 32 bit and 64 bit, with all editions from 2015 upward officially supported, while noting that support for 2015 through 2022 are end of life. GCC is supported in 32 bit and 64 bit at version 8 or newer for complete C++17 support, and it is one of the two compilers used by Linux CI. Clang is supported in 32 bit and 64 bit on any supported operating system, and it is the other CI compiler. The dual GCC plus Clang coverage on every push is the strongest portability signal in the project. It means contributors cannot accidentally rely on one toolchain leniency for long before CI flags it.

For operators choosing a platform, the boring choice is usually the right one. Use a current Long Term Support Linux release with a current GCC or Clang, current CMake, and current MySQL or MariaDB packages from system repositories. Per README, Linux and Mac style users should install packages through system package management rather than source packages where possible. That advice reduces version drift and keeps security updates flowing through the distribution. Windows remains viable, especially for developers already on Visual Studio, but Linux hosting remains the common pattern for persistent servers because of automation, service management, and remote administration norms.

Dependencies and build system

Per README, the server stands on several well known open source libraries plus less known helpers that avoid reinventing existing solutions. Required source access starts with Git, including a Windows client option, since source is distributed through version control. Databases are MySQL or MariaDB. Map and archive handling uses Recast for navigation data, Stormlib for client data file access, Zlib and Bzip2 for compression in archives and protocol paths, and OpenSSL for authentication time encryption. Text handling uses utf8cpp, while Lua backs the optional Eluna scripting engine. Those names may look long, but each maps to one clear job in the pipeline from client files to walkable world to authenticated session.

Bundling policy is pragmatic. Per README, Recast, Stormlib, utf8cpp, Lua, Zlib, and Bzip2 are included in the standard distribution because the project depends on specific versions. That avoids subtle breakage when system libraries drift ahead or behind the tested versions. Operators still install the system level toolchain and database packages themselves, plus Git and OpenSSL and related platform libraries as documented in the installation guides. The split is sensible: bundle libraries where exact behavior matters for maps, archives, text, and scripting, while using system packages for compilers, databases, and platform services.

Optional documentation tooling is minimal. Per README, Doxygen is the optional dependency for exporting HTML or PDF formatted documentation for the Mangos API. That is useful for developers navigating a large game codebase with many systems and callbacks. Operators who only build and run servers can skip it. Developers who plan to modify spells, AI, events, or custom scripts will appreciate generated API references alongside the wiki.

The build flow in prose is straightforward to describe without directing specific commands. Operators fetch the source, configure with CMake for their OS and compiler, build the auth server, world server, and tools, prepare MySQL or MariaDB, load and update the databases, extract client derived data from their own legal 1.12 client, generate navigation data, configure realm and server settings, then start auth before world and verify login plus world entry. Each stage has its own failure modes, from missing toolchain components to database permission issues to mismatched client data. The wiki and installation guides exist to cover those steps per operating system, while the README defines the supported inputs and outputs.

Community and contribution

Per README, the project welcomes anyone interested in enjoying older versions of World of Warcraft or contributing help. The community is described as small but extremely friendly and helpful, managed by MadMax and Antz. The Discord and forum motto is quoted in the README as Be nice or Be somewhere else, with trolling or unpleasantness dealt with swiftly. That tone matters for newcomers because private server stacks combine software engineering, database administration, and game knowledge, and beginners often need guidance across all three at once.

Community venues are clearly listed. Per README, there is an official MaNGOS website, a Discord server where contributors discuss Mangos related work, a main wiki holding database details, file type definitions, packet definitions, and related references, a bug and issue tracker for Mangos Zero, and installation guides for various operating systems. That structure separates chat from durable docs from actionable bug reports. Questions belong in chat or forums, durable knowledge belongs in the wiki and guides, and reproducible defects belong in the tracker with version and patch details.

Contribution culture is direct. Per README, pull requests are welcome, as signaled by the PRs welcome badge and Discord presence. The license section asks contributors who modify code and make improvements to feed those changes back upstream. That norm sustains volunteer infrastructure: fixes for quests, spawns, spells, pathing, authentication edge cases, build issues, and documentation improve faster when local patches return to the shared tree. Good contributions include a clear description, reproduction steps, client patch, commit hash, logs, and minimal scope. Review friendly patches land faster than broad rewrites.

Quality signals are visible in the repository badges. Build status comes from GitHub Actions on Linux and Mac plus AppVeyor on Windows. Repository status includes Codacy and Codefactor indicators alongside PRs welcome and Discord badges, plus release and commit activity shields. Badges are not proof of correctness, but they show that builds, style checks, and community channels are maintained rather than abandoned. For server software that operators trust with accounts and persistence, that maintenance signal carries weight.

Setup expectations

Expect server setup to be a real systems project, not a one click install. The required inputs are a supported OS, a supported compiler, CMake 3.18 or newer, Git, MySQL or MariaDB, OpenSSL, compression libraries where not bundled, and your own legal 1.12 client for data extraction. The outputs are auth and world binaries, populated databases, extracted maps and navigation data, configuration files, and logs. Between those points lie toolchain setup, database creation and permissions, schema loading, data extraction, mesh generation, realm configuration, firewall and port planning, and backup planning. Each step is learnable, but none should be skipped.

Client handling needs emphasis because it is both a legal and technical boundary. This article names the requirement but does not direct readers to any client download, data mirror, or prebuilt server package. Use only a legal copy you already own or lawfully obtain, keep it within the supported 1.12 line, and extract data locally as the guides describe. Do not mix in files from later Classic, do not borrow files of uncertain provenance, and do not publish or redistribute proprietary assets. The open source core is shareable; the proprietary client and its data are not.

Database and security planning deserve equal care. Choose strong credentials for database users, least privilege grants for server accounts, separate backup credentials where possible, and tested restore drills before inviting other players. Keep SOAP disabled unless a specific tool needs it, and if enabled, bind and credential it conservatively. Keep the OS, compiler runtime, database, and OpenSSL patched. Keep server binaries and database schema in sync when updating commits, since mismatched code and schema is a classic source of startup failures. Keep logs long enough to diagnose login, world, and script issues without retaining sensitive data longer than needed.

Finally, set content expectations with players early. State the exact core commit, the exact supported client patch, house rules, rates if any, known issues, restart windows, and wipe policy if applicable. Vanilla communities care deeply about era accuracy, progression pacing, and fair moderation. Clear public notes reduce disputes and make bug reports more useful because players can cite the same baseline the operators run. The README and wiki give the technical baseline; the operator community page gives the social baseline.

FAQ

What is MangosZero server core?

Per README, it is the open source Vanilla World of Warcraft server core in the MaNGOS family. It supplies an authentication server plus a world server, stores data in MySQL or MariaDB, and targets Vanilla patches 1.12.1 through 1.12.3.

Which game patches work with MangosZero?

Per README, the supported targets are Vanilla 1.12.1, 1.12.2, and 1.12.3. Later 1.13 and beyond NuClassic Classic Experience is explicitly not supported, so operators should stay within the 1.12 line.

What do I need to run it?

You need a supported OS, a supported compiler, CMake 3.18 or newer, Git, MySQL or MariaDB, supporting libraries including OpenSSL, and your own legal 1.12 client for data extraction. The README and installation guides define the exact matrix, while this article does not link to any client or data source.

Is it multiplatform and which compilers are tested?

Yes. Per README, Windows, Linux, and BSD are supported, with builds via Visual Studio, GCC 8 or newer, and Clang. Every push is built by GitHub Actions with both GCC and Clang on Linux, plus MSVC on Windows through AppVeyor.

Does it include SOAP and scripting support?

Per README, SOAP support is optional for external tooling, while Lua backs the optional Eluna scripting engine. Operators can enable those surfaces when needed and leave them disabled for simpler deployments.

Where is the official source and community?

Per README, the official source is the mangoszero server repository, with an official website, Discord server, wiki, installation guides, and bug tracker around it. Pull requests are welcome and contributors are asked to share improvements upstream.

Bottom Line

MangosZero server core is the focused Vanilla choice: strict C++17, auth plus world servers, MySQL or MariaDB persistence, optional SOAP, bundled map and archive helpers, dual compiler CI, and an explicit 1.12.1 through 1.12.3 target that excludes later NuClassic. Per README remains the authority for build, patch, and dependency facts. Bring a supported toolchain, a healthy database, your own legal 1.12 client, and careful configuration, and the core gives preservationists, hobbyists, and small communities a maintainable base with a friendly contribution culture.

Sources

Per the official repository README, available at https://github.com/mangoszero/server. All server facts, patch targets, language standard, database options, SOAP option, auth plus world roles, platform and compiler matrix, dependency list, CI behavior, license posture, and community venues above are drawn from that README head.