blizzard-legacy-dl: The Legacy Blizzard Games, Straight From Blizzard

By Indie Kings | November 4, 2026

Updated November 4, 2026: blizzard-legacy-dl downloads the legacy Blizzard games, Diablo II, StarCraft and Warcraft III, directly from Blizzard's own servers without running Blizzard's downloader. It is a single static Zig binary for Windows, macOS and Linux on x86-64 and arm64, plus a Docker image, and version 0.2.0 shipped on September 23, 2026 with 256 downloads. The repository holds 4 stars under MIT.

Image: GitHub social preview card for the blizzard-legacy-dl repository. Credit: jaenster/GitHub.

Per the official repository README, blizzard-legacy-dl downloads the legacy Blizzard games from Blizzard's own servers without running their downloader. The games in scope are Diablo II, StarCraft and Warcraft III, and the tool is written in Zig. The distinction matters: this is not a mirror, a torrent tracker or a third-party archive. It fetches from Blizzard's infrastructure and verifies what it received.

The design premise is that a product code is all the tool needs. Given a code, it fetches the stub, its access token and the payload itself. The README lists the products as D2DV for Diablo II, D2XP for Lord of Destruction, STAR for StarCraft, WAR3 for Reign of Chaos and W3XP for The Frozen Throne. An operating system selector covers Windows and Mac builds, and a locale selector defaults to en-US with support for a long list of others.

What it actually fetches

The install story is deliberately unremarkable, which is the right property for a downloader. There are binaries for Windows, macOS and Linux, each in x86-64 and arm64, with no runtime to install, and a Docker image for the rest. A one-line shell installer picks the right build and checks it against the release's checksum file, and there is a Homebrew formula in a tap.

The Docker path is stated as a single command that mounts the current directory and fetches a product into it, which is useful for anyone who does not want a binary on their machine at all. The README also mentions that a downloader executable you already have works in place of the product code, and so does a plain torrent file. That is a thoughtful fallback for anyone who has already gone through Blizzard's own process and wants to use this tool for the later steps.

The two sizes that are published are worth noting because they show the tool is not archiving anything unusual. These are the sizes of the games as Blizzard distributes them, and the tool's job is to assemble that payload faithfully rather than to compress, patch or otherwise modify it.

More than a download command

The command surface is broader than a fetch command, and the README documents each subcommand's purpose. The info command reports a stub's name, size, piece count, servers and token before anything is downloaded. The files command lists the payload's file list. The plan command prints the URL for a specific piece and the files it spans. The verify command re-checks an assembled payload against its piece hashes, and it is useful on its own against a copy obtained some other way. The run command walks the full downloader sequence step by step and prints each stage.

There are also two commands aimed at hosting rather than at consuming. The stubs command downloads every product, locale and operating system stub there is, walking a documented locale list and keeping whatever answers. The mirror command copies a payload from Blizzard into a directory so it can be served as a mirror. Together those two make the tool usable for an organisation that wants to host legacy installers internally rather than have every machine fetch from Blizzard directly.

The proxy subcommand is the one to read carefully. It logs HTTP requests passing through it and forwards them, which is a debugging aid for anyone who wants to see exactly what the downloader protocol does. The README warns that it listens on loopback by default and that passing a bind address to expose it makes it an open relay for anything else on that network for as long as it runs. That warning is in the README rather than discovered in an incident.

Resume, verification and the piece map

The download engine is built for unreliable connections, which is the correct priority for a payload measured in gigabytes. Interrupted downloads resume: rerun the same command and every piece already on disk that matches its hash is left alone, so only what is missing gets fetched. Files are preallocated at full length and each piece is written where it lands, so a fetch does not care about order and a resume does not depend on having finished a contiguous region.

Pieces are fetched several at a time, four by default, and the README gives a concrete reason: on a home connection, eight jobs is roughly three and a half times faster than one. It notes that Blizzard's own client does the same and that neither it nor this limits the download rate, only the number of requests in flight. That is an accurate description of the trade-off and it avoids claiming a bandwidth cap that does not exist.

The terminal presentation is a small but well-chosen detail. On a terminal, progress is drawn as a piece map, one cell per run of pieces, shading in as they arrive and turning green when a cell is complete. Because pieces are fetched in a shuffled order the map fills in scattered rather than left to right, and the README says that plainly so nobody mistakes it for a bug. Piped output or a continuous integration environment falls back to a plain counter, which is the correct behaviour for logs.

The option list covers the practical cases: fetching a piece range, retry counts, a base URL to use a mirror, a cookie to override the access token, sequential instead of shuffled fetching, reading configuration from a file, and skipping the tracker announce. The payload always lands in a subdirectory named after the torrent rather than being strewn across the destination, which is the kind of default that prevents an afternoon of cleanup.

Building a playable folder without the installer

The most interesting subcommand is install. Fetching a payload gives you Blizzard's files; install goes a step further and reads the payload's own install script to build a playable game directory from it, without running Blizzard's installer or Windows. The README shows both a current-version install and a specific older version, naming 1.13c as an example.

That capability matters for the wider preservation ecosystem around this game. A large number of Diablo II tooling projects, including the mod managers and the private server infrastructure, expect an existing 1.13d or 1.14 installation folder. Being able to produce one from a product code, on Linux, without an installer, removes a step that has historically required a Windows machine or a compatibility layer. The README does not oversell it, and it presents the command alongside the simpler fetch rather than as a replacement.

The licence position is straightforward. The tool is MIT licensed and it redistributes nothing. It fetches from Blizzard's servers and verifies the results against the payload's own hashes. The games themselves remain Blizzard's, and a user still needs to be entitled to what they download. The README does not need to say much here because the architecture speaks for itself: there is no hosted copy, and every byte comes from the source.

Where a small project stands

The repository was created on August 25, 2026, and was last pushed on October 26, 2026. It holds 4 stars and no forks or open issues under MIT, and is written in Zig. Two releases are published: version 0.2.0 on September 23, 2026 with 256 downloads across its assets, and version 0.1.0 on August 25 with 28. The per-asset breakdown for 0.2.0 shows the macOS arm64 build leading at 31 downloads, with the Linux x86-64 static build at 35 and the Windows x86-64 build at 12, which is a plausible distribution for a small developer tool in this community.

The star count is very low and the reader should weight that accordingly. This is infrastructure rather than a product, and it exists because the author's other projects, the dedicated server and the map generator, need a reproducible way to obtain a game installation. Tools of that kind accumulate users through the projects that depend on them rather than through their own visibility. The release download numbers are the better signal, and 256 downloads on a single release of a specialised downloader is a genuine audience.

The multimodal coverage is complete rather than aspirational. Windows, macOS and Linux binaries, both major architectures, a Docker image, a shell installer that checks checksums, a PowerShell installer for Windows, and a Homebrew tap. For a tool this small, shipping every one of those is a deliberate choice about who can use it without building anything.

Our take: the install subcommand is the reason to care about this beyond convenience. Being able to turn a Blizzard product code into a playable 1.13c or 1.14d folder on Linux, without an installer and without Windows, is the missing first step for a whole ecosystem of Diablo II tooling. The 4 stars understate it, and the resume behaviour and piece verification suggest it was built for a real, slow download rather than a demonstration.

FAQ

Does blizzard-legacy-dl host or redistribute the games?
No. Per the official repository README, it downloads the legacy games from Blizzard's own servers without running Blizzard's downloader. The binaries redistribute nothing, and you still need to be entitled to what you fetch.

Which games and platforms are supported?
Per the README, Diablo II, Lord of Destruction, StarCraft with Brood War, Warcraft III: Reign of Chaos and The Frozen Throne, with a Windows or Mac build selector and a locale list that defaults to en-US.

What happens if my download is interrupted?
Per the README, interrupted downloads resume. Rerun the same command and every piece already on disk that matches its hash is left alone, so only the missing pieces are fetched.

How does it verify what it downloads?
Per the README, pieces are verified against their hashes, files are preallocated at full length, and a separate verify command can re-check an assembled payload, including one obtained some other way.

Can it build a game folder instead of just downloading one?
Yes. Per the README, the install command reads the payload's own install script and builds a playable game directory without running Blizzard's installer or Windows, and it can target a specific older version such as 1.13c.

Is the proxy command safe to expose?
Not by default. Per the README, the proxy listens on loopback, and passing a bind address to expose it makes it an open relay for anything else on that network for as long as it runs.

Bottom Line

blizzard-legacy-dl is a small, focused tool that solves a specific problem properly: obtaining a legacy Blizzard game from Blizzard's servers, with piece-level verification, resumable downloads and a progress map, on every desktop platform and in a container, without running an installer.

The install subcommand is the part with wider consequences, because it can produce a playable 1.13c or 1.14d folder on Linux without Windows in the loop. Four stars and 256 downloads on the current release describe a tool that is infrastructure for other projects rather than a destination of its own, and the licence and verification behaviour are the right shape for that job.

Related: D2Decomp: Diablo II Rebuilt as a Native Engine, Mod Diablocraft: Diablo 3 Systems Rebuilt on a WotLK AzerothCore Server

Sources: per the official blizzard-legacy-dl repository README at github.com/jaenster/blizzard-legacy-dl, fetched in full on November 4, 2026, including the product table, command reference, download details and proxy warning; repository metadata (4 stars, no forks, no open issues, MIT, created August 25, 2026, language Zig, last pushed October 26, 2026) re-verified via the GitHub API on November 4, 2026; release notes and download counts for v0.2.0 (September 23, 2026) and v0.1.0 (August 25, 2026) from the same repository.