Calagopus is a Rust rewrite of the Pterodactyl game server panel

A reimplementation, not a fork with a new coat of paint

Calagopus is described as a ground up reimplementation of the Pterodactyl Panel in Rust. That word, reimplementation, carries the meaning. The project keeps what made the original work, which the README lists as secure, container based game server management, and aims at better performance, a refreshed interface, more features and a cleaner extension model on both the frontend and the backend.

The audiences are named explicitly. If you already run Pterodactyl or Pelican there is a supported migration path, and the repository topics list both of those names alongside minecraft, rust, docker, self-hosting and react, which is the vocabulary of the ecosystem it is deliberately sitting inside.

The stack is split in two. The backend is Rust on Tokio and Axum, and the frontend is React with Mantine and Tailwind for a clean, responsive interface. The repository description says the panel is built in Rust, while the primary language listed for the repository is TypeScript, which reflects the size of the front end relative to the back end.

The licence is MIT and the homepage is calagopus.com, where the documentation, including the installation guide, the Pterodactyl migration guide and the Pelican migration guide, is hosted.

Eggs carry over, including the validation rules

The compatibility claim that matters most to an existing operator is egg compatibility. Calagopus reuses Pterodactyl style eggs, and the repository contains a rule-validator directory described as a semi port of Laravel's validation rules in Rust, for use with eggs.

That last detail is a good example of how the rewrite actually works. Pterodactyl eggs are configuration that declares what a server is and how it is installed, and they carry validation rules written in the Laravel idiom, because Pterodactyl is a PHP application. Reusing those eggs in a Rust backend means the validation layer has to be reimplemented, which is what the rule-validator crate is for.

A semi port, as the project puts it, is a reasonable description for a partial reimplementation of a large validation surface. The practical consequence for an operator is that some eggs may need small adjustments, and the README frames this as compatibility rather than as a drop in guarantee.

The eggs themselves live outside this repository, in the Pterodactyl and Pelican ecosystems. What Calagopus provides is the loader, the schema and the validation that makes them meaningful.

Extension systems on both sides of the wire

The extension story is the feature the README is most insistent about: first class extension systems for backend and frontend, with no hacky patches or overrides and real plugin APIs.

The repository layout shows how that is built. There is a frontend directory with an extensions folder for things like themes and plugins, and a backend-extensions directory for auth providers and database drivers, with its own node_modules excluded from the Cargo workspace. A shared directory holds code used between backend parts, mainly relevant for extensions, and a schema-extension directory contains a core library for the schema extension system plus a derive directory holding a proc macro that derives schema extensions.

The proc macro is the interesting piece. Extension authors declare a schema in Rust and a derive macro generates the glue, which is a different model from the hand written registration of a plugin in a PHP application. Whether that model is easier to extend with depends on whether you prefer a macro to a configuration file.

An extension template directory at the repository root and the embedded-assets member in the Cargo workspace suggest that extensions are also expected to be shipped as self contained artefacts.

A Cargo workspace with a build for every shape of deployment

The Cargo manifest is a workspace with a set of members, and the members list explains the shape of the system: the backend, the database-migrator, embedded-assets, rule-validator, shared, the bins directory, the api-clients directory, schema-extension and backend-extensions. The default members are bins/base, bins/all-in-one and bins/heavy-supervisor, which is how the project offers different deployment shapes from one tree.

The api-clients directory contains wings-api, an auto generated API client for the Wings API, with a generator-src subdirectory holding the source of the generator, written in TypeScript. Generating the client rather than writing it by hand is what keeps a Rust backend in step with an HTTP API it does not own.

The database side is TypeScript in the migrations and Rust in the runner. The database directory holds migrations using Drizzle, and database-migrator is a tool to run them, built with Rust and SQLx. The .sqlx directory at the root is the offline query cache for SQLx, which is what lets the backend compile against a database schema without a live connection.

The manifest pins the toolchain at Rust 1.99.0, the edition to 2024 and the workspace resolver to 3, and the package version reads 1.2.7.

The compose file exposes the knobs that matter

The deployment path is Docker Compose, and there are several compose files at the root, including compose.yml, compose.minimal.yml, compose.heavy.yml and a couple of all-in-one variants, plus one with database backups. The main file wires three services together, a web service, a postgres service and a cache service.

The environment block for the web service is the clearest summary of how the panel is configured:

      - DATABASE_URL=postgresql://panel:panel@db/panel
      - DATABASE_MIGRATE=true
      - PORT=8000
      - APP_DEBUG=false
      - APP_PRIMARY=true # sets whether this panel instance is responsible for running background tasks (e.g. cleanup)
      - APP_ENABLE_WINGS_PROXY=true # enables the wings proxy feature, allowing the panel to proxy user requests to wings nodes, simplifies home network setups, not recommended for many nodes or high traffic setups

Two of those deserve attention. APP_PRIMARY marks the instance that runs background tasks, which matters when you run more than one panel, since you want exactly one doing the cleanup. APP_ENABLE_WINGS_PROXY is described as simplifying home network setups and explicitly not recommended for many nodes or high traffic, so it is a convenience for a small install rather than a production choice.

The database service uses a pgautoupgrade image on Alpine 18 with the panel user, and the cache service uses Valkey, which is the Redis compatible fork the project has chosen.

Environment settings that change the security posture

The .env.example file is short and every line in it is a decision. Beyond the connection strings and the port, there are three settings that a reader should understand rather than copy.

The first is APP_ENCRYPTION_KEY, whose example value is CHANGEME. It is the key used to encrypt values the panel stores, so it has to be generated properly and kept out of version control, and changing it later means losing access to whatever it encrypted.

The second pair are the caches. APP_USE_DECRYPTION_CACHE caches decrypted values in memory and in Redis, which the comment says improves performance and can be considered less secure. APP_USE_INTERNAL_CACHE keeps short lived values in application memory and Redis instead of Redis alone, which improves performance at the cost of higher memory usage. Both are performance options with a stated security or resource price, and the panel ships with them on.

The third is APP_BLOCKED_CIDRS, a list of subnets the panel refuses to connect to when fetching user provided URLs, for example when importing eggs from a URL. The default list covers the private ranges and the reserved blocks, and setting it to an empty value disables the protection. The .env.example also carries APP_REQUEST_LOG_LIMIT, which caps how many HTTP requests per second are written to the log before the rest are counted and summarised, with zero meaning unlimited.

Releases moving quickly, with a public roadmap

The release history shows active work. Tags named release-1.2.6 and release-1.1.6 were both published on 2026-10-18, and release-1.2.5 on 2026-10-11, with the manifest version sitting at 1.2.7. The repository is not archived and the last push was on 2026-10-22.

Two parallel 1.x lines being cut on the same day is a pattern worth noting for anyone planning an upgrade, because it means release branches are being maintained rather than a single trunk being tagged.

The roadmap is tracked publicly on external notes pages, with separate boards for the frontend and the backend, so the plan is visible without reading issues. Translations run through Crowdin, and there is a Discord server linked from the README for discussing an idea before writing code. The contributing guidance asks for an issue to be opened before larger changes.

For an operator weighing a switch, the practical reading is that this is a young project moving quickly, with a public plan and a migration path, and with the same Pterodactyl and Pelican ideas underneath it. The risk of adopting it is not that the model is different, since it deliberately is not, but that the implementation behind the model is newer than the one it replaces.

Editorial conclusion

Calagopus suits an operator who already runs Pterodactyl or Pelican, wants the same container based model with a faster backend, and can plan a migration rather than a fresh install, since the egg format and the Wings API are preserved. It is the wrong choice if you need a battle tested panel with a long track record, because the project is young and its releases are recent. Before switching, read the migration guide for your platform, keep your existing panel running until the new one is serving users, and set APP_ENCRYPTION_KEY and APP_BLOCKED_CIDRS deliberately in the environment file before the first start.

Frequently asked questions

Official sources

1. calagopus/panel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases