How to sell Minecraft hosting with MCSManager

Minecraft hosting is where most game hosting businesses start, and for good reason: the demand is constant, the customers are patient with small providers, and the technical bar to a first paying customer is genuinely low. The panel you start on tends to be whatever ran on the hardware you had.

MCSManager is what a lot of people land on. It is open source, it is small, it spans several machines, and the property that decides it for many is that it does not require Docker. That single fact puts it on hardware where the Pterodactyl family is impractical, and it is worth understanding why before you build a business on top.

What MCSManager actually is

Two pieces, in the now-standard shape: a web panel and a daemon. The panel is the interface and the place cross-node administration happens; the daemon runs on each machine and is what actually starts, stops and supervises the processes. One panel can talk to many daemons, so growing means adding a machine rather than standing up a second panel.

It is written in TypeScript (Node.js and Vue on the front, Node.js on the daemons), which makes it light to run and easy to read if you ever need to know exactly what it does. Roughly 4,800 stars on GitHub at the time of writing, actively developed, and translated into several languages.

The scope is Minecraft first, with Steam-based titles alongside it: Palworld, Terraria, Project Zomboid and the rest of that family. If your catalogue is "Minecraft, plus the survival game everyone is playing this year", that maps onto MCSManager cleanly.

The Docker question, and why it decides things

Pterodactyl and its descendants require containers. That is a defensible design, since it gives you isolation and resource limits for free, but it also sets a floor on where you can run.

MCSManager supports Docker and does not insist on it. Servers can run as plain processes managed by the daemon. Three practical consequences:

• It runs on cheap and awkward hardware. A small VPS where nested containers are unpleasant, an OpenVZ or LXC box, a repurposed machine in an office: MCSManager will work there.
• It runs on Windows. For a hobbyist growing into a business, that is often what is actually available.
• The trade is isolation. Without containers, "this customer's server ate all the RAM" is not automatically somebody else's problem being contained. Whatever isolation and limits you want, you arrange yourself with cgroups, separate users, separate machines, or by turning Docker on after all.

That last point is the one to think about before your tenth customer rather than after. Running unisolated processes for people who have paid you is fine at three servers and a bad idea at three hundred. The panel will let you do either.

Authentication and multi-user

MCSManager has multiple users and API keys: a key is generated per user and is what authenticates programmatic access, and the daemon has its own key as the sole means of authenticating a panel to it.

Worth being clear about what that model is for: MCSManager users are people who operate servers. They are not customers with subscriptions. There is no plan attached to a user, no expiry, no price, no invoice, and nothing that says a user has stopped paying. If you give every customer a panel login, you have given them an operator account on your infrastructure and you are tracking who owes you money somewhere else entirely.

That is not a flaw. It is the same in every game panel, including the ones people spend money on. It is simply the line where the panel stops and your business begins.

What selling actually requires

The panel gives you the machine half: create a server, start it, stop it, restart it, get to a console, delete it. The commercial half is entirely yours to build or buy:

• An order form and a catalogue, with plans that mean something in RAM, slots or storage.
• A payment that provisions within seconds. In game hosting this is not a nicety. The customer is usually sitting with friends waiting to join, and a provisioning delay measured in minutes is how you lose them.
• A dunning path: overdue, warned, suspended, restored. Suspension matters more here than in web hosting, because a game server left running is consuming RAM continuously for someone who has stopped paying.
• Capacity you can see, so you know what you are carrying across all those daemons before the hosting bill tells you.
• An audit trail, so "who deleted that world" has an answer. In Minecraft hosting specifically, that question gets asked, and the answer needs to be better than a shrug.
• A permission model for your staff, so a support volunteer can restart a server without being able to delete one.

Most small Minecraft hosts run this half on a spreadsheet, a payment link and a lot of goodwill. That works until it does not, and the failure is rarely dramatic: a slow accumulation of servers nobody is paying for, refunds you cannot reconstruct, and an evening a month spent reconciling by hand.

One practical note on the project itself

MCSManager originates in the Chinese-speaking community and that is still where its centre of gravity is. The panel is properly internationalised and English documentation exists, but when you go looking for a deep answer (an edge case in the daemon protocol, an unusual deployment), the richest material and the fastest community answers are often in Chinese. Machine translation handles it fine. It is worth knowing before you need support at midnight rather than discovering it then.

Where Provibr fits

MCSManager support is live. An agent inside your own network talks to the web panel over http or https, so neither the panel nor the daemons behind it has to face the internet. Creating, starting, stopping, restarting, suspending and removing instances all work, and what is already on the panel can be imported. Around that sits the layer described above: plans and capacity at a per-unit price, a permission model for your team, a full activity trail, and a REST API and WHMCS module so whatever you already bill with can drive it.

MCSManager already spreads one install over several daemons, so growing means adding a host rather than a second panel. Provibr reads that list and places a new server on free memory, and where there is more than one daemon and no default set it refuses rather than guesses. Suspending is the real thing here: MCSManager holds an expired instance down itself, so a customer with panel access cannot start it again.

What the integration cannot do is wish away the gaps in the panel. There is no console, because MCSManager's runs over socket.io, and there are no usage graphs, because the panel does not measure them. There is no reinstall either: MCSManager only rebuilds from a preset, and Provibr builds from a start command. Without Docker the panel enforces no limits at all, and the integration says so rather than pretending otherwise.

What it will not do

Managing servers is not managing the panel. Installing MCSManager, updating it, adding daemons, choosing whether to use Docker and looking after the machines underneath stays with you. Worlds, plugins, mods and backups stay in the panel, where you and your customers keep using them.

Game hosting rarely stays only game hosting. Provibr runs its control panels, hypervisors and game panels side by side today. They share one inventory, one permission model and one activity trail. Minecraft servers on one panel, the VPS a customer graduates to on another, and one place where you can see both.