When you run several game servers (or hundreds of customer instances) on dedicated hardware, the management panel becomes part of your performance profile. Pterodactyl has been the de facto standard for years, and its successor Pelican is now production-ready. The panel itself is not a game server — it is a Node.js control plane that creates Docker containers, allocates ports, and streams console output. At scale, the panel’s own bottlenecks — WebSocket throughput, container orchestration, and database queries — become the thing that breaks before your game servers do. Here is how to architect it properly on bare metal.
Separate Panel From Nodes
The single most important scaling decision is to never run the panel and game nodes on the same machine. The Pterodactyl/Pelican panel is a Laravel application backed by MySQL, with a queue worker and a WebSocket daemon (Wings/Pelican’s agent connects back to it). It is latency-sensitive in a different way than game servers: database queries block user actions, and the WebSocket layer fans out console and stats traffic to every open browser session.
Run the panel on a small dedicated VM or bare-metal box (4 cores, 8-16 GB RAM, NVMe for the database), and run Wings agents on separate game nodes. This keeps panel CPU spikes and database I/O away from your game simulation threads entirely. It also means a panel restart does not interrupt running game servers — a critical property for a hosting business.
Database and Queue Tuning
The panel database is small but writes frequently: every console line, every stat sample, every user action hits it. On MySQL/MariaDB, use InnoDB with a buffer pool sized to at least 2 GB (the whole panel DB usually fits in a few GB). Enable innodb_flush_log_at_trx_commit = 2 for a performance gain if you can tolerate losing a second of panel history on a hard crash. Keep the panel’s own tables and the game databases on separate MySQL instances if you also host game databases — never let a runaway game query block panel logins.
The Laravel queue worker should run as a supervised systemd service with multiple workers (4-8 for a busy panel). If you see delayed “server started” statuses or slow backups in the UI, the queue is the culprit. Redis for cache and sessions dramatically reduces database load versus file-based sessions, and is effectively mandatory above a few dozen nodes.
Wings Agent and Container Overhead
Each game server runs as a Docker container under Wings. Container overhead is small — single-digit percent CPU — but it is not zero, and the number of containers per node matters. Practical density on a 16-core, 64 GB node is 40-80 small Minecraft servers or 8-20 heavy modded/AAA servers, depending on their individual resource allocations. Set hard CPU and memory limits per server in the panel so one customer’s runaway instance cannot starve its neighbors.
Monitor Docker’s own overhead: the container runtime, log drivers, and network bridge all consume resources. Use the json-file log driver with strict rotation (max-size=10m, max-file=3) or you will fill disks with console logs. Disable Docker’s default bridge in favor of host networking for game containers where possible, since bridge NAT adds latency and can trip conntrack limits at high connection counts.
WebSocket and Backend Throughput
The WebSocket daemon maintains a persistent connection to every running Wings instance and every open browser console. At 50 nodes and 200 concurrent admin sessions, that is hundreds of long-lived connections, each receiving periodic stat pushes. A single-threaded Node process can choke here. Put a reverse proxy (nginx or Caddy) in front for TLS termination and tune its worker connections and keepalive settings. If you approach thousands of persistent connections, shard the WebSocket service or put a load balancer in front of multiple panel app instances.
Terminate TLS at the proxy, not in the Node app, and enable HTTP/2 for browser connections. Keep the WebSocket path on a subdomain so you can scale it independently. Watch for the classic symptom of WebSocket saturation: the console freezes while the rest of the UI stays responsive.
Storage Layout for Many Instances
- Panel DB: dedicated NVMe volume, snapshotted hourly.
- Game data: per-node NVMe with XFS or ext4, noatime, and per-server quota.
- Backups: separate network storage — never back up to the same physical disk.
- Logs: rotation enforced at the Docker and panel levels; ship off-box for retention.
Filling a game node’s disk is the most common self-inflicted outage in panel hosting. Enforce quotas and monitor free space with alerts at 70% and 85%. Our bare-metal plans give you the raw NVMe capacity and IOPS to run dense container fleets without storage contention.
Pterodactyl vs Pelican at Scale
Operational Discipline Keeps the Fleet Healthy
Above a handful of nodes, the panel is only half the story — operations decide whether you stay online. Automate node health checks that restart a wedged Wings agent, rotate all container logs on a schedule, and keep a documented restore procedure for the panel database. Test that restore quarterly; an untested backup is not a backup. Keep panel and node versions aligned, because a version skew between the panel and an agent breaks server creation in confusing ways.
Capacity planning should be continuous. Track per-node container count, average CPU steal, RAM utilization, and free disk, and move servers off a node before it hits 80% on any axis. Headroom is what lets you absorb a customer’s unexpected AAA-server launch or a DDoS-driven CPU spike without a migration. Panels make game hosting look like software, but underneath it is still bare-metal resource management, and the discipline is the same.
Pelican is the modern successor, offering a cleaner codebase, better performance on the backend, and active development as Pterodactyl’s original maintainers moved on. For a fresh deployment in 2026, Pelican is the safer long-term choice, though Pterodactyl remains battle-tested and has a larger ecosystem of community themes and addons. Either way, the scaling principles are identical: separate panel and nodes, tuned database, rotated logs, enforced quotas. Review our dedicated server comparison to pick nodes with the cores, RAM, and NVMe density your fleet needs.
Leave a Reply
You must be logged in to post a comment.