At the start of this year (2026), I started exploring the possibility of a modern alternative to Pterodactyl, an open-source game management panel that has pretty much been the industry standard for years. I spent about a month hyperfixating on this, reading through thousands upon thousands of lines of code, researching the industry and market further, as well as speaking to people that have to deal with Pterodactyl, from all sides.

Off the back of this research, I decided to start building my own alternative panel, and I chose the very possibly ambitious name "TheGamePanel". There's some information to be found on the project page, the website and the GitHub organisation, but I've never really explained, or even really introduced it. So here we are.

The Landscape

As I mentioned above, Pterodactyl has pretty much dominated the landscape for a while now, and even those that have taken some of that are forks of it. There are also a number of other solutions that fit mostly in the same space, but are either limited to a specific game or are paid products. They themselves are mostly not the best, but for this I'll be focusing on Pterodactyl and its forks, of which there are four primary ones.

• Pelican – The first one that comes to most people's minds when they think of a fork of Pterodactyl. It aims for an improvement in performance, and while it does add a few features that are missing, it's built primarily around the Filament admin panel. Pelican Website.
• Pyrodactyl – Another one that people are familiar with. It also adds a few missing features, though it claims to have completely rebuilt Pterodactyl, which is simply not true. It has modified it a bit and focuses primarily on the frontend aspect. Pyrodactyl Website.
• Reviactyl – Another fork, that while adding a few missing features and tidying up some that already exist, doesn't really do much internally beyond reformatting the original code. Reviactyl Website
• Jexpanel – Another fork with some new features, but one that focuses primarily on the management and billing aspect of running a game server panel. Jexpanel Website

As an honourable mention, there is also Calagopus, a complete rebuild of Pterodactyl using Rust rather than PHP and Go. The system itself is great and will almost always outperform something built in PHP, though it does sacrifice customisability and flexibility.

The Problem with Pterodactyl

If you're reading this article, and you're familiar with me and my work, you'll know how strongly I feel about nice code and cleanly architected and well-thought-out codebases. Pterodactyl, though far from the worst I've seen, is still a bit of a mess. There are parts of the codebase that are poorly written, and there are other bits where additional code has been written to solve a problem that the underlying framework already solves. There are also many logical inconsistencies.

I am well aware, however, that this view of Pterodactyl is only really valid for me and other developers who care about that. The vast majority of Pterodactyl's users are, in fact, not developers, or at the very least, not PHP or even web developers. So let's take a look at some of its other problems, whether they stem from the poorly written code or not.

Security Issues

I've only been a member of the community around Pterodactyl for a short period of time. In that time I've seen far more bugs than I'd expect to see in a project as mature and widely used as this. You only need to look at Pterodactyl's security and quality page to see how many security issues there have been in the last year alone.

Server Transfer Bug

Shortly after I joined the Discord for the community, I started helping some people in the support channel, as I was seeing the same questions and problems over and over again, with a lot of them going unanswered. During this, I discovered that the last release had introduced a critical bug that bricked server transfers. If you attempted to transfer a server between two Wings nodes, the server would be stuck in the "transferring" state and unable to be started, even though the transfer was successful. This was caused by a single change in the most recent release. The change itself was part of a PR that had been refactored at least once to avoid this exact issue.

Despite the constant stream of people facing this issue in both the Discord and GitHub issues, as well as PRs to address the issue, and a breakdown I wrote myself explaining the issue and giving people manual steps to fix it on their installations, it still took 40 days for a fix to be released. The PR that contained the fix had been waiting on attention for 39 of those days. The fix prevented the issue from happening but did nothing to address those that were already broken, and nothing was released anywhere to tell anyone or help anyone address their broken installations.

Lack of Extensibility and Flexibility

Almost everyone that runs Pterodactyl these days uses Blueprint, which is an extension of Pterodactyl that essentially patches it to allow for plugins, themes, and so on. This is a community-run project, and many different extensions have been created by the community, as well as additional platforms to help distribute and/or sell them. Many of these add features that should have been present from the start, and I'd even go a step further and say that a plugin system should have been present from the start.

If you're a semi-serious hosting company, you've almost definitely gone a step further and forked Pterodactyl itself, so you can make the necessary modifications and limit the bugs and errors from the upstream project.

Lack of Management or Processes

The project itself is managed and released almost like it's a hobby project that someone happens to be building, rather than a borderline industry standard piece of software. The release process, the testsuite, and any of the other CI tools you'd expect to be involved are either missing or lackluster. Installing it requires you to install PHP and use Composer to install the dependencies, and in many cases you need to familiarise yourself with some of Laravel's documentation.

There's no real triage or review process, and there's no central source to orchestrate any of it. You need to be checking the GitHub organisation or repository to be made aware of anything, and even then you've got to dig through it and know what you're doing.

Don't get me wrong, I'm aware this is an open-source project, and no maintainer owes anyone their time or effort, but that doesn't mean that they shouldn't be held to a certain standard. It's not like the project is a small hobby project come around, and it's not like there are no sponsors available to help fund the project.

And then the rest...

There are a number of other issues that I've either found myself or heard from other people. In fact, I struggled to find many people that didn't have some frustration or another with it, with a lot of them stemming from the fact that Pterodactyl is missing many features that are not only considered essential, but have been being requested for years. So let's finish this section by saying that the problems are numerous, and you wouldn't have to look far to find one.

Why Something New?

My original intention was to put together some improvements I thought could be made to Pterodactyl and put them forwards to the maintainers. I was going to contribute the changes myself, unless they were something the maintainers would rather do themselves or just not have at all. As I went through this and built up a model of the codebase, reviewing it and writing my own notes, I noticed more and more issues, and the further I looked into them, the more I found. There's a quote from the IT crowd that sums it up perfectly.

"No, no Jen, it's infected! If this was a human being, I'd shoot it in the face!"

So I started researching other codebases, reverse engineering features, reading documentation, and speaking to those involved in the industry in some way or another. Once I'd finished, I had myself a plan for not only what an ideal panel would do, but how it should be built. I've shared the plans and information with a handful of people, and it's been met mostly with excitement and positivity, which is always a good sign. There were some that were sceptical, as people have been attempting this for a while, though almost all of those have simply forked and modified.

There was also a question that many people asked in response to my plans.

Why PHP?

The short answer is, the wider community is already familiar with PHP projects, and I'm primarily a PHP developer. The longer answer is that as a non-compiled scripting language, PHP has a level of inherent flexibility that you won't find in more performant compiled languages like Go and Rust. For a management panel that already offloads the game server orchestration of a separate daemon (Wings), extensibility and flexibility are far more important than performance.

To be clear, this isn't a concession that PHP is slow. Modern PHP, especially running on a persistent process through something like FrankenPHP, is more than capable of handling the workload of a management panel. The performance gap between PHP and compiled languages only really matters when you're doing the kind of heavy lifting that the daemon handles, not the panel.

What is TheGamePanel?

TheGamePanel is still in active development, so there's still quite a bit of code to write, but almost all of it is already planned and mapped out. Besides the obvious fact that it's a game management panel that intends to be a modern alternative to Pterodactyl, there's the following.

Built to run as Software, not a website

TheGamePanel makes use of FrankenPHP, which allows it to run as a persistent daemon with a built-in HTTP server through Caddy. This also means that the entire application can be compiled into a single binary and installed and run on the server as you would anything else. No installing PHP, no dealing with composer updates, no installing nginx. Once you've got it deployed, you'll need a database, and that's it. It makes full use of the system you're installing it on, placing config and data files in the places software normally would, making it fully portable and self-contained, as well as supporting terraform and other deployment tools.

Entirely Purpose Built

The entire system is built from the ground up with very limited third-party dependencies. Every single aspect of it, from the HTTP layer to the database handling, is built entirely to run a customisable game management panel. There's no bloat or additional functionality that simply isn't relevant. It will have an extensive testsuite and will not be held back by downstream dependencies.

Fully Modular and Extensible

The entire system is built from the ground up with the idea of being fully extensible and modular. Except for the framework-like functionality, such as HTTP request handling, database connections, dependency injection, etc. the core features are provided as first-party modules that come preinstalled. It makes use of the same systems that are available to anyone wanting to customise or build a plugin. The entire system is open-source and will be released under the MIT licence, so you can even contribute to the system itself.

And much, much more...

I could write a lot more about the differences, but that's probably best saved for future articles. There are a few things worth highlighting, though.

TheGamePanel is designed to work with the infrastructure you already have. It's compatible with Pterodactyl Wings, Pelican Wings, and Calagopus Wings out of the box, so you don't need to rip out your existing nodes to start using it. It also supports both v1 and v2 Pterodactyl eggs, so you won't lose the work you've already put into configuring your game servers. That said, TheGamePanel does introduce its own replacement for eggs, called Blueprints, which are designed to be more flexible and powerful.

Beyond that, TheGamePanel ships with a fully granular permissions system covering both authentication and API keys. It can be run in headless mode with no web interface at all, making it ideal for API-driven setups, or those that want to build their own frontend.

So what now?

If this is something you're interested in, whether it's something you want to support, find information out about, or even just ask some questions, there are a few ways to do that.

• Check out the GitHub organisation TheGamePanel.
• Follow on X (Twitter) @GamePanelDev.
• Subscribe to the TheGamePanel newsletter.
• Join the TheGamePanel Discord.