DiIiS reimplements the Diablo 3 server protocol in C# on .NET 7

What the server actually implements, and where it stops

The feature list is unusually specific about completeness, which is more useful than a claim of being fully functional.

Account creation, authorisation and lobby are implemented, along with a complete chat system and friends, and a complete clan system. The Necromancer class mechanics are in. Item generation includes in-game affixes and there is a set item system. All main scripts for the story quests across five acts are implemented, with basic scripts and a generator for Adventure Mode, and the basis of Nephalem Rifts.

The artificial intelligence entries are the most honest numbers in the project: personal AI for 80 percent of minions, for 40 percent of all monsters, and for half of the bosses. Those percentages tell you the remaining 20 percent of trash mobs, 60 percent of elites and half the boss fights will behave incorrectly or not at all.

The dungeon generator is described as basic DRLG, which is the procedural dungeon algorithm the game uses. Basic means dungeons generate and are traversable, not that the layouts match the retail distribution.

The development roadmap at the end of the README is effectively the inverse of the feature list. It lists unfinished work in Greater Rifts, from ensuring the rift closes after 15 minutes and fixing the exit portal teleport, to the death time penalty of plus five seconds per death after the third inside a GR, mob removal after completion, the next-level portal display and a bug that shows only GR level 13 Torment 2. The items section lists Kanai's Cube legendary power extraction, the enchant NPC reroll, Ramaladni's Gift socketing, gem validation, affix validation, set bonus validation and legendary power duplicate checks.

One restriction is stated outright: the Donate Store implementation is removed.

Two branches with different purposes

The branch structure carries real instructions and they are easy to miss.

Developers are told to contribute using the community branch, to always create their branches from it, and to follow the roadmap. Enthusiasts who want to test the server are pointed at the test-stable branch or the community branch. The default branch on the repository is test-stable.

So there is a stable-testing line for people who want a running server, and a community line where development happens. Anything you build from should come from one of those two rather than from whatever is on the default branch when you clone.

The repository also carries disclaimer.md, linked from the top of the README as a disclaimer and project philosophy. That is the file to read before drawing conclusions about what the project is intended for, and it is referenced prominently enough that the maintainers consider it part of the documentation rather than an afterthought.

The source tree is under src/, with the server project at src/DiIiS-NA/Blizzless.csproj. There is a db/ directory and a db_old/, and the Docker Compose file mounts ./db/initdb into the database container's init directory, so schema initialisation is handled by the database image's entrypoint.

The database, and the contradiction between the README and the compose file

The manual database path asks for PostgreSQL 9.5.25, two databases named diiis and worlds, credentials edited in database.Account.config and database.Worlds.conifg, and a restore of worlds.backup into the worlds database. Note that the second filename is spelled conifg rather than config, which is the kind of detail that costs an hour if you type it correctly from memory and the build does not find it.

The Docker path supersedes it. docker-compose.yml defines two services: diiis-na-server built from the local Dockerfile, and db running the postgres:17 image with the postgres user and a matching password and a database named diablo.

So the README asks for PostgreSQL 9.5.25 and the compose file runs 17. That is a nine-major-version gap and the two setups are unlikely to behave identically. If you follow the manual path and something about your installation behaves oddly, the version difference between the two documented paths is the first thing to check.

The compose file also gates startup on the database being healthy, using depends_on with a condition of service_healthy, and the healthcheck is pg_isready -U postgres on a ten second interval with five retries. That ordering is the reason the first start is slow rather than broken.

Building it, and the six ports a game client needs

The compile step needs the .NET 7 SDK and runtime, and the README is specific that you want just the runtime rather than the ASP.NET or desktop packs. The publish command is:

dotnet publish ./src/DiIiS-NA/Blizzless.csproj --configuration Release --output ./publish

After publishing, three steps remain before a client can connect. For anything other than a local game, copy config.mods.json into the folder and modify it as needed, with a file generated automatically from config.ini for now. Then update config.ini in the published folder with your network's BindIP and PublicIP records. Then launch the Blizzless executable from the publish folder and wait, because on first run it creates a hierarchy.

Account creation happens in the server console, not through a web interface: `!account add Login Password Tag` creates an account, and adding a fourth argument of owner creates it with the owner rank. The example given is !account add username@ YourPassword YourBattleTag, and the same command with owner appended.

The port list appears in both the Dockerfile and the compose file and is identical: 1345, 1119, 83, 2001, 9800 and 9100. Six ports for one client connection is a reminder that this is not a single HTTP service. The Dockerfile publishes the same six and sets the entrypoint to ./Blizzless, and the compose file publishes the same set with the container named diiis-na-server.

Redirecting the retail client is the part with legal and practical weight

Getting an unmodified Diablo 3 client to talk to your server requires two interventions, and both are documented with a straight face because they are unavoidable.

The first is a certificate. Install bnetserver.p12 from src/DiIiS-NA/, password 123, because the game verifies the CA root certificates. You are telling the client to trust a certificate authority you generated, which is only safe on a machine you control.

The second is a redirect, and there are two documented methods. Method one is the hosts file, at %WinDir%\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux, mapping 127.0.0.1 to us.actual.battle.net and to eu.actual.battle.net. The README states plainly what follows: after the modification the official Battle.Net application will not be able to connect to the server.

Method two avoids the hosts file by hex-editing the client executable. The README lists the null-terminated strings to find and rewrite with your own address: eu.actual.battle.net, us.actual.battle.net, cn.actual.battle.net and kr.actual.battle.net. That is binary patching of a shipped commercial client, which is squarely in territory where the licence of that client matters, not just the licence of this repository.

The client is then launched with the x64 or x86 executable and the -launch argument, and you log in with the account you created.

Where a real realm or a different emulator fits better

For actually playing the game, nothing here competes with Blizzard's servers. This project has no live economy, no real players and no retail progression, and the roadmap documents how far the endgame systems are from complete. The Donate Store removal means even the monetisation hook is gone.

The realistic uses are research and local play. A developer studying how a modern action RPG server handles world state, chat, clans and dungeon generation has very little comparable open source, and a complete implementation in C# with a readable roadmap is a rare thing to read. That is the strongest argument for the project.

For LAN multiplayer with friends, the README lists LAN as a feature and the setup supports it through the same mechanism, with the local game path skipping the mods file and the public game indication. That is a narrower and more achievable target than online play.

Against other private server projects, the differentiator is documentation density. The roadmap, the commands list at docs/commands-list.md, the world settings at docs/game-world-settings.md and the issue report form at docs/report-form.md mean a contributor can find out what state a system is in without reading the source. Projects without that tend to accumulate dead code nobody can safely touch.

Licence is AGPL-3.0, which for a server you run and expose over a network means source disclosure obligations if you modify and offer it. That is a deliberate constraint on commercial hosting and worth understanding before deploying this anywhere public.

Editorial conclusion

DiIiS fits a developer who wants to study a live game server protocol, run a LAN party server, or work on dungeon and item systems without a live service. It does not fit anyone wanting a match of the retail game, since progression, balance and endgame systems are incomplete, and it does not fit a deployment that keeps Battle.net reachable, because the hosts-file redirect the client needs blocks the official client. First step is docker-compose up from the root, then reading docs/commands-list.md and confirming client version 2.7.4.84161 before you attempt any client modification.

Frequently asked questions

Official sources

1. blizzless/blizzless-diiis on GitHub
2. Issues
3. License: AGPL-3.0
4. README