Pelican Panel

Last reviewed Sep 13, 2026 · 770 words

Pelican is Pterodactyl with the install pain removed. Former Pterodactyl contributors forked it in 2024, kept the architecture that has run hundreds of thousands of game servers, and fixed the things that made a first deployment take an afternoon: a web installer replaces hand-editing .env, SQLite is a supported database so a single-node homelab does not need MySQL, and the admin UI was rebuilt on a modern PHP admin framework. It is 2,310 stars, MIT-licensed, and 2 years old, which means it also has fewer eggs tested against it, a smaller forum to search when something breaks, and a release cadence that still occasionally changes behaviour between versions.

Panel plus Wings, same as before

The shape has not changed. The Panel is a Laravel application that holds users, servers, allocations, and the egg definitions that describe how to run each game. Wings is a Go daemon installed on every node that actually runs the game servers as Docker containers, streams consoles over WebSocket, handles SFTP on port 2022, and talks back to the Panel over its API on port 8080. One Panel can manage many Wings nodes, so the same install scales from one Minecraft server on a NUC to a rack of nodes.

Isolation is the reason to run any of this rather than a bare screen session: each game server is a container with its own CPU and memory limits, its own filesystem, and a non-root user, so a misbehaving Rust server cannot take the box down and a player with SFTP access cannot see another server's files.

Installing it is finally short

The Panel needs PHP 8.2 or newer with the usual extensions, a web server, and a database. The quickest route on a fresh Debian or Ubuntu VM is the documented package install followed by the web installer at https://panel.example.com/installer, which walks through the database choice, the first admin user, and the queue worker. Pick SQLite for a single node with a handful of servers; pick MariaDB or PostgreSQL when you expect multiple nodes or more than a couple of dozen servers. A Docker Compose file is also published if you would rather run the Panel itself in a container.

Wings is a single binary plus a config.yml that the Panel generates for you after you create the node. Docker must be installed on every Wings host. Plan 1 GB of RAM for the Panel and Wings combined before you add a single game server, and then whatever each game needs: 2 to 4 GB for a modded Minecraft server, 6 GB or more for Rust or ARK.

Eggs are the compatibility question

Eggs are JSON definitions of a game: which Docker image, which install script, which startup command, which variables to expose. Pelican imports Pterodactyl eggs, and the large community collection built for Pterodactyl mostly works, but "mostly" is doing some work in that sentence. The variable format changed slightly, some eggs rely on Pterodactyl-specific paths, and a few need edits before they install cleanly. Minecraft, Terraria, Valheim, Satisfactory, and the Source engine games are well covered; obscure titles may need you to open the egg and fix a line.

The Panel's own admin area is much nicer than Pterodactyl's for editing eggs and nodes, and there is an OAuth login option (Discord, Google, and others) that used to require third-party patches.

Pterodactyl and Crafty are the other two answers

Pterodactyl is still the safer pick if you are hosting for paying customers, because the billing integrations and the years of community answers exist for it and not yet for the fork. Its development has slowed, which is why the fork happened, but slow is not dead. Crafty Controller is the right choice if the only game you will ever run is Minecraft: it is a single Python service with no Wings daemon, backups and scheduling built in, and 5 minutes to a running server. Pelican sits between them, and the wider games category has the rest.

What I'd do

For a new homelab game panel in 2026, install Pelican with SQLite, one Wings node on the same VM, and start with a Minecraft egg from the community collection to confirm the pipeline works end to end. Take a snapshot of the VM before every Panel upgrade while the project is young. If you are running a commercial host or already have a working Pterodactyl with 20 servers on it, stay put for now and revisit the fork in a year.