Pterodactyl: the game server panel that saves you from SSH-ing in every time someone wants to restart Minecraft

You know the pattern. Someone in the Discord wants a mod added to the Minecraft server. Someone else wants more RAM because the modpack got heavier. A friend wants the Rust server restarted because it froze at 3am. Every one of these routine requests turns into “hey, can you SSH in and do X,” and eventually you’re the unpaid systems administrator for six people’s hobby.

That’s the exact problem Pterodactyl was built to solve. It’s a free, open source game server management panel, MIT licensed , with the code on GitHub and documentation at pterodactyl.io . We run it ourselves: DreamServer’s dedicated game server hosting is built on Pterodactyl, precisely so customers get a real self-service panel instead of a support ticket queue for routine tasks like restarting a server or swapping a mod pack.

What Pterodactyl actually is

Pterodactyl splits into two pieces, and understanding that split is the key to understanding everything else about it.

The Panel is the web application, built on PHP and Laravel. It’s what you and your users see: the dashboard, user accounts, the server list, billing hooks if you wire it up to something like WHMCS. The Panel doesn’t run any game servers itself, it’s the control plane: it knows what servers exist, who owns them, what resources they’re allotted, and it talks to the machines that do the actual work.

Those machines run Wings, a daemon written in Go that lives on each game server node. Wings starts, stops, and manages the game server processes, launching each one inside its own Docker container. That’s the detail that matters most operationally: every game server is isolated. A crashed or misbehaving Rust server can’t take down the Minecraft server next to it on the same box, because they don’t share a process space, and resource limits (CPU, RAM, disk) are enforced per container rather than being a polite suggestion.

The third piece is eggs: a templating system describing how to install, configure, and run a specific type of game server. An egg for Paper Minecraft knows how to download the right jar, generate the startup command, and expose the right config variables in the Panel UI. Official and community eggs exist for hundreds of games: Minecraft in all its flavors (Vanilla, Paper, Forge, Fabric), Rust, ARK: Survival Evolved, Valheim, Terraria, CS2 and other Source-engine titles, and plenty more. Adding support for a new game doesn’t mean patching Pterodactyl itself, it means writing or importing an egg.

Why it matters

The obvious win is self-service. A restart, a mod swap, a look at the console to see why the server crashed: none of that needs an admin with SSH access anymore. That’s exactly the model behind our dedicated game server hosting : the servers are Pterodactyl-managed, so a customer running a Minecraft or Rust server gets full self-service control without needing shell access to the host.

The less obvious win is safety. Docker isolation means a container that eats all its allocated RAM gets killed by Docker, not by taking the whole host down with it. Per-server resource limits mean one noisy neighbor can’t starve everyone else’s server on the same node, whether you’re running this for six friends or six hundred paying customers.

What you get out of the box

• Eggs for hundreds of games, covering the obvious ones (Minecraft variants, Rust, ARK, Valheim, Terraria, CS2) and plenty of community-maintained niche titles.
• Per-server resource limits: CPU, RAM, and disk quotas enforced through Docker, so allocations are actual guarantees, not gentleman’s agreements.
• SFTP access per server, so users can manage worlds, configs, and mods directly without needing shell access to the host.
• A live console in the browser, streaming stdin/stdout, so you can watch a server boot or debug a crash without a terminal.
• Subusers, letting you hand a friend or a community moderator limited permissions on one specific server, without giving them the keys to your whole panel.
• Scheduled tasks and backups, so restarts, world backups, or command execution can run on a timer instead of needing a human to remember.
• A REST API, for anyone who wants to script server management, tie it into a Discord bot, or integrate it with a billing system.
• Multi-node scaling: one Panel can manage many Wings nodes, which can be spread across different physical machines or even different locations.

Installing Pterodactyl on a VPS

A realistic install has two moving parts that can live on the same box (fine for a small setup) or on separate machines (what you want once you’re running more than a handful of servers).

The Panel wants a fairly standard web stack: PHP, MariaDB or MySQL, Redis, and a web server in front (Nginx or Caddy). The official install path is a web-based installer after you pull the code and get Composer dependencies in place. Community-maintained Docker Compose setups also exist if you’d rather run the whole Panel stack as containers.

A typical bare-metal-style Panel setup looks roughly like this:

# System dependencies (Debian/Ubuntu example)
apt update && apt install -y php8.3 php8.3-{cli,gd,mysql,mbstring,bcmath,xml,curl,zip,intl} \
  mariadb-server nginx redis-server curl tar unzip git composer

# Pull the panel and install PHP dependencies
mkdir -p /var/www/pterodactyl && cd /var/www/pterodactyl
curl -Lo panel.tar.gz https://github.com/pterodactyl/panel/releases/latest/download/panel.tar.gz
tar -xzvf panel.tar.gz && chmod -R 755 storage/* bootstrap/cache/
composer install --no-dev --optimize-autoloader

# Environment + database migration (interactive)
cp .env.example .env
php artisan key:generate --force
php artisan p:environment:setup
php artisan p:environment:database
php artisan migrate --seed --force
php artisan p:user:make

Wings, the daemon that actually runs game servers, is a separate install and itself relies on Docker to launch containers. The modern, standard path is to run Wings as a systemd-managed service (or as a container) on each node you want to host servers on:

# On each Wings node (needs Docker installed first)
mkdir -p /etc/pterodactyl
curl -L -o /usr/local/bin/wings \
  "https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64"
chmod u+x /usr/local/bin/wings

# Grab a node token from the Panel's admin UI, then:
wings configure --panel-url https://panel.example.com \
  --token <node-token> --node <node-id>

systemctl enable --now wings

For a small setup, Panel and Wings on the same VPS or dedicated server is perfectly fine. Once you’re running enough concurrent players or servers that CPU contention becomes a real concern, splitting Wings onto its own dedicated box (or several, one per region) is the natural next step, and the Panel handles multiple nodes without any architectural change.

Ports to open depend on what’s running where. The Panel needs the standard web ports, Wings exposes its own API port, and each game server needs whatever port range you allocate for it:

ufw allow 80/tcp        # Panel HTTP (redirect to HTTPS)
ufw allow 443/tcp       # Panel HTTPS
ufw allow 8080/tcp      # Wings default API/SFTP port (adjust to your config)
ufw allow 25565:25665/tcp   # example game server port range (Minecraft-style)
ufw allow 25565:25665/udp   # if your games need UDP too

This is exactly the kind of workload that fits well on a DreamServer VPS or a dedicated box: predictable CPU and I/O, Docker support out of the box, and enough headroom to run Panel, Wings, and a handful of game servers side by side without stepping on each other.

Configuration patterns worth knowing

Split Panel and Wings across nodes early

If you expect this to grow past a hobby project, don’t wait until you’re CPU-starved to separate Panel and Wings. Put the Panel on a small, low-resource box (it’s mostly PHP and a database), and size Wings nodes for the actual game workloads. Different regions can run their own Wings nodes pointed at the same Panel, which is how you’d offer, say, an EU and a US location from one admin interface.

Pick eggs deliberately

Egg quality varies. Official eggs tend to be solid and kept up to date; community eggs range from excellent to abandoned. Before committing a game to production, read the egg’s install script and startup command. For something unusual (a specific mod loader version, custom plugins baked into the image), you may end up forking or writing your own egg rather than trusting a random one you found.

Set resource limits with headroom

A container that hits its memory limit gets killed by Docker’s OOM handling, which for a game server usually means an ungraceful crash, not a clean shutdown. Size RAM limits with a margin above what the process normally needs (Minecraft with a big modpack is the classic case where people set -Xmx right at the container limit and wonder why it dies under load). CPU limits are softer: Docker throttles rather than kills, so a tight CPU limit just means lag.

Use subusers, and put backups off-node

Give trusted community admins subuser access to their specific server rather than sharing the owner’s login: permissions are granular enough for console access and file management without handing over billing or delete rights. And decide deliberately where backups live: local backups protect against a corrupted world file, not a dead disk. Pterodactyl supports S3-compatible storage as a backup destination, the sane default for anything a community actually depends on.

Lock the Panel down like the admin interface it is

The Panel has full control over every server it manages, so treat access accordingly: two-factor authentication for admin accounts, a small number of full-admin users, and HTTPS with a real certificate, not a self-signed one users have to click through.

Where Pterodactyl is not the right answer

If you’re running exactly one Minecraft server for yourself, with nobody else needing access and no need for a web UI, Pterodactyl is overkill. A game binary in a systemd unit or a tmux/screen session, with a couple of shell aliases for start/stop/backup, has essentially zero overhead and nothing to maintain beyond the game itself. Panel plus Wings plus MariaDB plus Redis is real infrastructure that needs updates, monitoring, and patching. That’s a fair trade when you’re managing servers for other people, and a bad trade when you just want your own Valheim world up on weekends.

It’s also not a universal fit for every game server binary out there. Anything that doesn’t containerize cleanly, or expects direct hardware access, can be awkward to wrap in an egg. And egg quality is uneven: popular games are well covered, obscure ones may have a thin or unmaintained egg, or none at all, meaning you’re writing your own.

Alternatives we considered

Crafty Controller : simpler and more narrowly focused on Minecraft. If Minecraft is genuinely the only game you’ll ever run, Crafty’s lower complexity is a real advantage over Pterodactyl’s broader, heavier stack.

AMP (Application Management Panel) : commercial-friendly, broad game support, and a polished out-of-box experience from CubeCoders. Not fully open source the way Pterodactyl is, and licensing costs scale with usage, but a legitimate option if you want a supported commercial product.

Pelican Panel : a newer, Pterodactyl-inspired fork with its own development direction. Worth watching, though less battle-tested simply by virtue of being younger.

Plain systemd or tmux/screen: for the single-server, single-admin case, this is genuinely the right answer. No web stack, no Docker layer, just the game process and your shell.

So, should you run it?

If you’re managing more than one or two game servers, or if anyone besides you needs to touch them, Pterodactyl earns its keep. The Panel plus Wings architecture, Docker isolation, and the egg system cover a genuinely wide range of games with real safety guarantees around resource limits, and the self-service model means you stop being the bottleneck for routine requests.

If you’d rather skip building that stack yourself, our dedicated game server hosting runs on Pterodactyl already: you get the Panel, console, SFTP, and subuser access without standing up the infrastructure. If you want to run your own install, a DreamServer VPS is a solid place to put Panel and Wings, and our server administration service can keep it patched while you focus on the game servers themselves.