Documentation

WISP

Connect a WISP panel and Provibr builds, runs and removes game servers on it. WISP is a fork of Pterodactyl, so the model is the same one; this page covers the places where it differs.

A hosted panel, your own node

WISP is sold as a hosted service: wisp.gg runs the panel, and the node that carries your game servers runs on your own hardware. The agent talks to the panel over its API and to the node’s daemon for the console. Both connections are outbound, so nothing has to be opened to the internet.

Because the panel is not yours, there is nothing to upgrade and nothing to pin: WISP can change its API without a release you control. Provibr is tested against v3.7.5 and reads the running version from the panel itself, so drift shows up in the connection test rather than in a failed order.

Two API keys

WISP keeps Pterodactyl’s split between two API surfaces, and no single key covers both. Create them on an administrator account and paste both, along with the panel address.

Address of the panel: the full URL, for example https://panel.example.com. Add a port only if the panel really runs on one; a panel behind a reverse proxy answers on the default port of its scheme.
Application API key: used to build, suspend, reinstall and remove servers.
Client API key: used for power, live statistics and the console.
TLS fingerprint (optional): leave it empty on a hosted WISP panel; its certificate comes from a public authority and there is nothing to pin.

WISP keys carry no prefix, unlike Pterodactyl’s ptla_ and Pelican’s papp_. Nothing can tell you that you swapped the two: Provibr cannot check it, and the panel answers a wrong key with an empty 403 that reads as “not enough permissions”. If the connection test fails, try the two keys the other way round before changing anything in the panel.

The application key is more than server management: the same node listing that Provibr reads also exposes your node’s licence key and daemon token. Treat it as a credential for the whole panel, and revoke it in WISP if you ever disconnect the integration.

Transport

A hosted WISP panel is reachable over https with a publicly trusted certificate, so the fingerprint field stays empty. Fill it in only when you run WISP yourself behind a self-signed certificate; the agent then trusts that one certificate instead of turning verification off. Read it with:

shell

openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Commands and terminal output are in English everywhere, in the panel and in these pages. One text, one truth: what you read here is literally what your host will print back.

Leave the field empty for a certificate from a public authority, and also when the panel is reachable over http only. A fingerprint next to an http address is refused, because there is no certificate to pin. A panel on plain http does work, but both keys then travel unencrypted.

Eggs

A server is built from an egg, exactly as on Pterodactyl. WISP lists all of its eggs with their variables in one call, so the picker fills itself and a plan can override any variable the egg marks as editable.

Leave a required variable empty and WISP does not refuse the order: it quietly fills in the egg’s own default. You get a working server, just not the one you ordered. Provibr checks required variables before sending, so the order stops with a message naming the variable instead.

Plans

A game plan carries the egg, the resource limits and any variable overrides. Ordering is plan-driven: the plan decides which egg is used and what the server may consume, and one plan can be linked to more than one panel.

Placement

A WISP node reports its cores, memory and disk, but not how much of that is already handed out. Provibr adds that up from the servers on the node, which is the same thing it does for a hypervisor.

The node itself is chosen by the agent rather than by the placement engine: it picks the node with the most free memory and the first free port allocation on it. Ranking a WISP panel’s nodes from Provibr is not built yet.

Lifecycle

Create, start, stop, restart, kill, suspend, unsuspend, reinstall and delete all work. A suspended server can still be removed, and removing one frees its port allocation again.

WISP does not report a failed installation. A server is either marked installed or it is not, and “still working on it” and “it went wrong” look identical from the outside. If a new server stays uninstalled for much longer than an egg normally takes, open its console in WISP and read the install output there.

Console and metrics

The console is a live terminal on the node’s daemon, in the same panel as the rest of your infrastructure, and the usage graphs come from the panel’s own measurements. CPU, memory, disk and network are read every polling round; WISP does not report uptime, so a container that restarts between two rounds is not always recognised as a restart.

What Provibr does not do

Provibr does not manage the panel, its nodes, files, backups, databases or users. WISP’s own extras are not part of the integration either: the splitter, subdomains, wipe schedules, mod stores. A game server on the panel is what Provibr provisions, counts and prices; servers you did not create through Provibr are left alone.

PreviousMCSManager NextServers and plans