Pelican Panel: a Laravel and Docker control panel for game servers

The gap Pelican Panel fills between a raw Docker host and a game community

Running a handful of game servers on a single machine is not hard. Running twenty of them for other people is. Each title wants its own runtime, its own ports, its own save files, and its own restart schedule, and the moment more than one person has access you need accounts, permissions and a way to stop one tenant from reading another tenant's world data. Pelican Panel exists to put a web interface over that arrangement. The README describes it as a panel that "gives users a modern web UI for creating and managing game servers while running each server in an isolated Docker container through Wings." The intended audience is stated plainly: communities, hosts, and self-hosters. That is three quite different groups. A person running one Minecraft server for friends cares about install time. A hosting provider cares about per-customer isolation and resource limits. The README does not separate those use cases, so the same feature list has to serve all of them, and the eggs catalogue is what makes that plausible.

Wings, eggs and the split between the panel and the machines that run the games

The architecture is two-part. The panel itself is a Laravel application, and the repository topics list FilamentPHP, which is the admin framework the interface is built on. The panel does not start game processes. That job belongs to Wings, a separate daemon linked from the README at github.com/pelican/wings. The panel talks to Wings, Wings talks to Docker, and each game server becomes a container. The second piece of vocabulary is the egg. An egg is the packaged definition of how a particular game or service is installed and launched, and the README organises them into categories: Minecraft, SteamCMD, standalone games, Discord bots, voice servers, software, programming runtimes, databases, storage and monitoring. The practical consequence is that the panel's usefulness tracks the egg repositories rather than the panel code. If your game is in the SteamCMD list, which the README shows as including ARK: Survival, Palworld, Project Zomboid, Satisfactory and DayZ, someone has already worked out the container. If it is not, you are writing an egg yourself. The README's claim that this avoids "bloating machines with a host of additional dependencies" is accurate in the sense that dependencies live inside containers, but the host still needs Docker and Wings.

Installation: what the README does and does not give you

This is the weakest part of the supplied material, and it matters. The README contains no install commands. It points to pelican.dev/docs for documentation and to the Wings repository for the daemon, and that is the whole of the guidance. There is no docker-compose file quoted, no artisan command, no environment variable listed, no database migration step described. Anyone evaluating Pelican Panel has to treat the documentation site as the real source of truth and this README as an entry point. The one concrete signal in the release data is the version string: v1.0.0-beta38, published 2026-08-16, following beta37 on 2026-08-13 and beta36 on 2026-08-05. Three beta releases inside two weeks is a fast cadence, which usually means you should expect to upgrade often and to read release notes before doing so. It also means any installation instructions you find in a blog post or a forum thread may already be out of date relative to the current beta. Verify against the docs, not against third-party write-ups.

The beta tag is a real constraint, not a formality

Pelican Panel has not cut a stable 1.0. Every release in the provided list carries a beta suffix. For a self-hoster running one server for friends, that is a manageable risk: you upgrade, something breaks, you roll back, nobody's evening is ruined. For a hosting provider selling slots to paying customers, the calculus changes. Beta software can change configuration keys, database schema or API behaviour between releases, and the README gives no compatibility promise and no long-term support statement. There is also no migration guide in the supplied material, so a beta37 to beta38 upgrade path cannot be confirmed from what is here. A second limitation is scope. The README lists databases, Redis, Grafana, Prometheus and Loki among the supported eggs, which suggests Pelican can be used as a general container control panel. That is true only insofar as someone maintains an egg for the service. The panel is not a Kubernetes replacement and the README makes no claim that it is. Treat the non-game eggs as convenience, not as a platform.

Pterodactyl is the comparison that matters, and the README invites it

Pelican positions itself inside the Pterodactyl ecosystem rather than against it. The README's first bullet under "Why Pelican?" is "A modern alternative in the Pterodactyl ecosystem", and the repository topics include pterodactyl. The shared vocabulary gives away the lineage: Wings is the daemon name in both, eggs are the packaging format in both, and the panel-plus-daemon split is the same shape. The difference the README actually states is the interface layer, a Laravel application using FilamentPHP, and the surrounding egg organisation into separate GitHub organisations per category (pelican-eggs/minecraft, pelican-eggs/steamcmd, pelican-eggs/voice and so on). Whether that is enough to justify moving an existing Pterodactyl deployment is not something the supplied material answers. There is no migration tool mentioned, no import path from an existing Pterodactyl database, and no compatibility statement about existing eggs. If you are already running Pterodactyl with a working egg set, the honest reading is that Pelican offers a different UI and a differently organised egg registry, and you would be testing the migration yourself.

Licence and the cost of keeping a panel current

Pelican Panel is AGPL-3.0. That is a copyleft licence with a network clause: if you modify the panel and let users interact with it over a network, the licence's terms about offering the source to those users come into play. For a community running an unmodified panel, this is unlikely to change anything in practice. For a hosting company that forks the panel and sells access, it is worth reading the licence text and, if the business depends on it, taking proper advice rather than relying on a summary. The maintenance cost is the other side of the beta cadence. With releases landing every few days, a self-hoster who wants fixes has to upgrade fairly often, and each upgrade is a chance to break a running deployment. The README offers no upgrade tooling, no backup guidance and no rollback procedure, so the operational burden sits entirely with the operator. Budget for that before you migrate anything you care about.

Who should install it, and what to check before you do

Pelican Panel fits a self-hoster or small community that already runs Docker, wants per-server isolation without building it by hand, and is comfortable reading documentation rather than following a wizard. It fits less well if you need a frozen release you can pin for a year, or if your game has no egg and you have no appetite for writing one. Before installing, work through three checks in order. Open pelican.dev/docs and read the installation section completely, because the README will not get you running. Confirm the Wings daemon's own requirements from github.com/pelican/wings, since that is the component touching Docker and the host kernel. Then look at the egg repository for your specific game, for example pelican-eggs/steamcmd or pelican-eggs/minecraft, and check whether the egg is actively maintained. If all three hold up, the beta label is a scheduling question rather than a blocker. If any of them does not, wait for the stable release.

Editorial conclusion

Adopt Pelican Panel if you already run Docker on your own hardware and are comfortable reading pelican.dev/docs and the Wings repository rather than expecting a guided installer; the egg catalogue covering Minecraft, SteamCMD titles, databases and voice servers is the main draw. Do not adopt it if you need a stable, versioned release line or a hosted alternative, because the newest releases are still tagged v1.0.0-beta38. Before committing, read the installation section of the documentation end to end, confirm your host meets whatever kernel and Docker version it specifies, and check the licence terms for any commercial hosting use.

Official sources

1. License: AGPL-3.0
2. pelican/panel on GitHub
3. Project website
4. README
5. Releases