Bringing shut-down MMOs back to life, offline, on a Steam Deck

Preserving shut-down MMOs on a handheld you already own

This is a collection of one-command installers, Docker scripts and beginner-friendly guides for running classic MMO private servers entirely offline on a Steam Deck, any Linux machine, or Windows through WSL2. The premise is stated plainly in the README's own framing: games with servers that were permanently shut down, some cited by name, can be brought back to life on hardware most readers already own, with no subscription, no internet requirement, and no risk of another shutdown taking the game away a second time.

The project author frames it as a personal project born from watching beloved game servers disappear one by one and wondering whether a Steam Deck could bring them back offline, and the guides that resulted are the answer. Eight games are listed as fully working today, spanning three eras of World of Warcraft, two versions of a 2009-era RuneScape emulator, MapleStory's pre-Big-Bang era, and Mu Online, with three more in active progress and a long list of further titles planned, each paired with the specific open-source emulator project the guide is built around.

Drawing the legal line clearly, in its own words

A project like this lives or dies on where it draws the line between preservation and piracy, and this one draws that line explicitly rather than leaving it implied. The README states directly that the project is not affiliated with, endorsed by, or associated with the original game publishers, that it does not operate, host or endorse any public server, that no copyrighted game files are distributed by the project, and that users must supply their own legally obtained game client before any guide here does anything for them.

The bulleted summary that follows is equally direct about what the project will not do: it does not help run public servers, does not support monetising a private server, and does not provide or link to game client downloads anywhere. Coupled with crediting each underlying open-source emulator community by name and encouraging readers to support those projects directly, the project positions itself squarely as documentation and automation layered on top of existing open-source emulator software, rather than as a source of the games themselves, which is the correct and only sustainable framing for a project openly building install guides around commercial MMOs whose original publishers never sanctioned any of this. This is not legal advice, and readers in any doubt about their own jurisdiction's rules on private server emulation should look into that independently.

A genuinely careful root-access decision, explained rather than hidden

The most technically interesting passage in the README has nothing to do with games and everything to do with how the installers handle root access, and it is worth quoting the substance of because most shell installers handle this far more carelessly. Adding a user to the Docker group is functionally a root-equivalent privilege change, since a member of that group can mount the host's own filesystem into a container and read or write anything on it. The README states the installers need root exactly once, to install Docker and make that group change, that they ask for consent before doing it, and that they deliberately do not drop any passwordless sudo rule into the system's sudoers configuration.

That last detail is the one that separates a careful installer from a careless one. A passwordless sudo rule left behind after installation is a standing, silent escalation path that persists long after the script that created it has finished running, exactly the kind of thing a security-conscious user checks for and exactly the kind of thing a lazy installer leaves behind without a second thought. Explaining the privilege implication in plain language, asking first, and explicitly declining to leave a persistent escalation path behind, is real security hygiene applied to a hobbyist project that had no external pressure requiring it to bother.

One command per game, with the same shape every time

Installation follows an identical two-step pattern for every supported game, which is a small consistency choice that pays off across eight-plus different guides: make the installer executable, then run it.

chmod +x install-wow-vanilla.sh && ./install-wow-vanilla.sh

The same shape repeats for every other title, from The Burning Crusade and Wrath of the Lich King through RuneScape, MapleStory and Mu Online, each with its own dedicated script rather than one installer branching on a game argument. Windows users get a PowerShell-native equivalent through a substrate installer run first, then the game-specific installer afterward. The README states each WoW installer handles the entire chain itself: detecting SteamOS and fixing its package manager's keyring, installing Docker if it is missing, downloading and compiling the actual server software, creating a default administrator account, and populating the world with bots so a freshly installed server does not feel empty.

Populating a fresh server with hundreds of active bots, filling dungeons, raids and the auction house, is the detail that makes an offline private server actually feel like the game rather than a technically correct but lifeless recreation, and the README's own bot table states a specific range of 600 to 800 concurrently active bots depending on the game version, with roughly a thirty-minute install time across the board.

Built on real emulator communities, not reinvented from scratch

None of the underlying server emulation is this project's own work, and the README is careful to credit that directly rather than letting the polish of the installers imply otherwise. The World of Warcraft guides are built on two established open-source emulator projects, one covering the Wrath of the Lich King era and another covering the earlier Vanilla and Burning Crusade eras, both with long-running open-source communities of their own; the RuneScape guides are built on a dedicated 2009-era emulator project with an accompanying HD client launcher; and the README states plainly that every other emulator linked throughout the guides deserves the same credit and the same encouragement to support it directly.

That division of labour, deep emulator engineering handled by established communities that have worked on it for years, and installation, configuration and beginner accessibility handled by this project, is the correct one. Reimplementing an MMO server from a network capture is a multi-year undertaking that several dedicated open-source teams have already done well; automating the fiddly, error-prone last mile of getting that server running correctly on a Steam Deck is a different, smaller, and genuinely valuable problem this project actually solves.

What to weigh before running any of this

Licensing here has two distinct layers worth separating cleanly. This project's own installer scripts and guides are released under the AGPL, a copyleft licence that, unlike a permissive licence, requires anyone who modifies the code and runs a modified version as a network service to make that modified source available to its users. That is a meaningful obligation for anyone thinking about hosting a customised version of these scripts as a service, though it places no such requirement on someone simply running an installer locally on their own Steam Deck. The emulator software each guide installs carries its own separate licence from its own separate project, most commonly a copyleft licence in its own right, and that licence is the one that actually governs the server software itself rather than this project's installer scripts.

The project reports 1,039 stars, 102 forks and 48 open issues, with the most recent release on 2026-09-13 and the last push on 2026-09-14, so it is under active, fast-moving development with a meaningful backlog of open issues for a project this young, consistent with a hobby project that has grown popular faster than one person can triage every report.

Before running any installer here, three steps in order. Read the Legal and Ethical Notes section in full and make sure your own use, personal, offline and single-player, stays inside the boundary it draws, since the project explicitly does not support public or monetised servers. Obtain your own legally sourced game client first, since no guide here provides one and every installer assumes you already have it. And read the root-access explanation before accepting the Docker group change, deciding deliberately whether you want that privilege level on your machine, since the README gives you the information needed to make that choice rather than making it for you.

Editorial conclusion

Dad's MMO Lab fits someone who owns a Steam Deck or a Linux machine and wants a shut-down MMO running offline again, without hosting a public server or needing anything beyond a legally obtained game client, and its consistent one-command installer pattern across eight-plus games is genuinely accessible to someone with zero Linux experience. Its Legal and Ethical Notes section is the part worth reading in full before anything else, stating plainly that this is preservation built entirely on established open-source emulator communities rather than a source of the games themselves, and its explanation of the Docker group's root-equivalent privilege, asked for explicitly rather than granted silently, is more careful security handling than most hobby installer scripts bother with. Obtain your own game client before running any installer, keep your use personal and offline as the project explicitly intends, and read the root-access consent prompt before accepting it so the privilege decision is one you actually made rather than one that happened to you.

Frequently asked questions

Official sources

1. DadsMmoLab/dads-mmo-lab on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases