You just want to run a Minecraft server, why is this three products deep
You wanted one thing: a web page where your friends can restart the Valheim box without texting you at midnight. Instead you found three panels, a fork with a backstory, and a GitHub thread arguing about whether a daemon should be called “Wings” or something else entirely. Take a breath. Close those tabs.
Here’s the short version. If you’re starting fresh and want multi-game support with active development, run Pelican. It’s the 2024 fork of Pterodactyl, it ships releases weekly, and it kept everything that worked while fixing the parts that didn’t. If you only run Minecraft (Java or Bedrock) and you want the whole thing running in a single container by dinner time, run Crafty Controller. If you already have a working Pterodactyl install with eggs you rely on and nothing is actively broken, you can keep running it. It is not abandoned. But it is not where new energy is going either, and this piece verifies exactly why.
All three are free and open source. None of them charge for hosting, features, or seats, so there’s no pricing table to fact-check here, just architecture, versions, and how much RAM you’re about to hand over.
The three contenders, with real numbers
Here’s what’s actually shipping right now, pulled straight from each project’s own release feed:
- Pterodactyl Panel v1.15.1 (released August 2026), MIT licensed, paired with Wings v1.13.3 as its daemon. The panel repo is not archived and commits are still landing.
- Pelican Panel v1.0.0-beta38 (released August 2026), AGPLv3 licensed, paired with its own Wings daemon at v1.0.0-beta29, MIT licensed. Yes, Pelican kept the name Wings. The GitHub org pushed new commits the same day this article was researched.
- Crafty Controller 4 v4.11.0 (released September 2026), GPLv3-or-later, written in Python, hosted on GitLab under
crafty-controller/crafty-4with images published to Docker Hub asarcadiatechnology/crafty-4.
Crafty’s version bump landed literally the day before this was written. That’s not a typo, that’s a project with an active merge queue.
What actually happened with the fork
You’ll find a lot of confident blog posts about “drama” behind Pelican splitting from Pterodactyl. The primary sources are thinner than the drama implies. Pelican’s own FAQ gives the reason in one line: “Difference of visions, directions, and opinions.” It adds that the new team “gave the previous team 2 months of advance notice” and states flatly that there’s no bad blood: “Not at all.” That’s it. No manifesto, no incident report.
What you can verify independently, straight from GitHub’s release history, is a real gap in Pterodactyl’s output. Wings went from v1.11.13 in May 2024 to v1.12.0 in January 2026, a stretch of roughly 20 months with no daemon release. The Panel had its own dry spell too: v1.11.11 in June 2025 to v1.12.0 in January 2026, about six and a half months. The Pelican fork’s repository was created in March 2024, right as that slowdown was starting to bite. Draw your own conclusion, but the timing lines up with the release gap more than it lines up with any documented feud.
Since January 2026, Pterodactyl has resumed a real cadence: v1.12 through v1.15 landed roughly monthly. So “abandoned” is the wrong word for it today. “Slower than the fork it spawned” is the accurate one.
The isolation model is the real fork in the road
This is the part that actually changes how you operate the thing.
Pterodactyl and Pelican split the job into two pieces. The Panel is a Laravel web app that stores users, servers, and permissions in a database. Wings is a separate daemon, written in Go, that runs on each game node and talks to the Docker Engine. Every single game server you create gets spun up as its own Docker container, defined by an “egg” (a YAML template naming the base image, install script, startup command, and exposed ports). Panel and Wings talk over an authenticated API, so you can run one Panel and point it at daemon nodes scattered across five different machines if you want to.
Crafty Controller skips all of that. Crafty is one Python application. You start it, and it launches each game server as a subprocess it manages directly, writing to the process’s stdin, reading its stdout, and restarting it if it dies. There’s no separate daemon, no per-server container, and no API handshake between two services. If you run Crafty in Docker (its most common deployment), every Minecraft server you spin up runs as a process inside that same Crafty container, not as a sibling container next to it.
Neither approach is wrong. Docker-per-server buys you resource limits, image-level isolation, and the ability to run wildly different game stacks side by side without touching the host’s package manager. One shared process buys you simplicity: one thing to back up, one thing to update, one log to tail.
Install complexity, with the actual commands
Pterodactyl’s Panel needs PHP 8.2 or 8.3, MySQL 5.7.22+ or MariaDB 10.2+, Redis, and a web server (Apache, NGINX, or Caddy). Pterodactyl ships an official example compose file in its own repo, which is the fastest honest way to see what’s involved:
services: database: image: mariadb:11 restart: always environment: MYSQL_ROOT_PASSWORD: "change-me" MYSQL_PASSWORD: "change-me-too" MYSQL_DATABASE: "panel" MYSQL_USER: "pterodactyl" volumes: - "/srv/pterodactyl/database:/var/lib/mysql" cache: image: redis:alpine restart: always panel: image: ghcr.io/pterodactyl/panel:latest restart: always ports: - "80:80" - "443:443" links: - database - cache environment: APP_URL: "http://your-domain-or-ip" APP_TIMEZONE: "UTC" APP_ENVIRONMENT_ONLY: "false" CACHE_DRIVER: "redis" SESSION_DRIVER: "redis" QUEUE_DRIVER: "redis" REDIS_HOST: "cache" DB_HOST: "database" DB_PORT: "3306" DB_PASSWORD: "change-me-too" HASHIDS_LENGTH: 8 volumes: - "/srv/pterodactyl/var/:/app/var/" - "/srv/pterodactyl/logs/:/app/storage/logs"That’s a trimmed version of the real docker-compose.example.yml, not a drop-in. Keep the environment: block: the Panel’s entrypoint loops on nc -z -v -w30 $DB_HOST $DB_PORT before it starts nginx, so with DB_HOST unset the container waits forever on an empty hostname and the Panel never comes up.
That gets you the Panel. It does not run a single game server yet, because game servers live on Wings, which is a separate install on a separate node (it can be the same box, but it’s still a separate service):
sudo mkdir -p /etc/pterodactylcurl -L -o /usr/local/bin/wings "https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64"sudo chmod u+x /usr/local/bin/wingsThe binary on disk isn’t a running service yet. Create a node in the Panel, copy its Configuration block into /etc/pterodactyl/config.yml, then write /etc/systemd/system/wings.service (the Panel’s Nodes page hands you the exact unit file). Only after both of those does sudo systemctl enable --now wings do anything; run it earlier and systemd tells you Unit wings.service not found.
Pelican’s Panel install is nearly a mirror image: PHP 8.3 through 8.5 (8.5 recommended), MySQL 8+, MariaDB 10.6+, or PostgreSQL 14+ (SQLite3 works too on supported distros), plus a web server. Its Wings install command looks like this straight from Pelican’s own docs:
sudo mkdir -p /etc/pelican /var/run/wingssudo curl -L -o /usr/local/bin/wings \ "https://github.com/pelican/wings/releases/latest/download/wings_linux_$([[ "$(uname -m)" == "x86_64" ]] && echo "amd64" || echo "arm64")"sudo chmod u+x /usr/local/bin/wingsPelican’s docs use that arch-detecting form rather than a hardcoded amd64 URL, so the same line works on an ARM node. Same caveat as above on starting it: create the node in the Panel, drop its config into /etc/pelican/config.yml, write a wings.service unit from the docs, and only then enable the service.
So for either project you’re standing up two services (Panel and Wings) plus a database plus, for Pterodactyl, a Redis instance. That’s three or four containers or systemd units before your first game server exists.
Crafty collapses all of that into one image:
services: crafty: container_name: crafty image: registry.gitlab.com/crafty-controller/crafty-4:latest restart: always environment: - TZ=Etc/UTC ports: - "8000:8000" # HTTP - "8443:8443" # HTTPS - "19132:19132/udp" # Bedrock - "25500-25600:25500-25600" # Java server port range volumes: - ./crafty/backups:/crafty/backups - ./crafty/logs:/crafty/logs - ./crafty/servers:/crafty/servers - ./crafty/config:/crafty/app/configdocker compose up -dOne docker compose up, no database to provision, no second daemon to authenticate. Your 2 AM self will appreciate the difference the first time a Pterodactyl node loses its Wings token and refuses to talk to the Panel until you regenerate it.
Multi-game support: eggs versus one game, done well
Pterodactyl and Pelican both use “eggs,” small config files naming a Docker image, install script, and startup command for a given game. Because Wings just runs whatever image the egg points at, the practical game list is enormous: Minecraft in every flavor, Valheim, Rust, ARK, Terraria, CS2, Discord bots, even generic Node or Python app eggs. Community egg repositories cover hundreds of titles. Pelican kept the egg format and, being a fork, started fully backward compatible with existing Pterodactyl eggs, though the two egg ecosystems are already drifting apart as each project adds fields the other doesn’t read.
Crafty is honest about being a Minecraft tool first. Its own docs describe it as “A Web based GUI for Minecraft Server administration” with Bedrock support built in and “SteamCMD support on the way,” meaning general Steam-based game servers are not there yet as of this writing. The v4.11.0 changelog is still patching the Hytale support Crafty already shipped in v4.10.x, fixing how it resolves log file paths, so the team is clearly widening scope, just not there yet. If your home lab is Minecraft plus Bedrock and nothing else, that narrow focus is a feature: fewer moving parts means fewer things an update can break.
Resource footprint on a small home lab box
Run the math on what’s resident before a single game server starts.
Pterodactyl or Pelican, minimum viable setup: PHP-FPM plus a web server for the Panel, MySQL or MariaDB, Redis (Pterodactyl requires it, Pelican doesn’t strictly), and the Wings daemon itself sitting on top of the Docker Engine you already need for the game containers. On a small VM or a Raspberry Pi, that’s four to five long-running services before you’ve hosted anyone’s Minecraft world. None of them are individually heavy, but they add up, and MySQL alone will happily eat several hundred MB of RAM at idle depending on its buffer pool settings.
Crafty: one Python process inside one container, plus whatever the game server itself needs. No database server, no cache layer, no second daemon negotiating tokens with the first. On a box with 2 to 4 GB of RAM, that difference is the gap between “comfortable” and “swapping.”
The tradeoff is what you give up: Wings gets you real Docker-level resource limits (CPU shares, memory caps, disk quotas) per server, enforced by the container runtime itself. Crafty’s process supervision can still throttle and monitor, but it’s watching subprocesses, not fencing them off with cgroups the way a container does. For a couch co-op Valheim server for four friends, that distinction rarely matters. For a public server you don’t fully trust the playerbase on, it does.
Who should still run Pterodactyl after the fork
If you already have a working Pterodactyl deployment, nodes configured, eggs tuned, users onboarded, there’s no fire drill here. The project released v1.15.1 last month, the repository isn’t archived, and issues are still getting triaged. Migrating panels for the sake of migrating panels is how you turn a Saturday into a support ticket.
Run Pterodactyl if any of these are true: you depend on a plugin, billing integration, or egg pack that hasn’t been ported to Pelican yet; you manage it for a business where an unplanned re-platform isn’t worth the risk; or you simply have zero complaints about it today. “It works and nobody’s mad” is a legitimate reason to leave a system alone.
Start on Pelican instead if you’re building new: the release cadence right now is faster, the plugin system is a real first-party feature Pterodactyl doesn’t have, and Pelican’s own FAQ promises an official migration guide from Pterodactyl, “at least as easy as upgrading was originally.” That guide is not published yet. Today the only path is a third-party community script, so treat a no-rebuild migration as a near-term promise rather than a shipped feature.
And if none of this “Panel plus Wings” architecture appeals to you and Minecraft is the only thing you host, don’t force yourself into it just because it’s the popular answer. Crafty getting you there with one container is not a compromise, it’s the correct tool for a smaller job.
Common Questions
Can I run Pterodactyl or Pelican on a Raspberry Pi?
Yes, on a 64-bit Pi (Pi 4 or newer) running a supported Linux distro. Both Wings daemons ship official arm64 release binaries and Docker CE supports Raspberry Pi OS 64-bit. Expect the Panel’s PHP, database, and Redis stack to use most of a Pi 4’s 4GB before you add game servers, so budget accordingly.
Is Pterodactyl Panel dead or abandoned?
No. GitHub shows v1.15.1 released in August 2026, the repository isn’t archived, and commits are landing on the default branch. There was a real release slowdown from mid-2025 into January 2026, but the project resumed a monthly cadence afterward. It’s slower than Pelican, not dead.
Does Crafty Controller support games other than Minecraft?
Not fully yet. Crafty’s own project description lists Minecraft Java jars and Bedrock executables as supported today, with SteamCMD-based games listed as “on the way.” Recent releases added Hytale log support, so the scope is widening, but Pterodactyl and Pelican’s egg systems cover far more titles right now.
Do I need a separate database server for Pterodactyl or Pelican?
No, you can run MariaDB or PostgreSQL in its own container alongside the Panel container on the same host. Pterodactyl’s own example compose file does exactly this, bundling a mariadb service, a redis cache service, and the panel image together. You only need a physically separate database host once you’re running multiple nodes.
Can I migrate from Pterodactyl to Pelican without rebuilding my servers?
Not with an official tool yet. Pelican’s FAQ promises a migration guide “at least as easy as upgrading was originally,” but as of this writing that guide isn’t published and no first-party import command ships with the Panel. A third-party script (FinnAppel/Ptero-to-Pelican-Migration-Script) exists. Back up your database before trusting it.
