ds3os: running your own Dark Souls 2 and 3 servers

Why an open server implementation exists at all

ds3os describes itself as an open source implementation of the game servers for Dark Souls 2 (SOTFS) and Dark Souls 3. The motivation in the README is worth reading closely, because it is not simply about hosting.

The stated reason is to offer an alternative to playing online with mods without the risk of being banned, and also to let people play privately without dealing with cheaters, invasions and the rest. In other words, the value is a controlled environment where the rules are the server owner's rules, not a faster service than the official one.

The project is written primarily in CMake with the C++ sources under Source, protocol definitions in a Protobuf directory, tooling under Tools and assets under Resources. It is MIT licensed, not archived, and the last push was on 2026-07-10. The most recent published releases are v0.42.0.0-main on 2024-08-14, v0.41.0.0-main on 2024-03-24 and v0.40.0.0-main on 2024-03-23.

One thing the project is careful about is scope. It is a server implementation, not a game client. The retail game is what connects to it, which means a legitimate copy of the game and its platform client are prerequisites rather than optional extras.

Steam ticket authentication and the piracy boundary

The README has a section titled Can I use it with a pirated game, and the answer is no. The server authenticates Steam tickets, and the maintainers state plainly that they have no interest in supporting piracy or Steam emulators.

That distinction matters for how you should read this project. It is not a patch that unlocks a retail game, and it is not a bypass for the platform's account checks. The server speaks to the legitimate client and validates the session through the platform's ticket mechanism. The feature table in the README lists ticket authentication as supported for Dark Souls 3, which is the same mechanism the official servers use to decide whether a player may join.

The README also asks readers to support the publisher, stating that the games should be purchased if possible. That framing is consistent with how the project is built: the server replaces the matchmaking and session infrastructure, not the game.

A second boundary concerns account risk. The README states that ds3os uses its own save files, so as long as you do not copy ds3os saves back into your retail saves, you should be fine. The project deliberately does not provide an automation path to copy ds3os saves back to retail saves, for safety, though the FAQ explains how to do it manually by renaming the files.

Loader, Server and the config file that drives both

The layout after a build is simple, which is one of the project's clearer points. Once built you have a folder called Bin with two subfolders of relevance: Loader and Server. Running the loader gives you the option to create a server or join an existing one.

For a dedicated server you run Server.exe from the Server folder, and that starts the custom server on your machine. On its first run the server emits the file Saved\default\config.json, which holds matchmaking parameters. The README says you can adjust them and apply changes by restarting the server. The same file carries the password setting, where a password is entered when attempting to launch the game against a protected server.

The configuration file also decides which game the server hosts. The FAQ explains that after running the server once, the GameType parameter can be changed between DarkSouls2 and DarkSouls3. That single parameter is what switches a host between the two supported titles, which is convenient for operators who want to run both.

The loader is the other half of the story. It has to patch the game's memory so the retail client connects to your server instead of the official one, and that patching needs administrator privileges. The loader also carries a cog icon at the bottom for settings, including a button to copy retail saves into the ds3os save area.

Running the server in Docker with a mounted Saved folder

Two containers are published and the README says they are updated automatically each time a new release is made. The first, timleonarduk/ds3os, is the main server and the one the README says you almost certainly want. The second, timleonarduk/ds3os-master, is for the master server, and the README suggests you only need it if you are forking ds3os.

The quick way to run the main server is a single command. It creates a directory on the host, gives it to the uid and gid the container expects, and starts the container with a memory limit, an always-restart policy, host networking, and a bind mount so the configuration files live on the host filesystem at /opt/ds3os/Saved:

sudo mkdir -p /opt/ds3os/Saved && sudo chown 1000:1000 /opt/ds3os/Saved && sudo docker run -d -m 2G --restart always --net host --mount type=bind,source=/opt/ds3os/Saved,target=/opt/ds3os/Saved timleonarduk/ds3os:latest

Host networking is the part to think about. It keeps the port setup identical to a native run, which is convenient, but it also means the container shares the host network namespace, so the port forwarding and firewall steps described further down apply to the container exactly as they would to Server.exe.

If you prefer to build the images yourself, the repository carries a Dockerfile per game, DarkSouls2.Dockerfile and DarkSouls3.Dockerfile, plus a CMakeLists.txt at the root. There is also a Nix setup, with flake.nix, default.nix and flake.lock.

Why a client cannot connect and the checklist behind it

The README devotes a section to the case where the game launches but cannot connect, and the causes are worth walking through because they cover most real cases.

The first is privileges. The launcher patches the game's memory to redirect it to the new server, and that requires admin rights. If the loader cannot patch the client, nothing else matters.

The second is routing. If you host the server yourself, the README asks you to forward a set of ports on your router for both tcp and udp: 50000, 50010, 50050 and 50020. It also asks you to allow the server through Windows Defender Firewall, giving the path Start Bar, Windows Administrative Tools, Windows Defender Firewall with Advanced Security, then Inbound/Output Rules.

The third is configuration drift. The server autconfigures itself on first run, but the README warns it may pick incorrect values when the host has multiple network adapters. You are told to open the configuration file and check the settings, with ServerHostname named as one of the most critical values. That file is written to Saved\default\config.json, which is also the file the Docker bind mount exposes at /opt/ds3os/Saved.

There is also a hard dependency worth repeating, because it is stated as a note in bold: the Steam client, with no login needed, must be installed when you run Server.exe, otherwise Server.exe fails to initialize.

Dark Souls 3 is the finished half, Dark Souls 2 is not

The feature table in the README is the most honest summary of the project's maturity. For Dark Souls 3, the supported column is marked for network transport, announcement messages, profile management, blood messages, bloodstains, ghosts, summoning, invasions, auto-summoning through covenants, matchmaking, leaderboards, quick matches in arenas, telemetry, ticket authentication, master server support, loader support, the admin web interface, sharding and a Discord activity feed.

The Dark Souls 2 SOTFS column is thinner and, more importantly, is labelled experimental. The README states plainly that Dark Souls 2 support is still experimental and under development with a high probability of things not behaving correctly, and the table describes it as stable enough for use only for Dark Souls 3.

Two entries differ between the columns for a structural reason. Mirror Knight is marked not applicable for Dark Souls 3 and supported for Dark Souls 2 SOTFS. Bell Ringing is the other way round, supported for Dark Souls 3 and not applicable for Dark Souls 2.

Behind the table the README says most of the core functionality works, with some variance from the retail game, and that the aim is to match retail server behaviour more closely and improve unofficial servers generally. The listed roadmap is per-server mod settings, for example letting a server remove the summon limit, and a better anticheat with checks stricter than the publisher's. On the Dark Souls 2 side, that roadmap should be read as description of a work in progress rather than a promise.

Building from source and what the release history says

Downloads come from the GitHub releases page rather than from a package index, and the release tags follow a plain scheme: v0.42.0.0-main, v0.41.0.0-main, v0.40.0.0-main. There is no tagged release newer than 2024-08-14, even though the branch itself received a push on 2026-07-10. The gap between the two is the thing to plan around. A release download gives you a known configuration, while the branch may contain changes that have never shipped as a binary.

Building locally uses CMake with the top-level CMakeLists.txt, and the repository is organised with Source for the server code, Protobuf for protocol definitions, Tools for auxiliary tooling and Resources for assets. There are separate Dockerfiles for Dark Souls 2 and Dark Souls 3, so the container build and the native build are both supported paths.

Support for questions and technical problems runs through the project Discord, and the README asks users to join rather than to open a general question elsewhere.

On licensing, the repository is MIT licensed, which is permissive for a server implementation that people may want to modify for their own community. Read the LICENSE file for the terms, and note that the game itself remains the property of its publisher, so the licence covers the server code and not the game content.

Editorial conclusion

Use ds3os if you want to play Dark Souls 2 or 3 with friends on infrastructure you control, with mods, without touching a retail account, and the Dark Souls 3 support is the part that is described as stable enough for use. Do not adopt it as a replacement for retail matchmaking, and do not read the Dark Souls 2 column as production ready, since the README marks it experimental and under development with a high probability of things not behaving correctly. Before running anything, confirm that the Steam client is installed on the host because Server.exe fails to initialize without it, decide whether you need the master server container or only the main one, and pin a release rather than tracking the branch, because the most recent published release is v0.42.0.0-main from 2024-08-14 while the last push was on 2026-07-10.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TLeonardUK/ds3os on GitHub