// the find
pterodactyl/panel
Pterodactyl® is a free, open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to end users.
Pterodactyl is a game server hosting panel that wraps game servers in Docker containers and provides a web UI for managing them. It consists of this PHP/Laravel panel repo plus a separate Go daemon (Wings) that runs on each host node. Primarily used by game hosting providers and communities who want a self-hosted alternative to proprietary panels.
- Clean separation between the panel and the Wings daemon via a well-defined remote API, which means the PHP app never directly touches Docker—it delegates everything to the Go daemon over authenticated requests.
- Permission model is reasonably granular: subusers get per-server permission scopes, API keys have explicit permission sets, and there's 2FA support with TOTP. The middleware stack in app/Http/Middleware shows real thought put into auth layers.
- The 'Egg' system for defining game server configs is a clever abstraction—JSON-based configs that define startup commands, environment variables, and install scripts, plus an import/export system. This is what makes the community ecosystem (pterodactyleggs.com) viable.
- Active maintenance with CI, PHPCSFixer, ESLint, and TypeScript on the frontend—the project isn't running on vibes alone.
- The admin panel is still Blade-based while the client area is React/TypeScript—you're maintaining two completely different frontend paradigms in the same codebase, which makes contributing to admin features a different experience than contributing to the client.
- Installation is genuinely painful for beginners: requires configuring nginx/Apache manually, running artisan commands, setting up cron, configuring queues, and then separately installing Wings on each node. No docker-compose-based single-command setup for the whole stack in the official docs.
- The repo hasn't had a stable release since v1.11 in 2022 (based on last tags), but development continues on 1.0-develop. The gap between what's in develop and what's in a stable release creates real friction for anyone trying to deploy or contribute.
- The repository pattern is heavily used with explicit interfaces for every model (see app/Contracts/Repository), but in practice Eloquent is used directly in many services anyway—the abstraction adds boilerplate without consistently delivering testability benefits.