Blog ·
Pterodactyl vs Pelican: op welk gamepaneel bouw je verder?
Pterodactyl of Pelican? Aantal bijdragers, releasetempo en negen gemeten API-verschillen, met de cijfers zoals ze op 21 augustus 2026 stonden.
Door Provibr
Verkoop je gamehosting, dan is dit de keuze die de komende jaren van je bedrijf bepaalt. Pterodactyl is sinds 2015 de standaard. Pelican is een fork, in maart 2024 gestart door mensen die aan Pterodactyl gewerkt hadden, en die heeft een flink deel van de community meegenomen.
Wij hebben geen belang bij de uitkomst. Provibr ondersteunt beide panelen live, en een klant op Pterodactyl betaalt ons precies hetzelfde als een klant op Pelican. Dat is waarom wij dit kunnen schrijven: cPanel publiceert geen eerlijke vergelijking met DirectAdmin, en Pterodactyl publiceert er geen met Pelican. Wij bouwden beide integraties, tegen beide API's, en liepen tegen beide sets randen aan.
Het getal waar het echt om draait
Deze cijfers komen uit de GitHub-API en zijn gemeten op 21 augustus 2026. Over een jaar kloppen ze niet meer, en precies daarom staat die datum erbij.
| Pterodactyl | Pelican | |
|---|---|---|
| Publiek sinds | 2015 | maart 2024 |
| Sterren | 9.163 | 2.256 |
| Forks | 2.657 | 310 |
| Bijdragers | 191 | 226 |
| Laatste release | v1.15.1 (14 aug 2026) | 1.0.0-beta-reeks |
| Eigen label van het project | stabiel | beta |
Sterren en forks meten hoeveel mensen een project gevonden hebben. Bijdragers meten hoeveel mensen er nog aan werken. Pelican heeft in ruim tweeënhalf jaar méér bijdragers verzameld dan Pterodactyl in tien jaar. Dat is het hele verhaal in één regel, en dat is waarom deze vraag überhaupt gesteld wordt.
Het tegenwicht staat in de laatste regel en is niet klein. Pelican draagt nog steeds 1.0.0-beta, de makers zeggen dat zelf, en de API verandert tussen betareleases. Provibr is getest tegen 1.0.0 en pint verder niets vast, want het paneel biedt geen manier om te vragen welke versie het draait. Een upgrade die een antwoord verandert komt dus als fout naar boven en niet als waarschuwing vooraf.
Wat de twee delen
Pelican is een fork, dus de vorm is dezelfde. Een server wordt gebouwd uit een egg: een Docker-image, een startcommando en een set variabelen die het egg zelf definieert. Een node met de Wings-daemon draagt de container. Een allocatie geeft de server zijn adres en poort. Beide panelen splitsen hun API in tweeën: een beheerhelft die servers aanmaakt en verwijdert, en een clienthelft die power-commando's, live verbruik en de console draagt.
Die gedeelde vorm is waarom een migratie tussen de twee überhaupt realistisch is. Het is ook de valkuil: dezelfde vorm betekent niet dezelfde antwoorden.
Waar ze uiteenlopen, gemeten tegen beide panelen
Dit is het deel dat geen enkele marketingpagina je geeft. Elke regel hieronder is iets waar we tegenaan liepen bij het bouwen en uitrollen van de twee integraties.
| Onderwerp | Pterodactyl 1.x | Pelican 1.0.0-beta |
|---|---|---|
| Groepering van eggs | Eggs zitten in nests | Nests helemaal verdwenen |
| Eén egg ophalen | Geen GET /api/application/eggs/{id}: je loopt de nests af tot je hem vindt | Eggs zijn direct adresseerbaar |
| Regels van een egg-variabele | Laravel-regels als string (required|regex:/…/) | Dezelfde regels als array |
| Ontbrekende verplichte variabele bij aanmaken | Door het paneel geweigerd | Geaccepteerd; de container crasht daarna bij de eerste start |
limits.io = 0 | Wordt stil 500 (het paneel valideert tussen 10 en 1000) | Wordt zo geaccepteerd; het veld weglaten geeft 422 |
| CPU-rapportage van een node | Alleen geheugen en schijf | Ook CPU, als percentage van één core (350 betekent 3,5 cores) |
| Identiteit van het clientaccount | /api/client/account geeft een id | id verwijderd |
| Voorvoegsels van de API-sleutels | ptla_ / ptlc_ | papp_ / pacc_ |
| Versie-endpoint | Geen | Geen |
Een paar daarvan verdienen een zin, want ze bepalen hoeveel werk een overstap werkelijk is.
De vorm van de egg-regels is de scherpste rand. Een parser die tegen Pterodactyls regelstrings geschreven is, faalt bij Pelican niet op één variabele; hij faalt op het uitpakken van de héle eggenlijst, want het type is veranderd. Alles wat eggs leest moet herschreven worden, niet bijgesteld.
Het verschil bij verplichte variabelen is een verschil in supporttickets. Op Pterodactyl wordt een ontbrekend veld vooraf geweigerd. Op Pelican bouwt het paneel de server gewoon, en crasht de game van je klant bij de eerste start. Provibr dwingt die verplichting daarom aan zijn eigen kant af voor Pelican: een veld dat rood wordt is een veel beter antwoord dan een container die stil sterft.
Het CPU-veld op een node is een echt verschil in mogelijkheden, in het voordeel van Pelican. Een Pterodactyl-node vertelt hoeveel geheugen vrij is; een Pelican-node vertelt daarnaast hoeveel CPU hij heeft en hoeveel er al is uitgedeeld. Plaatsing over nodes kan dus naast geheugen ook cores meewegen. Wel goed om te weten van dat getal: op beide panelen is het de eigen boekhouding van het paneel (de limieten van de servers op een node bij elkaar opgeteld, inclusief servers die nog installeren) en geen meting van wat er draait.
Beide sleutelparen zijn te verwisselen zonder een zichtbare fout. Beide panelen accepteren een clientsleutel óók op de beheer-API. Het voorvoegsel is het enige wat ze onderscheidt, en daarom controleert elk fatsoenlijk stuk gereedschap dat aan beide kanten. Pelican legt daar nog een laagje op: de clientsleutel is precies één keer te zien, en de lijst bewaart daarna een korte identifier die zélf als sleutel geaccepteerd wordt. Plak die en je krijgt een kale authenticatiefout, zonder enige hint dat je het verkeerde gekopieerd hebt.
Welke moet je dan kiezen?
Er is geen algemene winnaar. Er is een winnaar per situatie.
Kies Pterodactyl als je vandaag aan betalende klanten verkoopt, je contracten iets over softwarestabiliteit zeggen, of je bedrijf geen brekende wijziging in een minor release kan opvangen. v1.15.1 kwam uit op 14 augustus 2026; het project staat niet stil, het beweegt in het tempo van een tien jaar oude codebase met 191 bijdragers.
Kies Pelican als je iets nieuws bouwt dat in 2027 live gaat, je plaatsing wilt die CPU begrijpt, of je wilt zitten waar de ontwikkelenergie nu zit. Neem er dan bij dat je vóór elke upgrade de release notes leest, en dat "beta" het eigen woord van het project is en niet dat van een concurrent.
Blijf voorlopig op Pterodactyl als je het al in productie draait en niets pijn doet. Dat een fork actiever is, is een reden om te plannen, geen reden om dit kwartaal te migreren.
Ga naar Pelican als je het al op een testomgeving draait, alles wat eggs leest opnieuw hebt gebouwd, en een terugweg hebt die je echt uitgeprobeerd hebt.
Wat men vergeet: je hoeft niet in één stap te kiezen
Het lastigste aan een paneelmigratie is niet de software. Het zijn de maanden ertussen, waarin oude klanten op het oude paneel zitten en nieuwe klanten op het nieuwe landen, en jij twee besturingsvlakken draait met twee logins en twee manieren om te tellen wat je verkocht hebt.
Dat middenstuk is waar Provibr zit. Beide panelen koppelen aan hetzelfde Provibr-account, beide staan in dezelfde serverlijst, en beide tellen mee voor dezelfde capaciteit en dezelfde maandfactuur. De agent belt uitgaand vanuit je eigen netwerk, dus geen van beide panelen hoeft een poort open te zetten en er wordt op geen van beide iets geïnstalleerd. Servers die je niet via Provibr hebt aangemaakt blijven met rust tot je ze importeert, en dat is wat een bestaand paneel overzetten tot overnemen maakt in plaats van opnieuw opbouwen.
De keuze op welk paneel je inzet blijft van jou. Je hoeft hem alleen niet in één weekend te maken.
Verder lezen
- Pterodactyl instellen: twee sleutels, eggs, gameplannen, de console en servers importeren.
- Pelican instellen: de twee API-sleutels, plaatsing over nodes, en wat er tussen betareleases verandert.
Sterren, forks, bijdragers en releases zijn op 21 augustus 2026 via de GitHub-API gemeten. Alles wat hier over de twee API's staat, is tegen draaiende panelen gemeten tijdens het bouwen van de Provibr-integraties.
