# Pterodactyl Panel: Docker-Isolated Game Server Management for PHP Stacks

> Pterodactyl Panel is a free, MIT-licensed control panel that runs each game server inside its own Docker container, pairing a Laravel backend with a React frontend and the Go-based Wings daemon. It suits hosts and communities that want per-instance isolation without writing their own orchestration layer.

**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.

- Repository: https://github.com/pterodactyl/panel
- Website: https://pterodactyl.io
- Stars: 9,273 · Forks: 2,696
- Language: PHP
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pterodactyl-panel

## What Pterodactyl Panel Actually Manages

Pterodactyl Panel is the control plane for game servers, not a game server itself. The README describes it as a free, open-source game server management panel built with PHP, React, and Go, and states that it runs all game servers in isolated Docker containers while exposing a UI to end users. That sentence is the whole product thesis: the panel owns users, permissions, server records and the interface, while the actual game processes live in containers on machines the panel talks to.

The audience is narrow and specific. It is for people who operate more than a handful of game servers and are tired of hand-managing systemd units, ports and per-game dependencies on shared hardware. The README's own framing is aimed at platforms: "Make game servers a first class citizen on your platform." A single person running one Minecraft instance on a spare box gets almost nothing from the panel's user model, allocation tracking or API. A host renting capacity to strangers gets a great deal.

The supported list in the README covers Minecraft (including Paper, Sponge, Bungeecord and Waterfall), Rust, Terraria, Teamspeak, Mumble, Team Fortress 2, Counter Strike: Global Offensive, Garry's Mod and ARK: Survival Evolved. Community-provided eggs extend that to Factorio, San Andreas: MP, Pocketmine MP, Squad, Xonotic, Starmade and Node.js or Python Discord bots. That split matters: the core list is maintained by the project, the rest is community output with no implied support.

## How the Panel, the Database and the Daemon Split Work

The repository layout makes the architecture legible. app/, bootstrap/, config/, database/ and routes/ are standard Laravel directories, so the panel is a PHP application with an HTTP surface, a queue, and Eloquent models behind it. resources/ holds the React frontend, which package.json confirms: React 16, react-router-dom 5, easy-peasy for state, Tailwind for styling, xterm for a browser terminal, and sockette for WebSocket connections. The Go component is not in this repository at all. The README links to separate Wings documentation at pterodactyl.io/wings/1.0/installing.html, which means the daemon that actually starts containers is a distinct deployment you install on each node.

That split is the design decision worth understanding. The panel never touches Docker directly. It records intent (this server should exist, this user may start it) and Wings executes it on the node. The practical consequence is that the panel can be hosted somewhere completely separate from the machines running games, and a panel outage does not necessarily kill running servers. The cost is a second install path, a second set of credentials, and a node-to-panel connection you must configure before anything works.

The .env.example shows the dependencies the panel expects: DB_CONNECTION=mysql with DB_HOST=127.0.0.1 and DB_PORT=3306, Redis at REDIS_HOST=127.0.0.1 and REDIS_PORT=6379, and QUEUE_CONNECTION=redis. Note that CACHE_DRIVER and SESSION_DRIVER default to file while the queue defaults to Redis. If you follow the example literally you end up with a mixed setup, which is fine but worth knowing before you debug why a worker is not picking up jobs.

## Installing Pterodactyl Panel and Starting a First Server

The README does not contain install commands. It points to the panel documentation at pterodactyl.io/panel/1.0/getting_started.html and the Wings documentation at pterodactyl.io/wings/1.0/installing.html, and those pages are where the actual steps live. What the repository does give you is the configuration surface and a container build, and that is enough to describe the shape of a deployment without guessing at commands the project never published.

Start from the environment file. The repository ships .env.example, and the Dockerfile copies it into place during the image build with cp .env.example .env before running composer install. The keys below are the ones you must supply values for; APP_KEY is empty in the example and HASHIDS_SALT is empty too.

```bash
APP_ENV=production
APP_DEBUG=false
APP_KEY=
APP_URL=http://panel.example.com
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=panel
DB_USERNAME=pterodactyl
DB_PASSWORD=
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
QUEUE_CONNECTION=redis
```

If you would rather build the image than assemble PHP, nginx, cron and certbot by hand, the repository includes a Dockerfile and a docker-compose.example.yml. The Dockerfile is a two-stage build: stage 0 uses node:22-alpine and runs yarn install --frozen-lockfile followed by yarn run build:production, then stage 1 uses php:8.3-fpm-alpine, copies the compiled assets from stage 0, installs the PHP extensions bcmath, gd, pdo_mysql and zip, and runs composer install --no-dev --optimize-autoloader.

```bash
docker compose -f docker-compose.example.yml up -d
```

The Dockerfile also writes two cron entries into the container: a per-minute php /app/artisan schedule:run and a nightly certbot renew --nginx --quiet. That per-minute scheduler is not optional decoration. Laravel's scheduler is how the panel runs recurring work, so a deployment that skips cron will appear healthy and then quietly stop doing scheduled tasks.

For local frontend work, package.json sets engines.node to ">=22", so the build toolchain expects Node 22 or newer. The repository also carries flake.nix and shell.nix, which is a hint that the maintainers develop against a Nix-defined environment, though nothing in the README tells you to use it.

Once the panel and at least one Wings node are running, the first real use is administrative: create a user, create a node, attach an allocation, then create a server against an egg. The panel's job is to write those records; Wings is what turns the record into a running container. If you create a server and nothing starts, the fault is almost always on the Wings side of that boundary, not in the Laravel application.

## Where Pterodactyl Panel Gets in Your Way

The separation between panel and daemon is the biggest operational cost. You are not installing one thing. You are installing a Laravel application with MySQL and Redis, then installing Wings on every machine that will run games, then wiring the two together. The README treats this as two documentation tracks, and it is honest about that, but it means the failure surface is roughly double what a single-binary control panel would have.

The Docker isolation that the README leads with is also a constraint. Every game server runs in a container, which is what makes dependency management tractable, but it also means anything that cannot be expressed as a container image and a startup command is awkward. Games with unusual host integration, hardware access requirements, or licensing schemes that assume a bare-metal install will fight the model.

The licence situation deserves a direct note. The README's final section says code is released under the MIT License and links to LICENSE.md, but the repository metadata reports the licence as NOASSERTION. Those two statements do not agree, and the metadata is what automated tooling reads. If your organisation has a policy gate that consumes licence identifiers, it will not see MIT here. Read LICENSE.md yourself and decide; this is a factual discrepancy in the project's own materials, not a legal opinion.

Finally, the default branch is 1.0-develop. That is a development branch, not a stable release branch, and anyone cloning the default will get code that is ahead of the tagged releases. The presence of v1.15.1, v1.15.0 and v1.14.1 as recent tags suggests the release process is active, but the branch naming means "clone and run" is not the same as "install the latest release."

## Pterodactyl Panel Versus a Plain Docker Compose Stack

The obvious alternative is doing it yourself: one docker-compose file per game, a reverse proxy, and a spreadsheet of ports. That approach has real advantages. There is no PHP application to patch, no MySQL schema to migrate, no queue worker to supervise, and no second daemon to install. For three servers run by the same person who built them, hand-rolled Compose is less work than Pterodactyl Panel and will stay less work.

The difference is what happens when the number of servers grows or when other people need access. A Compose stack has no concept of a user who may restart server A but not server B, no allocation registry that prevents two servers from claiming the same port, and no API that a billing system can call. Pterodactyl Panel's Laravel application exists precisely to hold those records, and the React frontend exists to expose them to people who will never open a terminal. The panel is heavier because it is doing multi-tenancy, and multi-tenancy is the thing a Compose stack does not do at all.

A second alternative is a managed or SaaS game panel. The README's sponsor list includes companies in that space, including WISP, which the README describes as a SaaS platform for game server management. The trade is control for operational burden: you stop running MySQL, Redis, nginx, cron and Wings, and you accept someone else's uptime and pricing. For a hobby community, that trade is often correct. For a host whose product is the panel experience, it is not.

## Upgrade Cost, Maintenance Signals and Licence Caveats

The last push to the repository was on 2026-08-14, and v1.15.1 was tagged the same day, with v1.15.0 on 2026-08-03 and v1.14.1 on 2026-06-29. The repository is not archived. That release cadence suggests a project that is still being worked on, and the version numbering suggests patch releases arrive between minor ones.

Upgrading a Laravel application of this size is not a file copy. The Dockerfile runs composer install --no-dev --optimize-autoloader and yarn run build:production, which means an upgrade involves PHP dependency resolution and a frontend rebuild, not just pulling a new image tag. The CHANGELOG.md at the repository root is where release notes live; the README does not document a rollback procedure, and neither does it describe a supported downgrade path. Plan for database backups before any version jump, because the database/ directory holds migrations and migrations are one-directional by convention.

The stack pins are worth reading before you commit to an upgrade cadence. The Dockerfile targets php:8.3-fpm-alpine and node:22-alpine. package.json pins React 16 and react-router-dom 5, both old major lines, alongside a react-dom alias to @hot-loader/react-dom. Those are deliberate compatibility choices, and they mean the frontend cannot casually absorb a React 18 migration without work from the maintainers.

On licence: the README states MIT and links LICENSE.md, while repository metadata says NOASSERTION. Treat the discrepancy as something to resolve by reading the file, not by assuming either side is right.

## Conclusion

Adopt Pterodactyl Panel if you run a hosting operation or a community with several game servers and you want each instance isolated in Docker behind one Laravel-backed UI. Do not adopt it if you need a single-command install, if you have no MySQL and Redis available, or if you expect the repository to define your licence terms for you. Before committing, verify three things: that your database and Redis hosts match the DB_HOST and REDIS_HOST values you put in .env, that the Node runtime on your build machine satisfies the engines field in package.json, and that you have read LICENSE.md rather than trusting the README's MIT sentence.

## FAQ

### What is Pterodactyl Panel used for?

It is a free, open-source game server management panel that runs each game server in an isolated Docker container and exposes a web UI to end users. It is built with PHP, React and Go, and the README frames it as a way to make game servers a first class citizen on a hosting platform.

### Does Pterodactyl Panel run the game servers itself?

No. The panel is the control plane, and the Go-based Wings daemon is what actually runs containers on a node. The README links to separate Wings documentation, so panel and daemon are two installs.

### What database and cache does Pterodactyl Panel need?

The shipped .env.example sets DB_CONNECTION=mysql on port 3306 and Redis on port 6379, with QUEUE_CONNECTION=redis. Cache and session drivers default to file rather than Redis.

### Is Pterodactyl Panel free to use?

The README states the code is released under the MIT License and links to LICENSE.md, but the repository metadata reports the licence as NOASSERTION. Check LICENSE.md directly rather than relying on either summary.

### Which games does Pterodactyl Panel support out of the box?

The README lists Minecraft (including Paper, Sponge, Bungeecord and Waterfall), Rust, Terraria, Teamspeak, Mumble, Team Fortress 2, Counter Strike: Global Offensive, Garry's Mod and ARK: Survival Evolved as core supported games. Community-provided eggs cover more, including Factorio, Squad and Discord bots.

## Sources

- [Issues](https://github.com/pterodactyl/panel/issues)
- [Project website](https://pterodactyl.io)
- [pterodactyl/panel on GitHub](https://github.com/pterodactyl/panel)
- [README](https://github.com/pterodactyl/panel/blob/1.0-develop/README.md)
- [Releases](https://github.com/pterodactyl/panel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pterodactyl-panel