Blog ·
Pterodactyl vs Pelican: which game panel should you build on?
Pterodactyl or Pelican? Contributor counts, release cadence and nine measured API differences, with the figures taken on 21 August 2026.
By Provibr
If you sell game hosting, this is the decision that shapes the next few years of your business. Pterodactyl has been the default since 2015. Pelican is a fork, started in March 2024 by people who had worked on Pterodactyl, and it has pulled a large part of that community along with it.
We have no stake in the outcome. Provibr supports both panels live, and a customer running Pterodactyl and a customer running Pelican pay us exactly the same. That is why we can write this: cPanel does not publish an honest comparison with DirectAdmin, and Pterodactyl does not publish one with Pelican. We built both integrations, against both APIs, and hit both sets of edges.
The number that actually tells the story
These figures come from the GitHub API and were measured on 21 August 2026. They will not be accurate a year from now, which is exactly why the date is here.
| Pterodactyl | Pelican | |
|---|---|---|
| Public since | 2015 | March 2024 |
| Stars | 9,163 | 2,256 |
| Forks | 2,657 | 310 |
| Contributors | 191 | 226 |
| Latest release | v1.15.1 (14 Aug 2026) | 1.0.0-beta series |
| Project's own label | stable | beta |
Stars and forks measure how many people found a project. Contributors measure how many people are still working on it. Pelican has gathered more contributors in roughly two and a half years than Pterodactyl did in ten. That is the whole story in one row, and it is why the question is being asked at all.
The counterweight is in the last row and it is not a small one. Pelican still ships as 1.0.0-beta, its own maintainers say so, and its API changes between beta releases. Provibr is tested against 1.0.0 and pins nothing else, because the panel offers no way to ask which version it is running, so an upgrade that changes an answer surfaces as an error rather than as a warning beforehand.
What the two have in common
Pelican is a fork, so the shape is the same. A server is built from an egg: a Docker image, a start command and a set of variables the egg defines itself. A node running the Wings daemon carries the container. An allocation gives the server its address and port. Both panels split their API in two: a management half that creates and deletes servers, and a client half that carries power commands, live usage and the console.
That shared shape is why a migration between them is realistic at all. It is also the trap: the same shape does not mean the same answers.
Where they diverge, measured against both panels
This is the part no marketing page will give you. Each row below is something we ran into while building and shipping the two integrations.
| Subject | Pterodactyl 1.x | Pelican 1.0.0-beta |
|---|---|---|
| Grouping of eggs | Eggs live in nests | Nests removed entirely |
| Fetching one egg | No GET /api/application/eggs/{id}; you walk the nests until you find it | Eggs are addressable directly |
| Egg variable rules | Laravel rule strings (required|regex:/…/) | Same rules as an array |
| Missing required variable on create | Refused by the panel | Accepted; the container then crashes on first start |
limits.io = 0 | Silently becomes 500 (the panel validates between 10 and 1000) | Accepted as-is; omitting the field returns 422 |
| Node CPU reporting | Memory and disk only | CPU too, as percent of one core (350 means 3.5 cores) |
| Client account identity | /api/client/account returns an id | id removed |
| API key prefixes | ptla_ / ptlc_ | papp_ / pacc_ |
| Version endpoint | None | None |
A few of those deserve a sentence, because they decide how much work a switch really is.
The egg rules format is the sharpest edge. A parser written against Pterodactyl's rule strings does not fail on one variable when pointed at Pelican. It fails on the deserialisation of the entire egg list, because the type changed. Anything that reads eggs has to be rewritten, not adjusted.
The required-variable difference is a support-ticket difference. On Pterodactyl a missing field is refused up front. On Pelican the panel builds the server, and the customer's game crashes the first time it starts. Provibr enforces the requirement on its own side for Pelican for that reason: a field that turns red is a far better answer than a container that dies quietly.
The node CPU field is a real capability gap, in Pelican's favour. A Pterodactyl node tells you how much memory is free; a Pelican node also tells you how much CPU it has and how much is handed out. Placement across nodes can therefore consider cores as well as memory. Worth knowing about that figure: on both panels it is the panel's own bookkeeping, adding up the limits of the servers on a node, including ones still installing, and not a measurement of what is running.
Both key pairs can be swapped without an error you can see. Both panels accept a client key on the management API. The prefix is the only thing that distinguishes them, which is why any tooling worth using checks it on both sides. Pelican adds a wrinkle here: it shows the client key exactly once, and the list afterwards keeps a short identifier which is itself accepted as a key: paste that and you get a plain authentication failure with no hint that you copied the wrong thing.
So which one should you pick?
There is no general winner. There is a winner per situation.
Pick Pterodactyl if you are selling to paying customers today, your contracts mention software stability, or your business cannot absorb a breaking change in a minor release. v1.15.1 shipped on 14 August 2026; the project is not standing still, it is just moving at the pace a ten-year-old codebase with 191 contributors moves at.
Pick Pelican if you are building something new that goes live in 2027, you want placement that understands CPU, or you want to be where the development energy currently is. Accept in exchange that you will read release notes before every upgrade, and that "beta" is the project's own word and not a competitor's.
Stay on Pterodactyl for now if you already run it in production and nothing hurts. A fork being more active is a reason to plan, not a reason to migrate this quarter.
Move to Pelican if you already run it in staging, you have rebuilt whatever reads eggs, and you have a rollback that you have actually tested.
The part people forget: you do not have to choose in one step
The hardest thing about a panel migration is not the software. It is the months in the middle, where old customers sit on the old panel and new customers land on the new one, and you are running two control planes with two logins and two ways of counting what you sold.
That middle is where Provibr sits. Both panels connect to the same Provibr account, both appear in the same server list, and both count towards the same capacity and the same monthly invoice. The agent dials outward from your own network, so neither panel needs an inbound port opened and nothing is installed on either. Servers you did not create through Provibr are left alone until you import them, which is what makes moving an existing panel across a matter of adopting what is already there rather than rebuilding it.
You still have to make the call about which panel you bet on. You just do not have to make it on one weekend.
Read next
- Pterodactyl setup: two keys, eggs, game plans, the console, importing servers.
- Pelican setup: the two API keys, node placement, and what changes between beta releases.
Figures for stars, forks, contributors and releases were measured via the GitHub API on 21 August 2026. Everything described about the two APIs was measured against running panels while building the Provibr integrations for them.
