ServUO: running your own Ultima Online server from a C# emulator

What ServUO actually is: a whole game world, not a library

ServUO is a server emulator for Ultima Online, written in C#, and it is described as community driven. The site is at servuo.dev, the licence is GPL-2.0, and the default branch is pub57, which is a publishing branch rather than a development one.

What matters for anyone evaluating it is the shape of the thing. This is not a library you import and no service you deploy with a single command. It is a complete server application with directories of configuration files, a script system, spawn data and an executable. The README gives the startup sequence in six steps: start with the Config directory and read its readme first, then find and edit Server.cfg to set up the essentials, then go through the remaining *.cfg files to check they suit your needs, then build the executable, then run ServUO, and then two joke steps about profit.

The audience is therefore private server operators and the people who want to script one. The topics on the repository confirm the scope, with tags for mmo, mmorpg, server, emulator and ultima, and the licensing tags for gpl and gplv2.

The repository layout tells you where the work goes

The top level listing is a map of the emulator's parts. Config/ holds the settings, including Server.cfg and the other *.cfg files that the startup steps tell you to review. Server/ holds the server code, and the solution file ServUO.sln with its DotSettings companion is the Visual Studio project definition. Scripts/ is where gameplay logic lives as scripts, and it is the directory a server operator is most likely to edit, since that is where behaviour is changed without recompiling.

The rest of the tree is data. Data/ holds the client side assets, Spawns/ holds the current spawn configuration, SpawnsOld/ holds a previous version of it, and RevampedSpawns/ is a third generation of spawn data. Having three spawn directories in one repository is unusual and instructive, because it shows what actually changed when the spawns were reworked, and it gives a server operator a fallback.

There are also the Windows native bits, zlibwapi32.dll and zlibwapi64.dll, which point to a compression dependency that ships as a binary rather than being resolved at build time, and a ServUO.exe.config file next to the solution for runtime settings of the executable itself.

Building it: make on Linux and macOS, batch files on Windows

There are two build paths and they are chosen by platform. On Windows there are two batch files, one for development with a debugger attached and extended output, and one for production. The production script produces ServUO.exe, and the development script is the one you attach a debugger to.

On other platforms the same split is expressed through the makefile, with a debug target and a release target, where writing the release output is optional by default.

The project is a .NET solution, so a build means the .NET SDK, and the dependency list on Linux is where the real friction shows. On Ubuntu and Debian the documentation asks for the dotnet backports repository and a set of packages including zlib1g, mono-complete, the .NET 10 SDK and the .NET 10 runtime.

sudo add-apt-repository ppa:dotnet/backports
sudo apt-get update
sudo apt-get -y install zlib1g mono-complete dotnet-sdk-10.0 dotnet-runtime-10.0

On Arch based distributions the list is shorter.

sudo pacman -S make mono dotnet-sdk dotnet-runtime

The mono-complete and mono packages on both lists are the notable part, since a project built on .NET 10 still carries a Mono dependency for older runtime pieces. Expect to sort that out before the first successful launch.

Configuration is the product, because the configuration is the game

The startup steps put the Config directory first, ahead of the build, which tells you what the project thinks matters. You read the readme there, you set the essentials in Server.cfg, and then you go through the remaining *.cfg files one by one to check they suit what you want. There is no single settings screen and no environment variable; a server's behaviour is defined by files an operator edits by hand and keeps under version control.

That is a deliberate trade. A configuration file you can commit is reproducible, and for a private world it is the only record of what makes your server different from the default. It is also the main source of initial friction, because the operator has to know which file controls which behaviour, and the documentation points at a readme in that directory rather than enumerating the settings.

The scripts and spawns are the other half. Scripts/ is where the rules of the game live, and Spawns/, SpawnsOld/ and RevampedSpawns/ decide what exists in the world and where. A server that boots and runs is not yet a server that is fun, and the difference is entirely in those directories.

Publishing branches and a release cadence that slowed down

The naming convention in this repository is worth understanding before you track it. The default branch is pub57, and the releases are named after a publish number, with the listed versions being 57.4.1, published as Publish 57.4 on 2025-01-19, 57.3 from 2023-04-30 and 57.2 from 2022-11-10. So the 57 series is the current line, and the last tagged publish was in early 2025.

The repository is not archived and the last push was on 2026-10-06, so work continues on the branch even though no new publish is listed. The Travis CI badge is still present in the README, along with the Discord link and the issue tracker, so the community channels are active even if the release numbering has not moved in a while.

Two practical consequences. If you want a stable, named build, take a published release rather than the branch tip, and expect the branch to contain more than the last publish. And if you pin a version, be aware that the licence is GPL-2.0, so if you modify the emulator and let others interact with your server, the source obligations of that licence apply to your distribution of the changes. That is a licensing question rather than a technical one, and the LICENSE file in the repository root is the version to read.

Where ServUO is the wrong tool

The clearest case for not using it is that you want to play rather than to operate. A private world needs an operator who will configure the settings, curate the spawns, write and debug scripts, and keep the world running, usually on a machine that is on all the time. None of that is what the emulator is for, and the project does not present itself as a hosted service.

The second case is expectations about the game itself. The emulator reproduces the mechanics of Ultima Online and gives you the data to run a world, but a world with no scripts written, no spawns tuned and no community is an empty shell. The difference between a working private server and an interesting one lives entirely in the content you add, and nothing in the repository automates that.

The third case is a development environment where the dependency list does not fit. The Ubuntu and Arch instructions assume a Mono package alongside the .NET 10 SDK and runtime, and the repository ships prebuilt zlib binaries for Windows, so on an unusual Linux distribution or a non x86 platform you are likely to hit build friction before you reach the game. The Windows path, with the two batch files, is the one the project appears to have optimised for.

Editorial conclusion

Adopt ServUO if you want to run a private Ultima Online world and are prepared to tune the configuration, write scripts and curate the spawns, because the emulator gives you the world and the data but not the content. Do not adopt it if you want a hosted game to play rather than a server to run, and do not expect a recent release cadence, since the newest listed publish is 57.4.1 from 2025-01-19 even though the default branch pub57 is still receiving pushes. Before you open a world, read the readme in the Config directory, set the essentials in Server.cfg, review the remaining *.cfg files, and copy the data into place from the Data, Spawns and Scripts directories before the first launch.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. ServUO/ServUO on GitHub