# Pyrodactyl: a rewritten Pterodactyl panel that has already moved house

> Pyrodactyl is a PHP and React fork of the Pterodactyl game server panel built around a Vite and Turbo frontend, and this repository is no longer the active project, with issues and pull requests moved to a separate pyrodactyl-oss organisation. What remains here is worth reading for the frontend architecture, not for running a panel.

**pyrohost/pyrodactyl** — Pyrodactyl is the Pterodactyl-based game server panel that's faster, smaller, safer, and more accessible than Pelican.

- Repository: https://github.com/pyrohost/pyrodactyl
- Website: https://pyrodactyl.dev/
- Stars: 883 · Forks: 113
- Language: PHP
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/pyrohost-pyrodactyl

## This repository is a pointer, not the project

The first thing the README tells you is that the repository is no longer in use or getting updates, and that the current project lives at a different GitHub organisation, pyrorodactyl-oss. A second note says all issues and pull requests should be made in that same repository. A third warns that Pyrodactyl is under development and pre-release, that some UI elements may appear broken, and that there might be bugs. Put together, that is a fork with a moving target: the code here is the history, the actionable project is elsewhere. For an evaluation this matters most when you check maintenance state. The last push to this repository was on 2026-04-30, and the tagged releases listed here stopped earlier, with v4.5.0 published on 2025-10-28, v4.4.0 on 2025-10-25 and v4.3.0 on 2025-10-17. A panel is infrastructure you run for other people, so the difference between a stale mirror and the live fork is the difference between a working service and a dead one.

## The frontend rebuild is the actual contribution

The list of differences from vanilla Pterodactyl is where the engineering went, and it is almost entirely frontend. The panel is built with Vite, and the README claims the initial download size is over 170 times smaller than leading Pterodactyl forks including Pelican, with faster loading times said to average over 16 times better than other closed-source forks and Pelican. The mechanism named for the smaller payload is code splitting and chunking, so pages load only the resources they need on demand, paired with better caching. Builds are said to complete in milliseconds with Turbo, and cold builds with zero cache to finish in under 7 seconds. The dependency list corroborates the shape of the work: React, Radix UI, Tailwind CSS 4, TanStack Query and Virtual, CodeMirror, xterm, chart.js, axios and date-fns. It is a modern single-page application stack sitting on top of an unchanged Pterodactyl backend.

## Two claims worth checking yourself before believing them

Two of the README statements are strong enough that a careful reader should treat them as marketing until measured. The first is that most severe and easily exploitable CVEs simply do not exist in Pyrodactyl because of its modern architecture, plus SRI and integrity checks for production builds. That is a claim about the whole upstream dependency surface, and the panel still runs the Pterodactyl application server, the database layer and the Wings daemon, none of which become safe because the frontend was rewritten. The second is the accessibility statement, that the panel is entirely keyboard-navigable even in context menus and screen-reader compatible, built with the latest web accessibility guidelines in mind. Accessibility claims are the easiest kind to state and the easiest kind to regress, and nothing in this repository provides an automated check for them. Both claims are worth verifying on the running panel rather than accepting from a readme.

## The Dockerfile shows the two-stage build split

The container definition explains where the build speed comes from. It is a multi-stage build with a frontend stage on node:lts-alpine that installs corepack and turbo, copies pnpm-lock.yaml and package.json, and runs pnpm install with a frozen lockfile before pnpm run ship. The second stage is php:8.4-fpm-alpine, which installs the PHP extensions bcmath, gd, pdo, pdo_mysql, pdo_pgsql and zip, then pulls in the runtime packages including nginx, supervisor, dcron, certbot, tar, unzip, curl, git and the mysql and postgresql clients. The compiled frontend output is then copied in from the frontend stage into public/assets and public/build. So the runtime container carries no Node toolchain and no node_modules, and the DEV argument switches the build steps off for local work. The file also carries an explicit TODO at the top about refactoring Docker with stricter permissions and modernized tooling, which tells you the container definition is not finished work.

## Environment configuration still follows the Pterodactyl shape

The example environment file shows that the fork keeps the upstream configuration contract, which is good news for anyone migrating. It sets APP_ENV, APP_DEBUG, an APP_KEY, APP_THEME, APP_TIMEZONE, APP_URL and APP_LOCALE, and it includes APP_ENVIRONMENT_ONLY for panel-only installs. Database settings use the usual DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD keys, and Redis appears as REDIS_HOST, REDIS_PORT and REDIS_PASSWORD. Caching and queuing are separate keys, CACHE_DRIVER set to file and QUEUE_CONNECTION set to redis, with SESSION_DRIVER also on file. Mail goes through MAIL_MAILER, MAIL_HOST, MAIL_PORT and the credential keys, and there is a MAIL_FROM_ADDRESS default plus a commented MAIL_EHLO_DOMAIN entry that references an upstream pull request explaining why that default matters for mail servers. A RECAPTCHA_ENABLED flag defaults to true. The presence of both mysql and postgresql client packages and driver keys says you choose the database rather than inheriting one. The minimum you would set on a fresh panel looks like this, taken from the example environment file.

```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=pyrodactyl
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
CACHE_DRIVER=file
QUEUE_CONNECTION=redis
SESSION_DRIVER=file
```

## What a Pterodactyl fork is, and where Pelican fits

The comparison the README keeps making is with Pelican and with other closed-source Pterodactyl forks. Pterodactyl itself is the base: the licence section credits Pterodactyl copyright to Dane Everitt and contributors from 2015 to 2022, and credits Pyrodactyl copyright to Pyro Inc. and contributors from 2023 onwards, both under Apache-2.0. The panel's job is to manage game servers: a host installs it, and players or staff get web interfaces for server files, consoles and configuration. The fork's pitch is that the operator-facing experience of a game server panel is slow and dated, and that the frontend is the part worth rewriting. The consequence for an adopter is that you are not choosing a new server management model, you are choosing a different skin and build pipeline over the same model, with the upstream compatibility and the upstream security surface still attached.

## Local development has a documented path, Windows does not

The README points to two documentation pages rather than reproducing the steps: one for installation at the pyrodactyl.dev docs site, and one for local development, which it describes as various ways of starting a ready-to-use, fully-featured development environment. It also asks readers to read the documentation before installing. One platform restriction is stated plainly: Windows is currently only supported for development purposes, which means production runs on Linux and the container path is the intended deployment. The repository layout supports that reading. Besides the PHP application directories app, config, database, routes, storage and tests, there is a Vagrantfile and a vagrant directory for the virtual-machine development route, a nix directory with an .env.nix for a reproducible environment, docker-compose.develop.yml and docker-compose.example.yml for the container route, a Dockerfile for production, and a Vagrantfile alongside a .devcontainer-style .vscode directory. There are three overlapping ways to get a working environment, which is generous but also means the docs matter.

## Where this fork is the wrong choice

Four situations rule it out. First, anyone who needs a maintained issue tracker, because this repository is not where issues live anymore. Second, a team that cannot run Docker or manage PHP-FPM with nginx and supervisor by hand, since that is the deployment shape the Dockerfile describes. Third, a project that wants to avoid the Pterodactyl heritage, because the fork keeps the upstream application layer, the upstream environment contract and the upstream Pterodactyl copyright notice, so a licensing review has to cover both. Fourth, an operator who needs a stable, released panel today: the pre-release warning is explicit that UI elements may be broken and bugs may be present. The remaining risk to weigh is not the fork quality but the fork's own churn. The 2026-04-30 push and the 2025 release dates show activity with a long gap between the last tagged build and the last commit, and the new organisation may be moving at a different pace.

## Conclusion

Read this repository for the frontend approach rather than for an install target: the Vite and Turbo pipeline, the smaller bundle and the container stages are the parts worth carrying into your own panel work. Do not deploy from here, because the README states the repository is no longer in use or getting updates and directs issues and pull requests to the pyrodactyl-oss organisation, and the last push to this repository was on 2026-04-30. Verify first that the pyrodactyl-oss repository has the release you intend to run, that its documented installation path matches your host, and that the Apache-2.0 terms recorded in the README cover the Pterodactyl code the fork is derived from before you put it in front of players.

## FAQ

### Is the pyrohost/pyrodactyl repository still the active project?

No. The README states that this repository is no longer in use or getting updates and directs readers to the pyrodactyl-oss repository, and a separate note says all issues and pull requests should be made there. The last push to this repository was on 2026-04-30.

### What licence is Pyrodactyl released under?

The licence section of the README lists Apache-2.0, and credits Pterodactyl copyright from 2015 to 2022 to Dane Everitt and contributors and Pyrodactyl copyright from 2023 onwards to Pyro Inc. and contributors. The repository also contains a separate LICENSE_MIT file.

### How do I install Pyrodactyl?

The README sends readers to the installation documentation at pyrodactyl.dev before installing, and notes that Windows is currently only supported for development purposes. A Dockerfile, docker-compose.example.yml and a Vagrantfile are included in the repository for container and virtual-machine setups.

### What does Pyrodactyl change compared with vanilla Pterodactyl?

The README lists smaller bundle sizes from building with Vite, faster build times with Turbo, faster loading through code splitting and chunking, SRI and integrity checks on production builds, and a keyboard-navigable accessible interface. The environment file keeps the upstream Pterodactyl keys, so the backend configuration contract is unchanged.

### Which database can Pyrodactyl run on?

The example environment file sets DB_CONNECTION to mysql with DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD keys, and the container installs both the mysql-client and postgresql18-client packages, so a PostgreSQL connection is also supported by the configuration surface.

## Sources

- [License: Apache-2.0](https://github.com/pyrohost/pyrodactyl/blob/main/LICENSE)
- [Project website](https://pyrodactyl.dev/)
- [pyrohost/pyrodactyl on GitHub](https://github.com/pyrohost/pyrodactyl)
- [README](https://github.com/pyrohost/pyrodactyl/blob/main/README.md)
- [Releases](https://github.com/pyrohost/pyrodactyl/releases)

---

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