Why we built a custom panel instead of using generic hosting software

When we started Zeros Host, we had a straightforward choice: use an existing game server control panel and build on top of it, or build something purpose-made for the games we support. We chose the second option. This post explains why, what it meant in practice, and what the honest tradeoffs are.

What generic panels do well

Generic panels - Pterodactyl, Multicraft, and similar tools - are not bad software. They handle the universal parts of game server hosting reliably: file access, console output, start/stop controls, resource limits, SFTP, scheduled tasks. If you are running fifteen different games and need one tool to manage all of them, a generic panel is the sensible choice.

The problem is that "universal" and "useful for a specific game" are different things. A panel that works for Minecraft, Terraria, Rust, CS2, and thirty others by necessity treats each one the same. It has no opinion about what matters to a Garry's Mod server operator, because having opinions about every game simultaneously is not tractable.

What Garry's Mod actually needs

Garry's Mod servers are Lua-driven. Most of the meaningful configuration is in Lua files. Most of the ways things go wrong are Lua-related. Most of the tooling a GMod server operator actually wants has nothing to do with file management or resource limits - it has to do with the addon ecosystem and how Lua interacts with the game.

Concretely, here is what that means for us:

Mod Manager - installing addons on a GMod server is not drag-and-drop. Addons have dependencies, Workshop IDs, and load order implications. Our Mod Manager handles Workshop sync, dependency resolution, and update tracking. A generic panel file manager cannot do this because it does not know what a Workshop ID is.

Backdoor Scanner - paid GMod addons are frequently cracked, and cracked versions often include Lua backdoors. These are not detectable by looking at file names; you have to inspect the code. Our scanner checks addon files against known backdoor patterns before they are loaded. This is only possible because we built tooling that understands Lua and the GMod addon format.

Workshop integration - a DarkRP server typically pulls dozens of Workshop addons on first run, which adds significant startup time and requires the server to have an authenticated Steam session. We handle Workshop authentication and caching at the platform level, so operators do not have to manage it manually per server.

DarkRP Config Builder - DarkRP configuration is a set of Lua files with specific syntax. Getting it wrong breaks the gamemode silently or with cryptic console errors. Our Config Builder provides a structured interface for jobs, shipments, entities, and door groups, then generates valid Lua. This is not something a generic file editor can do.

The honest tradeoffs

Building game-specific tooling costs development time. The Mod Manager, Backdoor Scanner, and Config Builder each required understanding the game deeply enough to model it in software. That time cannot be spent on other things - which means we support fewer games than a generic panel would allow.

Right now we support Garry's Mod, Minecraft, Terraria, and Project Zomboid. Each one has game-specific tooling beyond the generic hosting baseline. Adding a new game is not a matter of pointing the panel at a new binary; it means building the tooling that makes the panel useful for that game's operators.

We think that tradeoff is correct. A customer hosting a DarkRP server gets meaningfully more useful software than they would with a generic panel. But it does mean we are not the right host for every game, and we do not pretend otherwise.

What this means for future games

We will add new games when we can build tooling that makes them genuinely better to host here than elsewhere. We will not add games just to expand the list. That pace is slower than some competitors, but the alternative is a generic panel with a longer game list and no particular reason to prefer it.