# DarkflameServer: running a private LEGO Universe server on your own hardware > An AGPL server emulator for LEGO Universe, written in C++ and split into several cooperating binaries, with a Windows release for single player and a Docker Compose setup that brings its own MariaDB. It is built for small groups and for people who want to read the code, not for public fleets. **DarkflameUniverse/DarkflameServer** — The main repository for the Darkflame Universe Server Emulator project. - Repository: https://github.com/DarkflameUniverse/DarkflameServer - Website: https://www.darkflameuniverse.org/ - Stars: 761 · Forks: 189 - Language: C++ - License: AGPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/darkflameuniverse-darkflameserver ## What the emulator replaces and what it still needs LEGO Universe was developed by NetDevil and The LEGO Group, launched in October 2010 and ceased operation in January 2012. Darkflame Universe, shortened to DLU, is a server emulator for that game. Development started in 2013, has gone through multiple iterations, and the project describes itself as able to present a near perfect emulation of the game server. The split between what the emulator provides and what it does not is worth being precise about. DLU distributes no LEGO files at all. A separate game client is required to set the emulator up and to play, and the project cannot supply that client. Instead it points users to safe checksums so they can tell whether a client they have will work. That boundary shapes everything else. You are not getting a complete game, you are getting the server half of one, and the client you supply has to match the expectations of the server build you run. The repository topics list the pieces involved, and the CMake variables file is where the network version the client speaks is pinned, which is the sort of detail that decides whether a connection attempt succeeds at all. ## A server built from cooperating binaries, not one process The repository layout shows a codebase split by service. At the top level there are directories named dAuthServer, dChatServer, dChatFilter, dMasterServer, dWorldServer, dNavigation, dScripts, dWeb, dZoneManager, plus shared code in dCommon, dNet, dPhysics, dDatabase, dServer, and a vanity directory that holds name service data. The Windows walkthrough in the project documentation confirms the shape in practice. On macOS you have to allow the unsigned binaries AuthServer, ChatServer, MasterServer and WorldServer through System Preferences before they will run, and the initial pop-up blocks them because the binaries are unsigned. That is four separate executables to approve, which tells you the emulator runs as several cooperating processes rather than one monolithic daemon. The Docker image mirrors this. The Dockerfile builds with gcc:12 and cmake, compiles with make, then copies the built Server binaries into the runtime image: ```dockerfile FROM gcc:12 as build ``` ```dockerfile COPY --from=build /tmp/persisted-build/*Server /app/ ``` It also copies the compiled ini files into /app/configs, the vanity data into /app/vanity, the navmeshes directory, the migrations folder and the dcf files, and keeps a copy of the ini and vanity files under default-configs and default-vanity so that a host mount does not clobber them. That two copy pattern is a deliberate accommodation for people who mount their own config directory over the container. ## The single player Windows path avoids compiling anything If you just want to play alone or with a couple of friends on Windows, the documentation says you no longer need to build the server from source or install development tools. The route is a release download. You download the latest Windows release, extract it into a folder inside your client directory, and the folder has to end up in the same place as legouniverse.exe with MasterServer.exe inside it. Then you open sharedconfig.ini in the server files folder, find the line that says client_location and put .. after it, so the line reads client_location=.. . That relative path is what points the server at the client assets sitting one directory up. Running the server is a double click on MasterServer.exe. On the first run you are asked to create an account, and the server shuts itself down afterwards, so you start it a second time. To connect, either delete boot.cfg from the LEGO Universe client, rename it, or follow the section on allowing a user to connect to your server if you want to keep the file. Shutting down cleanly means clicking the MasterServer.exe window and holding ctrl while pressing c. Two warnings sit around this path. If you are running under the Windows Subsystem for Linux, version 1 does not support sqlite as a database because of how it handles filesystem synchronization, and running it that way results in save data loss; version 2 is required. And on macOS the unsigned binaries have to be allowed before anything starts. ## Building from source needs a specific CMake range For anything beyond a Windows single player install, the documentation walks through a development environment setup and starts with cloning the repository including its submodules: ```bash git clone --recursive https://github.com/DarkflameUniverse/DarkflameServer ``` The recursive flag matters because the tree contains a .gitmodules entry and a thirdparty directory, and a shallow clone without the submodules leaves the build unable to find the vendored code. Compiler requirements are g++11 or greater, with MSVC, clang and appleclang listed as unchecked options. The CMake constraint is stated twice, once in the Windows packages section and once under its own heading: version 3.25 up to version 3.31. You can check what you have with: ```bash cmake --version ``` On macOS the listed packages are installed with brew: ```bash brew install cmake gcc mariadb openssl zlib ``` On Ubuntu the documented command is: ```bash sudo apt install build-essential gcc zlib1g-dev libssl-dev openssl mariadb-server cmake ``` The zlib1g-dev package matters specifically because it provides the header files, which a plain zlib package does not. The documentation also states plainly that familiarity with the command line and preferably a Unix-like environment is greatly advantageous across the whole process. ## Docker Compose wires the server to its own MariaDB The Compose file defines two services. The first, darkflamedb, runs a mariadb:latest image on a network named darkflame, with a healthcheck that calls healthcheck.sh with the --connect and --innodb_initialized flags, and a volume mapping a host directory into /var/lib/mysql. Credentials come from environment variables with defaults, and MARIADB_PASSWORD has no default at all, so the stack refuses to start until you set it. The second service, darkflameserver, pulls the published image ghcr.io/darkflameuniverse/darkflameserver:latest and mounts the host config directory, the client folder as read only, the resource server location, the dump folder and the logs directory. Its environment block is where the server is told what it is talking to: ```yaml environment: - CLIENT_LOCATION=/app/luclient - DLU_CONFIG_DIR=/app/configs - DATABASE_TYPE=mariadb ``` Network exposure is limited to UDP: port 1001, port 2005, and the range 3000 to 3300, all mapped as UDP. That range is large enough that a host firewall that blocks unsolicited UDP will break zone traffic rather than only some of it. The client mount is the part that trips people up. The container needs the LEGO Universe client files present at /app/luclient, and the project ships no client of its own. ## sqlite by default, MariaDB when you want one Two database backends are supported and the choice is set in configuration rather than in code. The Compose file defaults to MariaDB, while the.env.example file also ships MariaDB as its default value and lists the acceptable settings as sqlite, mysql, mariadb and maria, case insensitive. The example environment file is short enough to read in full, and it holds the values most operators will change: ```bash CLIENT_PATH=./client NET_VERSION=171022 ACCOUNT_MANAGER_SECRET= EXTERNAL_IP=localhost DATABASE_TYPE=mariadb SQLITE_DATABASE_PATH=resServer/dlu.sqlite MARIADB_USER=darkflame MARIADB_PASSWORD= MARIADB_DATABASE=darkflame SKIP_ACCOUNT_CREATION=1 ``` Two of these carry real consequences. ACCOUNT_MANAGER_SECRET is documented as needing to be a long random string, with a link to a generator for a 256-bit key, because it guards account creation, and SKIP_ACCOUNT_CREATION is set to 1, meaning the first run does not stop and ask you to create an account the way the Windows walkthrough describes. NET_VERSION feeds the network version used by the client, and the value 171022 also appears as CLIENT_NET_VERSION in the Compose environment. The real difference between the backends is operational rather than functional. sqlite keeps everything in a single file, which is why the Compose healthcheck for the server container looks for /app/resServer/CDServer.sqlite, and why the WSL version 1 filesystem issue matters. MariaDB needs a separate service, credentials, and a migration step, and it is the option that keeps working when several people are connected at once. ## AGPL-3.0 and an explicit warning about public servers The licence is AGPLv3, and the project spells out the points it thinks matter instead of leaving them in the LICENSE file alone. You must disclose any changes you make to the code when you distribute it. Hosting a server for others counts as distribution. The code comes without any warranty whatsoever, and the maintainers are not liable for anything you do with it. That second point has teeth. If you open a server to people outside your group, you are distributing it, so the disclosure obligation applies to you. Vendoring the code into a larger product and running it as a service puts you in the same category. The documentation is equally direct about scale. It does not recommend hosting public servers, states that the project is intended for small scale deployment such as within a group of friends, and says it has not been tested for large scale deployment, which comes with additional security risks. For an operator that is the key fact to carry away. The project is a faithful reimplementation with a community sized audience, and the maintainers are telling you not to run it as a public service. There is a matching caveat on the client side. The emulator ships no LEGO files, and users are strongly suggested to check the listed safe checksums to see whether a client will work, which is the project's way of avoiding the question of where client files come from. ## Recent tags, a canary channel, and the state of the tree The project is not archived and the last push was on 2026-10-17. Tagged releases are moving: v3.3.0 was published on 2026-05-21, v3.3.1 on 2026-06-06, and a canary build on 2026-10-05 carries the version string Canary v3.3.1 with a commit hash appended. A canary tag published alongside numbered releases suggests you can pull a recent build without waiting for the next version number, though the documentation excerpt available here does not spell out the release procedure. The tree itself gives a sense of the scope. Alongside the service directories there is a migrations directory, a tests directory, a cmake directory, a docs directory, CMakePresets.json, CMakeVariables.txt, a build.sh script, an entrypoint.sh, a Dockerfile, a docker-compose.yml, a .env.example, SECURITY.md, CONTRIBUTING.md, a systemd.example unit file and a cliff.toml, which is the configuration used by git-cliff to generate changelogs from commit history. The split between a database service and the game services means an upgrade touches several moving parts: the server binaries, the migrations, and the database schema underneath them. The presence of migrations as a tracked directory means schema changes are applied deliberately rather than by whatever the server binary happens to do at startup. ## Conclusion Adopt DarkflameServer if you want to play LEGO Universe with a small group, or you intend to study how a game server is put together, since the source is complete and the build path is documented. Skip it if you plan to run a public server, because the project itself says it is intended for small scale deployment and has not been tested at large scale. Before you start, confirm you can obtain a working game client, since the emulator ships no LEGO files, and pick your database carefully: sqlite is the default and WSL version 1 corrupts save data. ## FAQ ### Do I need a LEGO Universe client to run DarkflameServer? Yes. The emulator distributes no LEGO files at all, and a separate game client is required to set it up and to play. The project points users to safe checksums so they can tell whether a client will work with the server. ### Can I run DarkflameServer without building it from source? Yes for a single player Windows install. The documentation states that single player installs no longer require building from source, so you can download the latest Windows release, extract it next to legouniverse.exe and run MasterServer.exe. ### Which database does DarkflameServer use by default? Both sqlite and MariaDB are supported. The example environment file ships DATABASE_TYPE=mariadb and SQLITE_DATABASE_PATH=resServer/dlu.sqlite, with acceptable values listed as sqlite, mysql, mariadb and maria. ### Is it safe to run DarkflameServer under WSL? Only with WSL version 2. The documentation warns that version 1 does not support using sqlite as a database because of how it handles filesystem synchronization, and that using it will result in save data loss. ### Can I host a public Darkflame Universe server for strangers? The project does not recommend it. The documentation says the emulator is intended for small scale deployment such as within a group of friends and has not been tested for large scale deployment, which comes with additional security risks. Hosting a server for others also counts as distribution under AGPLv3. ## Sources - [DarkflameUniverse/DarkflameServer on GitHub](https://github.com/DarkflameUniverse/DarkflameServer) - [License: AGPL-3.0](https://github.com/DarkflameUniverse/DarkflameServer/blob/main/LICENSE) - [Project website](https://www.darkflameuniverse.org/) - [README](https://github.com/DarkflameUniverse/DarkflameServer/blob/main/README.md) - [Releases](https://github.com/DarkflameUniverse/DarkflameServer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/darkflameuniverse-darkflameserver