ReHLDS: a reverse-engineered and bug-fixed Half-Life dedicated server

What the project is and how it was made

ReHLDS describes itself as a reverse-engineered and bug-fixed HLDS, and the README explains the method with unusual specificity. It is the result of reverse engineering the original HLDS, builds 6152 and 6153, using the DWARF debug information embedded in the Linux version of HLDS, engine_i486.so.

That detail explains the shape of the whole project. Debug information in a shipped binary is a map of the original code, and it is what turns a decompilation effort into a reconstruction. The source has names, types and structure rather than guesses, which is why the project can produce something that behaves like the original rather than something that merely resembles it.

The second sentence is the one that matters to a server operator: along with the reverse engineering, a lot of defects and potential bugs were found and fixed. The bugs were not introduced by the reverse engineering; they were in the original, and a faithful reconstruction is what makes them visible.

The repository is a C and C++ project with a CMakeLists.txt at the root, a build.sh, an msvc/ directory for Microsoft Visual Studio, a dep/ directory for dependencies, and the rehlds/ directory holding the engine itself. There is also a version_script.lds for linker versioning and a CHANGELOG.md.

The scale of adoption is stated with a link rather than a claim: you can try playing on one of many servers using ReHLDS, with a Game Tracker search on the server variable that reports the version.

The most recent release is 3.15.0.896 from 2026-05-18, preceded by 3.14.0.857 from 2025-03-27 and 3.13.0.788 from 2023-07-12. The version scheme encodes the HLDS build it tracks and a patch count.

The stated goals and the licence transition

The project lists two goals, and the second one is framed as future work rather than as done.

The first is to provide a more stable version of the Half-Life dedicated server than the official one, with an extended API for mods and plugins. The extended API is the practical difference for anyone running a public server, because it is what lets a plugin reach engine state that the original build keeps private, which in turn is what the anti-cheat and rate-limiting features below are built on.

The second goal is performance optimisations, with use of SSE for vector math given as the example, and the README is explicit that this is another goal for the future. That is worth noting because the current builds already require the SSE instruction sets to run, so SSE support exists in the binary, but the vectorised maths is not the point of the project yet.

The licence story is the more consequential administrative fact. ReHLDS was originally released under GPLv3 and transitioned to the MIT Licence in July 2025 with the agreement of the core contributors, and the details are in a LICENSE-TRANSITION.md file in the repository root.

That transition is unusual and it is worth understanding why it happened. The engine is a reconstruction of Valve's code. Valve's own HLDS was distributed under a restrictive Half-Life licence rather than an open source licence, which is why the original engine was never open source in the first place, and the GPL was the pragmatic choice for a reverse-engineered derivative. Moving to MIT removes the copyleft obligation, which for a server engine that people distribute as binaries is a real change for downstream users and for anyone embedding it.

The project also carries the CII Best Practices badge, which is an external assessment of the project's own development practices rather than a claim about the engine.

Installing it over an existing HLDS, and the compatibility limits

The installation model is a replacement rather than a separate install, and it depends on which HLDS you have.

ReHLDS is fully compatible with the official pre-anniversary edition of HLDS, engine version 8684 and below, downloaded by steamcmd. All you have to do is download the ReHLDS binaries and replace the original swds.dll on Windows or engine_i486.so on Linux. For Windows you can also copy a swds.pdb file with debug information.

The caution is that ReHLDS is not compatible with an old 5xxx or below platform downloaded by hldsupdatetool. That distinction matters because the two routes to a Half-Life server install different versions, and the old hldsupdatetool route gives you one of them.

The steamcmd route is two commands:

app_set_config 90 mod cstrike
app_update 90 -beta steam_legacy validate

The binary downloads come in two flavours, release builds from the GitHub releases page and dev builds from the actions workflow. The release archives are signed with GPG, and the README gives the public key fingerprint and a four-step procedure: download the .asc key file, import it with gpg --import, download the release archive and its .asc file, and verify with gpg --verify some-rehlds.zip.asc some-rehlds.zip. The key is published on a public keyserver with the fingerprint given.

That signing step is not decoration for a file that replaces a binary on a machine that will run as a network service. A server owner has no way to audit a game engine, so the release signature is the only available check that the bytes are the ones the project published.

The CPU requirement is explicit too: ReHLDS binaries require SSE, SSE2 and SSE3 instruction sets to run, and can benefit from SSE4.1 and SSE4.2. That rules out hardware from before roughly 2004.

The binary compatibility caveat, and what it costs you

One caveat is repeated with emphasis, and it is the first thing to check before planning a migration.

ReHLDS is not binary compatible with the original HLDS, since it is compiled with compilers other than the ones used for the original HLDS. The consequence stated is that plugins that do binary code analysis, Orpheu for example, probably will not work with ReHLDS.

That is a narrower statement than it first looks, and the distinction is useful. Orpheu works by scanning the running engine's memory for known function signatures and then calling into them. If the compiler lays out the code differently, the signatures do not match and the hook silently fails to attach. It is not that Orpheu is deliberately blocked; it is that the addresses and layouts it depends on no longer exist.

So the plugins that break are the ones that reach into engine internals at the machine level. Plugins that use the documented ReHLDS extended API, which is the point of the first goal, are unaffected, and plugins that only use the standard Half-Life mod interface are unaffected. The practical question for a server owner is whether your plugin stack is built on Orpheu hooks, and if it is, whether the replacement exists for ReHLDS.

This is also the reason the extended API matters more than the bug fixes do in some cases. A rebuild that is not binary compatible removes an entire class of tooling, and the answer is to provide a supported alternative rather than to hope the offsets happen to match.

The configuration surface, and the anti-flood and anti-cheat cvars

The configuration list is where the practical differences from the original engine show up, and it is long enough that the naming pattern tells you what the project is for.

There are the familiar server settings and then a family of sv_rehlds_ prefixed ones that do not exist in the original. The anti-cheat group is the move rate limiter. There is sv_rehlds_movecmdrate_max_avg for the maximum average level of move commands, with a default of 400, and sv_rehlds_movecmdrate_avg_punish for the ban length in minutes, default 5. There is a separate max burst level with a default of 2500 and its own burst punish value, and an identical quartet for string commands: sv_rehlds_stringcmdrate_max_avg with a default of 80, its punish, its max burst of 400 and its burst punish.

That is a coherent anti-cheat design. A player who sends move commands slightly too fast for a while is banned for five minutes, and a player who bursts past a hard limit is banned longer. The average and the burst are separate thresholds because they catch different attacks: sustained acceleration and a single spike.

The download-flood group is the other half. sv_rehlds_dlfile_bucket_size is the maximum size of the dlfile token bucket, with 0 meaning automatic, based on the map resource list size plus 16, and a negative number disabling dlfile rate limiting entirely. sv_rehlds_dlfile_refillrate is how many tokens are restored per second, default 50, and sv_rehlds_dlfile_punish is the ban length for dlfile flooding, whose default of -1 means a kick rather than a ban.

The remaining entries are behavioural fixes and compatibility switches: sv_rehlds_force_dlmax forces a client's cl_dlmax to 1024 to avoid excessive packet fragmentation, sv_rehlds_hull_centering uses the centre of the hull instead of the corner, sv_rehlds_send_mapcycle controls whether mapcycle.txt is sent in the serverinfo message, and sv_rehlds_userinfo_transmitted_fields restricts which userinfo keys are sent to clients over the network, where each key must be prefixed by a backslash and unlisted fields are simply not transmitted.

The userinfo one is worth a second look, because it is a bandwidth and privacy setting rather than a cheat protection. The wiki page it links explains how to collect a sufficient set of keys for your server.

Limits: a reconstructed engine, a legacy target and a moving baseline

The limits are worth stating plainly for anyone considering a migration.

The first is that this is a reconstruction of a 1998 engine. ReHLDS tracks HLDS builds 6152 and 6153 for its reverse engineering and is compatible with the pre-anniversary edition at engine version 8684 and below. Every upstream Valve release that arrives for this branch of Half-Life has to be accommodated, and the version numbering in the release tags, 3.15.0.896, reflects that the number is the HLDS build followed by a ReHLDS patch count.

The second is the binary compatibility problem described above, which rules out a category of plugin.

The third is the instruction set floor. SSE, SSE2 and SSE3 are required, which is not a constraint for any current machine but does mean the project cannot run on the embedded or vintage hardware some dedicated servers still use.

The fourth is the project scope. The stated goals are stability, an extended API and future performance work. ReHLDS is not a modern engine, does not add new game features, and does not change the game. It is a better-maintained version of the thing Valve shipped and stopped updating, which is a narrower proposition than it can sound from the outside.

The fifth is that performance optimisation is explicitly a future goal, so the case for ReHLDS rests on stability and on the anti-cheat and anti-flood protections rather than on throughput.

The sixth is the release cadence. The tags show roughly a year between major versions, 3.13 in July 2023, 3.14 in March 2025 and 3.15 in May 2026, and the repository has both release builds and dev builds from CI, so a deployment can track either a stable tag or the tip.

ReHLDS against the official HLDS and against running the game instead

Two comparisons make the choice clearer.

The first is against the official HLDS. Valve stopped updating the dedicated server for the pre-anniversary branch, and the engine you get from steamcmd is the one that shipped years ago with its defects intact. The difference in approach is that ReHLDS has been through the defect list. The reverse engineering found bugs, and fixing them is the first stated goal, and the extended API plus the anti-flood and anti-move protections are the second. The cost is that you are running a binary compiled by someone other than Valve, that you lose Orpheu-style plugins, and that you are trusting a community project with a signed release.

For a public server that has to survive players who try to break it, that trade is usually worth it. The move and string command rate limiters exist because the original engine has no equivalent, and a server without them is a server that will eventually be taken down by a script.

The second comparison is against not running a dedicated server at all. For a small community, listen server hosting or a modern platform with its own anti-cheat removes the need for the engine entirely, and the operational burden of a self-hosted GoldSrc server, patching, source mod updates and a Linux box you maintain, is not small.

What ReHLDS cannot do is make an old game new. It keeps the server alive, stable and harder to grief, and it gives plugin authors a supported API. If your goal is a game with modern graphics, physics or networking, this is the wrong project and the comparison does not arise. If your goal is a stable Counter-Strike 1.6 or Half-Life server that people already play, it is the right shape of tool.

Editorial conclusion

Adopt ReHLDS if you run a GoldSrc server and want a maintained engine with anti-cheat and anti-flood protections that the original build does not have, and you are willing to drop plugins that analyse the binary at runtime. Do not adopt it if your plugin stack depends on Orpheu-style binary analysis or on the 5xxx-era HLDS packages. Verify first that you are on the pre-anniversary HLDS that steamcmd installs, that your CPU supports SSE, SSE2 and SSE3, and that you verify the release signature with GPG before you deploy a downloaded archive.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. rehlds/ReHLDS on GitHub
5. Releases