How to sell game server hosting with Pelican Panel

Pelican runs game servers. It does not take orders, it does not send invoices, and it does not decide that a server should stop because nobody paid for it. That gap, between the panel works and the business runs, is what this page is about.

Pelican is a fork of Pterodactyl and, at the time of writing, still in beta. Provibr connects to it as a live integration and is tested against Pelican 1.0.0.

What Pelican gives you, and what it does not

Pelican is a control panel. It knows three things well:

What Pelican has no concept of: a customer, an invoice, a payment, a subscription that lapses. There is a suspended flag on a server, but nothing in the panel ever sets it for you.

So a game hosting business built on Pelican has three parts, not one:

1. 01The panel: Pelican, running your servers.
2. 02The shop: where a customer picks a plan and pays. WHMCS, Blesta, FOSSBilling, your own checkout.
3. 03The bridge: the thing that turns a paid order into a running server, and an unpaid one into a stopped server.

Most people build the third part by hand and regret it. It is where the edge cases live: a node that is full, an egg variable that was left empty, a customer who cancels while the installer is still running.

Connecting Pelican: two keys, and one trap

Pelican has two APIs with two different keys, and a provisioning bridge needs both. They come from two different screens, and both must belong to an account with administrator rights.

Give the application key read and write access to Server, Node, Allocation, User and Egg. Anything less and creation fails halfway, which is worse than failing at the start.

Two things about this that cost people an afternoon:

Copy the client key the moment it appears. Pelican shows it once. Afterwards the list keeps only a short identifier, and that identifier is accepted as a key, so pasting it gives you a plain authentication error rather than a hint that you copied the wrong thing. The application key can be read back from the list in full; the client key cannot.

Mind which key goes in which field. Pelican accepts a client key on the management API as well, so swapping the two does not produce an error you can see. The prefix is the only thing that tells them apart. Provibr checks that prefix on both sides for exactly this reason: the alternative is an integration that appears to authenticate and then behaves strangely for a week.

There is no command-line shortcut here: Pelican ships no artisan command for API keys, so both are created through the web interface.

If the panel presents a self-signed certificate, pin its fingerprint rather than turning verification off. A panel reachable over plain http works, but both keys then travel unencrypted across your network, and a fingerprint next to an http address is refused, because there is no certificate to pin.

From eggs to something you can sell

An egg is not a product. It has no price, no name a customer recognises, and no limits attached to it. A plan is the layer that turns one into the other: it holds the egg, the Docker image, the start command and the resource limits a server gets.

Two details that catch people out when they set limits:

• Memory, disk and CPU accept 0 for unlimited.
• The CPU limit counts in percent of one core. 100 is one full core, 200 is two. A plan sold as "2 vCPU" is 200, not 2.
• IO weight runs from 0 to 1000, and 500 is the usual value.

The required-variable rule

An egg defines its own variables, and marks some of them required. Here is a decision worth copying whether or not you use Provibr:

Refuse the order when a required variable is empty, even though Pelican itself would accept it.

Pelican creates the server anyway. The container then crashes on its first start, the customer sees a dead server, and your support queue gets a ticket that reads "it doesn't work". A field that turns red at checkout is a far better answer than a server that exists and doesn't run.

Provibr reads the egg list from your panel, so the order form offers the eggs you actually have instead of asking someone to type a number.

Where a server lands

Pelican reports how much memory and CPU each node has, and how much of it is already handed out. A sensible bridge uses both: a new server goes to a node with room for it, and is refused with a reason when no node has any.

⚠️ The figures the panel reports are bookkeeping, not a measurement. They add up the limits of the servers on a node, including ones that are still installing. A node can therefore look full while very little is actually running.

That matters commercially. If you oversell (and most game hosts do, because a Minecraft server allocated 4 GB rarely uses 4 GB), then Pelican's numbers will stop you long before your hardware does. Plan your node budgets around what you intend to sell, not around what the machine can physically bear.

What the customer actually touches

For a game server, the console is the product. Commands, player joins, and the log line that explains a crash all live there. Pelican has a real console, and Provibr passes it through to the customer over the same outbound connection as everything else: no separate port, no second login, no second password to reset.

Files, backups, databases and schedules stay in Pelican. That is deliberate: those are panel features, and reimplementing them in a second interface gives your customers two places where the truth might live.

Moving an existing panel across

If you already run Pelican with paying customers, you do not have to rebuild anything. Servers created outside the bridge are left alone; you import them so they appear in your dashboard and count towards your capacity.

Importing does not touch the server. It only starts counting it. Until you import it, it is neither managed nor billed, which means you can move a panel across in batches, at your own pace, instead of during a maintenance window.

What this does not cover

Be clear about the boundary before you sell against it:

• Panel administration stays in Pelican. Adding nodes, editing eggs, managing panel users. None of that moves.
• Files, backups, databases and schedules stay in Pelican too.
• Pelican is still in beta and its API changes between releases. The panel offers no way to ask which version it is running, so an upgrade that changes an answer shows up as an error rather than as a warning beforehand. Read the release notes before upgrading a panel your automation talks to. This is not a Provibr limitation. It is a property of the panel, and any bridge you build will have it.

You do not have to pick one panel

Most game hosts end up running more than one panel: Pelican for the new stock, Pterodactyl for what was already there, something else for a customer who insisted. And most of them also sell web hosting or VPS alongside it.

Provibr runs its control panels, hypervisors and game panels side by side in one dashboard. One capacity number, one set of API keys, one place where a server's life is recorded, regardless of which panel it happens to run on.

The next page covers the other half: what happens to a Pelican server when an invoice goes unpaid.