Pelican Panel: Docker-Isolated Game Server Management for Self-Hosters

What Pelican Panel Does and Who It Is For

Pelican Panel is a web-based control panel for creating, starting, and managing game servers. Each server runs inside its own Docker container, handled by a separate daemon called Wings. The panel itself is a PHP Laravel application that provides the web interface, user management, and API; Wings runs on the node where the game servers actually execute.

The target audience is split into three groups. Community administrators who run private servers for friends or clans want a self-hosted alternative to managed hosting platforms. Hosting providers want a multi-user system where clients can control their own server instances without shell access. Individual self-hosters want isolation between game processes without hand-writing systemd units for each one.

Pelican is positioned explicitly as a modern alternative within the Pterodactyl ecosystem. The README states it is for those who want a modern alternative in that ecosystem, though it does not specify which APIs or configuration files it shares with Pterodactyl.

Wings, Eggs, and the Two-Component Architecture

Running Pelican requires two separate pieces of software. The panel handles the web interface and is the part this repository ships. Wings is a separate Go-based daemon, hosted at github.com/pelican/wings, that runs on the machine where game servers execute. The panel talks to Wings over an authenticated API connection.

Game server templates in Pelican are called eggs. An egg describes how to install a specific game or server type: which Docker image to use, which environment variables to expose, which startup command to run, and which ports to bind. Eggs live in separate repositories under the pelican-eggs GitHub organization. The categories include Minecraft variants such as Paper, Sponge, and Bungeecord; SteamCMD games such as ARK: Survival Evolved, Counter-Strike, DayZ, Palworld, and Satisfactory; Discord bots; voice servers like Teamspeak and Mumble; and general-purpose software including Gitea, Grafana, and various databases.

The egg design means Pelican itself does not hard-code any game logic. Adding support for a new game type means writing or importing an egg, not modifying the panel code. The tradeoff is that egg quality varies by maintainer, and a broken or outdated egg produces a game server that fails silently at the container startup stage.

Installing Pelican Panel with Docker Compose

The quickest installation path uses the provided compose.yml. At minimum you need to set APP_URL and LE_EMAIL before starting.

The compose.yml exposes ports 80 and 443 by default:

services:
  panel:
    image: ghcr.io/pelican/panel:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      APP_URL: "http://localhost"
      LE_EMAIL: "[email protected]"
      APP_ENV: "production"
      APP_DEBUG: "false"

The panel image is pulled from the GitHub Container Registry at ghcr.io/pelican/panel:latest. A Caddy reverse proxy and PHP-FPM are bundled inside the image; the compose file creates two named volumes, pelican-data and pelican-logs, to persist application data and log output across container restarts.

For deployments behind an existing reverse proxy, the README instructs you to comment out ports 80 and 443, uncomment port 81:80, and set BEHIND_PROXY to true along with TRUSTED_PROXIES matching your proxy's IP addresses.

Wings must be installed separately on each node that will run game servers. The documentation for Wings is at github.com/pelican/wings. The two components must be able to reach each other over the network; the panel does not bundle Wings.

Frontend Build Stack and PHP Backend

The panel frontend uses Vite, Tailwind CSS v4, and xterm.js for in-browser terminal access to game server consoles. The Dockerfile builds frontend assets with Yarn and PHP dependencies with Composer in separate stages, producing a single Alpine-based image with Caddy handling HTTPS termination.

The multi-stage build separates dependency installation from the application build so that layer caching works efficiently during development. Composer handles PHP dependencies; Yarn handles JavaScript dependencies. The package.json lists xterm packages including an addon for WebGL rendering, which means the in-browser console requires a browser with WebGL support.

The project ships a .env.example file with a minimal set of required variables: APP_ENV, APP_DEBUG, APP_KEY, APP_URL, and APP_INSTALLED. APP_KEY must be generated before the first run; the documentation at pelican.dev explains how. The app uses SQLite by default for smaller deployments and supports MySQL or PostgreSQL for multi-node production setups, though the .env.example provided in the repository does not show database connection variables explicitly.

Real Limitations to Check Before Deploying

Pelican is still in beta. The most recent release at the time the repository was last updated is v1.0.0-beta38, published 2026-08-16. The beta label means the API and configuration format can change between releases without a guaranteed migration path.

The two-component architecture creates an operational constraint. Wings must be running and reachable for any game server action to work. A firewall rule that blocks the Wings port, a Wings crash, or a network partition between the panel host and the Wings host makes the game server unmanageable from the web interface even if the game server itself is still running inside Docker.

Egg quality is uneven. The pelican-eggs repositories are community-maintained, and some eggs for less popular games may not have been updated to work with current Docker images or game server versions. Before committing to Pelican for a specific game, locating and testing the egg for that game is a required step.

Plugin support exists but the plugin directory is persisted as a Docker volume subpath. The compose.yml mounts pelican-data at /pelican-data/plugins, which means plugins survive container upgrades as long as the volume is preserved. The README does not document a rollback procedure if a plugin update breaks the panel.

Pelican vs. Pterodactyl: The Fork Relationship

Pterodactyl is the established predecessor in this space. Pelican's README positions it as a modern alternative within the Pterodactyl ecosystem without detailing the precise history. Both projects use Docker containers for isolation and a separate daemon architecture.

The key difference visible in the repository is that Pelican uses a modern frontend stack (Vite, Tailwind v4, xterm.js) and is building toward a plugin system. Pterodactyl has a larger installed base and a longer track record in production. Teams running Pterodactyl who consider migrating to Pelican should verify whether their existing eggs and Wings configurations are compatible, since the README does not document a migration path.

License, Maintenance, and Sponsorship

Pelican Panel is licensed under the AGPL-3.0. That means any service that runs a modified version and provides it to users over a network must publish the source of those modifications. Hosting providers who intend to customize the panel without releasing their changes should read the AGPL requirements before deploying.

The project is built and maintained by volunteers. The README notes that Pelican helps communities and self-hosters, and that ongoing development is supported through sponsorship at hub.pelican.dev/sponsor. The last push to the repository was on 2026-09-27, and the project shows a regular release cadence with multiple beta releases in 2026.

Contributions are accepted through GitHub and coordinated in the project Discord. The contributing.md file in the repository describes the process. Translators, testers, and documentation writers are listed alongside code contributors as welcome participants.

Editorial conclusion

Pelican Panel is a good fit for community hosts and self-hosters who already know Docker and want reproducible, isolated game server environments without paying for proprietary hosting software. It is not a good fit for anyone expecting a stable release: the project is still in beta as of v1.0.0-beta38. Before adopting it, verify that the specific game or server type you need has a maintained egg in the pelican-eggs organization and that your infrastructure meets the two-component requirement of running both the panel and Wings.

Frequently asked questions

Official sources

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