Pelican started as a fork of Pterodactyl. Both run game servers in Docker containers and control them through the Wings daemon on each node, but they part ways on points that matter more to a hosting company than the look of the panel.
Pterodactyl and Pelican side by side
| Point | Pterodactyl | Pelican |
|---|---|---|
| Licence | MIT | AGPL-3.0 |
| Releases | stable 1.x line, 1.12.0 to 1.15.1 during 2026 | heading for 1.0 through a series of betas |
| Panel database | MySQL or MariaDB, plus Redis | SQLite by default, or MySQL, MariaDB and PostgreSQL |
| Panel interface | Laravel with a React front end | Laravel and Filament, with roles for admins |
The licence decides what happens to your changes
MIT lets you modify Pterodactyl without publishing your changes. AGPL-3.0 requires a modified version that people use over a network to offer them its source code. A host that patches Pelican's core therefore has to make that code available to its customers.
Moving over from Pterodactyl
Pelican upgrades a Pterodactyl database in place: users, servers, nodes, eggs and API keys carry over, and game servers keep running on their files. Themes and panel modifications do not carry over. In Pelican those belong in plugins, which add features without touching core files. Our fix for plugin updates was merged into Pelican (#2598), so we know that mechanism from the inside.
If you want to sell servers in the same panel where customers manage them, there is a third route: Flaem combines a game panel with a store, a wallet and KSeF invoicing, and takes over running Wings nodes without shutting servers down.
Setting up Pterodactyl, theming it and connecting it to billing is covered on our Pterodactyl integration page.
Was this post helpful?
