How to sell game server hosting with PufferPanel

PufferPanel is a lightweight, self-hosted game server panel. It installs in minutes, it runs a lot of games, and it is refreshingly free of Pterodactyl's complexity. It is also missing several things a hosting business assumes are there.

This page is about selling on PufferPanel with your eyes open: what automates cleanly, what does not, and where the honest boundary sits. Everything here was measured against PufferPanel 3.0.9.

PufferPanel is not a Pterodactyl fork

Worth stating early, because the assumption costs people days of work. Pelican is a fork of Pterodactyl and shares most of its API shape. PufferPanel is an independent project, and nothing transfers:

• Authentication is OAuth2 client credentials, not an API key.
• Servers are built from community templates by name, not numbered eggs.
• There is no nest/egg hierarchy to walk.
• Server identifiers are self-chosen, eight characters, and you pick them at creation time rather than receiving one.

If you have a Pterodactyl integration and are hoping to point it at PufferPanel with a config change, you are writing a new integration.

Connecting: OAuth2, and a secret you see once

Create an OAuth2 client in the panel under your account. You get a client ID and a client secret; both go into your automation along with the panel URL.

Copy the client secret immediately. PufferPanel shows it once, at creation. A half-copied secret gives you a plain authentication error rather than telling you it is incomplete, a very ordinary hour of your life spent checking the wrong things.

What the client may do follows the account it belongs to. There is no scope picker. If you want it to create and remove servers, it needs to belong to an administrator account. This is a meaningful security note: an OAuth2 client on an admin account is an admin credential, and it should be treated like one.

The port is not guessable

A fresh PufferPanel serves plain HTTP on port 8080. Behind a reverse proxy it will be on 443. There is no port an automation can add on your behalf without guessing, so give it the full URL: http://panel.example.com:8080 or https://panel.example.com.

And be honest with yourself about the transport. A panel on plain http works, but the client secret (an administrator credential) and everything the integration does then travel unencrypted across your network. If the panel is behind TLS with a self-signed certificate, pin its fingerprint rather than disabling verification. A fingerprint next to an http address is refused, because there is nothing to pin.

Templates, not eggs

PufferPanel builds a server from a community template (minecraft, factorio, and so on) rather than from a numbered egg you defined yourself. The template's name is its identity.

Two consequences that shape how you sell:

The full template definition has to be sent inline at creation. PufferPanel does not let you say "make me a server from template X" by reference; the whole definition, with its variables, goes into the request. This is why ordering on PufferPanel is realistically plan-driven only: you need a catalogue that holds the template and its values, because a free-text order form would ask a customer to supply a document.

Community templates default to a host environment. That environment needs binaries a fresh panel host does not have: Java, a game's dependencies, whatever the template assumes. Left alone, the server fails to build with a missing-binary error that reads like a bug in your platform. The fix is to switch to the template's docker variant, which carries them in its image. Provibr does this automatically; if you build your own bridge, do it yourself, because the failure mode is a support ticket every single time.

Placement across nodes, and why it is blunt

PufferPanel exposes its nodes. It does not expose their memory, disk or CPU.

That is not a small thing. A placement engine has nothing to rank on: it cannot ask which node has room, because the panel does not answer that question. Provibr still reports the node, since a game panel with no node at all cannot be ordered against, but it reports unknown capacity, and a multi-node panel is picked by name order rather than by free space.

Practically: if you run more than one PufferPanel node, you are the capacity planner. Nothing in the chain will stop you overfilling a node, because nothing in the chain can see it filling up.

Lifecycle: what works

Create, start, stop, restart, kill, reinstall and delete all work.

One measured detail: delete stops the server first, because the daemon refuses to remove a running container. A delete issued against a running server returns a 500 if you skip that step, which is exactly the shape of bug that surfaces the first time a customer cancels a busy Minecraft server on a Friday evening.

Three things PufferPanel does not have

This is the section to read before you commit to PufferPanel as your selling platform.

No suspend

PufferPanel has no suspend of its own. No column, no endpoint; server status knows only running and installing.

So when a platform "suspends" a PufferPanel game server for non-payment, what actually happens is: the container is stopped, and access to it is blocked in the platform's panel. That is a real and useful thing, but it is not enforced by PufferPanel itself, which means anyone with direct access to the PufferPanel installation can start the server again.

If your customers have no access to the underlying panel, this is fine. If they do, your dunning has a hole in it, and no amount of automation closes it. This is a property of the panel, not of any tool you put in front of it. Compare Pelican, which has a real suspend flag.

No live console

PufferPanel has a console, but it is poll-based: GET /console returns base64 logs with an epoch cursor, and POST /console sends a command. A spec-conforming WebSocket handshake against /console returns 200 JSON instead of 101, tried with both a bearer token and a session cookie.

Provibr's console relay is a tunnel (it carries Wings NDJSON WebSockets and VNC), and a poll model does not fit it without building a second relay form. So the console is off for PufferPanel, deliberately, rather than shipping a console button that leads to a tab which falls back to the overview.

For a game server, the console is arguably the product. Sell accordingly: your customers get it in PufferPanel itself, not in your dashboard.

Almost no usage figures

PufferPanel's stats endpoint reports CPU percentage and memory in bytes. No disk, no network, no uptime.

The standard graph set for a game server is CPU, memory, disk and network. Two of those four would be permanently empty. A graph pinned at zero forever is worse than no graph, so usage graphs are off for PufferPanel too.

So when is PufferPanel the right choice?

It is a genuinely good panel, and the boundaries above are not disqualifying; they are just specific. PufferPanel suits you if:

• Your customers do not get direct access to the panel host, so the missing suspend enforcement is irrelevant.
• You sell fixed plans rather than metered resources.
• You run one node, or you are comfortable being your own capacity planner.
• You value a small, quick, low-dependency panel over feature depth.

It suits you less well if you sell to a technical audience with panel access, or if per-server usage graphs are part of what you charge for.

You do not have to pick one panel

The realistic answer for most game hosts is both. PufferPanel for the lightweight tier, Pelican or Pterodactyl where the console and enforcement matter, and probably web hosting or VPS alongside it all.

Provibr runs its control panels, hypervisors and game panels side by side in one dashboard. They share one API and one capacity number. Where a provider cannot do something, the platform refuses with a reason that names the missing capability rather than pretending otherwise.

The next page covers the order-to-server and unpaid-invoice paths in detail: PufferPanel billing automation.