Running a Valheim server for six friends and a Palworld server for a Discord community used to mean two separate boxes, two separate billing cycles, and two separate headaches every time someone forgot to update the mod list. In 2026, that math no longer makes sense. A single modestly-sized cloud VPS running Pterodactyl Panel can host four or five game servers side by side, each isolated in its own Docker container, each with its own backups, its own file manager, and its own web console that a non-technical friend can actually use.
This tutorial walks through deploying a genuine multi-game cloud stack: Pterodactyl Panel and Wings on a fresh Ubuntu 24.04 LTS VPS, configured to run Valheim, Rust, Palworld, and Minecraft simultaneously, with the kind of cost and network tuning that separates a laggy weekend project from a server people actually want to play on. We will also cover what it costs to run this stack for real, month over month, and how to trim that bill without degrading the experience for players.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Pterodactyl Panel Is the Standard for Self-Hosted Game Servers in 2026
Pterodactyl is a free, open-source game server management panel built with PHP, React, and Go. It runs every game server inside an isolated Docker container while exposing a clean web interface to admins and players, which is the reason it has become the default choice for small hosting operations, Discord community servers, and hobbyists who outgrew a single SteamCMD install running in a tmux session.
The panel repository shows v1.12.0 as a stable release from January 2026, and newer deployment templates published in August 2026 pin the panel image at v1.15.0 as the current production-ready build. The companion daemon, Wings, which handles the actual container lifecycle on each node, sits at v1.12.1. Between panel and daemon, Pterodactyl has shipped a steady cadence of point releases through the first eight months of 2026, mostly hardening the Docker sandboxing and tightening the API used by third-party billing integrations like WHMCS and Blesta.
What makes this relevant to a cloud computing tutorial rather than a pure gaming one is the underlying architecture decision. Pterodactyl treats every game as a container workload with defined CPU, RAM, and disk limits, which means the same discipline you would apply to a Kubernetes deployment (resource requests, health checks, isolated storage) applies directly to a Rust or Minecraft instance. You are not “installing a game server” so much as standing up a lightweight container orchestration layer that happens to run game binaries instead of microservices.
Pterodactyl vs Pufferpanel vs AMP vs Raw SteamCMD: Which Fits a Multi-Game Cloud Stack
Before committing a VPS to any single tool, it’s worth understanding why Pterodactyl wins out for a multi-game stack specifically, rather than for a single dedicated server. A 2026 cloud VPS hosting guide describes Pterodactyl, Pufferpanel, and similar tools as now giving operators a clean web UI for spinning up multiple game instances on one box, which is precisely the workload this tutorial builds. The distinction between the main options comes down to isolation model, licensing, and how much manual SteamCMD work each one still expects from you.
Pufferpanel is the closest direct competitor: also free and open-source, also web-based, but it uses a lighter-weight process supervision model rather than Pterodactyl’s strict one-container-per-server Docker isolation. That makes Pufferpanel marginally easier to set up on a low-RAM VPS, but it also means a misbehaving game binary has more access to the host than it would inside a Pterodactyl container. AMP (Application Management Panel) supports a broader library of non-Steam titles out of the box and has a more polished commercial tier, but its free tier caps the number of concurrent server instances, which defeats the purpose of a four-game stack unless you pay for a license. Raw SteamCMD with systemd unit files remains the leanest option in terms of overhead, but it pushes every backup, every port mapping, and every crash restart back onto you as shell scripts, with no web UI for the non-technical friend who just wants to restart the Valheim server without SSH access.
| Tool | Isolation model | Cost | Best fit |
|---|---|---|---|
| Pterodactyl | Docker container per server | Free, open-source | Multi-game stacks needing strong isolation and a polished UI |
| Pufferpanel | Process-level supervision | Free, open-source | Low-RAM VPS, simpler single-game setups |
| AMP | Process-level with commercial dashboard | Free tier limited; paid tiers from ~$60/yr | Wide non-Steam game library support |
| Raw SteamCMD + systemd | None (shared host) | Free | Single-server hobbyists comfortable with shell scripting |
For the four-game stack this tutorial builds, Pterodactyl’s Docker isolation is the deciding factor: if Rust’s server binary hits a memory leak (a recurring complaint in the game’s own community forums after major updates), it stays contained to its own container instead of starving Valheim or Minecraft running alongside it on the same box.
Prerequisites and Versions You Need Before Starting
Before touching a terminal, confirm you have the following in place. Skipping any of these is the single biggest cause of a broken installation halfway through Step 6.
- A cloud VPS with a minimum of 4 vCPUs and 8 GB RAM for a two-game stack, or 8 vCPUs and 16 GB RAM if you plan to run all four games from this guide simultaneously
- Ubuntu 24.04 LTS as the base OS, the version used in verified 2026 Pterodactyl tutorials and the current long-term support release
- PHP 8.3 with the standard Pterodactyl extension set (cli, gd, mysql, mbstring, bcmath, xml, curl, zip, intl, sqlite3)
- MariaDB 11.8.8 (LTS) or newer for the panel database
- Redis 8.10.0 or newer for caching and queue handling
- Docker Engine (latest stable) for Wings to manage game containers
- A registered domain name or subdomain with DNS pointed at your VPS, since the panel expects a hostname for SSL
- SteamCMD dependencies (lib32gcc-s1 on Debian-based systems) for any Steam-distributed game like Valheim, Rust, or Palworld
- A minimum 80 GB SSD-backed disk, since Rust alone can consume 20-25 GB once a map has been running a few weeks
Budget-wise, a 4-game stack sized this way typically lands between $40 and $70 per month depending on your cloud provider, which we break down later in this guide with a full cost table.
Step 1: Provision the Cloud VPS and Harden Base Access
Start with a fresh Ubuntu 24.04 LTS instance. Whatever provider you choose, size the instance to the RAM math above: roughly 100 MB of overhead per active player on lightweight titles like Valheim, and considerably more (closer to 300-500 MB per player) for Rust and Palworld once world size and mods are factored in. Before installing anything, lock down SSH and create a non-root sudo user.
adduser gameadmin
usermod -aG sudo gameadmin
ufw allow OpenSSH
ufw enable
apt update && apt upgrade -yReconnect as the new user before proceeding. Running the panel install as root works, but it defeats the entire point of container isolation if your host account is also compromised.
Step 2: Install PHP 8.3, MariaDB, Redis, and Composer
Pterodactyl’s panel is a Laravel application, so it needs a full PHP-FPM stack plus a database and cache layer. Add the PHP repository and install the dependency set the panel expects.
sudo apt install -y software-properties-common curl apt-transport-https ca-certificates gnupg
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install -y php8.3 php8.3-{common,cli,gd,mysql,mbstring,bcmath,xml,fpm,curl,zip,intl,sqlite3}
sudo apt install -y mariadb-server redis-server nginx tar unzip git
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composerSecure the MariaDB installation and create a dedicated database and user for the panel rather than reusing an existing one, since Pterodactyl’s migrations expect exclusive ownership of the schema.
sudo mysql_secure_installation
sudo mysql -u root -p -e "CREATE USER 'pterodactyl'@'127.0.0.1' IDENTIFIED BY 'STRONG_PASSWORD_HERE';"
sudo mysql -u root -p -e "CREATE DATABASE panel;"
sudo mysql -u root -p -e "GRANT ALL PRIVILEGES ON panel.* TO 'pterodactyl'@'127.0.0.1' WITH GRANT OPTION;"
sudo mysql -u root -p -e "FLUSH PRIVILEGES;"Step 3: Download and Configure Pterodactyl Panel
Pull the current stable release rather than the develop branch, which can carry breaking changes between point releases.
sudo mkdir -p /var/www/pterodactyl
cd /var/www/pterodactyl
sudo curl -L https://github.com/pterodactyl/panel/releases/latest/download/panel.tar.gz | sudo tar -xzv
sudo chmod -R 755 storage/* bootstrap/cache/
cp .env.example .env
sudo composer install --no-dev --optimize-autoloaderRun the environment setup wizard, which walks through database credentials, mail configuration, and the admin account. Use the recommended production flags to force HTTPS and disable debug output.
php artisan key:generate --force
php artisan p:environment:setup
php artisan p:environment:database
php artisan p:environment:mail
php artisan migrate --seed --force
php artisan p:user:makeSet the correct ownership so nginx and the queue worker can write to storage and cache directories.
sudo chown -R www-data:www-data /var/www/pterodactyl/*Step 4: Configure Nginx and TLS for the Panel
Create an nginx server block pointed at the panel’s public directory, then issue a Let’s Encrypt certificate with certbot rather than running the admin panel over plain HTTP. The panel handles player billing and API tokens; unencrypted traffic here is not a corner worth cutting.
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d panel.yourdomain.com
sudo systemctl enable --now pteroq.service
sudo systemctl status nginxThe pteroq service runs the Laravel queue worker in the background, handling scheduled tasks like backup rotation and email notifications. If this service is not enabled, backups silently stop running, which is one of the more common misconfigurations reported in Pterodactyl’s community support channels.
Step 5: Install Wings and Register the Node
Wings is the daemon that actually runs the Docker containers for each game server. On a single-VPS setup, it runs on the same machine as the panel, but it can just as easily run on a separate node if you outgrow one box. Install Docker first, then Wings.
curl -sSL https://get.docker.com/ | CHANNEL=stable sh
sudo systemctl enable --now docker
sudo mkdir -p /etc/pterodactyl
curl -L -o /usr/local/bin/wings "https://github.com/pterodactyl/wings/releases/latest/download/wings_linux_amd64"
sudo chmod u+x /usr/local/bin/wingsIn the panel’s admin area, create a new Node under Admin > Locations > Nodes, then copy the auto-generated configuration into /etc/pterodactyl/config.yml on the VPS. Start Wings as a systemd service so it survives reboots.
sudo systemctl enable --now wings
sudo systemctl status wingsStep 6: Deploy Your First Server (Minecraft) to Verify the Stack
Before adding the more resource-hungry titles, confirm the full pipeline works end to end with Minecraft, which has the simplest egg (Pterodactyl’s term for a server template) and the fastest feedback loop. In the panel, go to Admin > Servers > Create New, select the Minecraft: Java egg, assign 2 GB RAM and 2 vCPU cores, and deploy.
A successful deploy shows a live console streaming the server startup log, ending in a line similar to Done (23.841s)! For help, type "help". If the container fails to start, check Wings’ logs first, since panel-side errors almost always trace back to a Docker permission issue or an image pull failure.
sudo journalctl -u wings -f --no-pagerStep 7: Add Valheim, Rust, and Palworld via SteamCMD Eggs
With the base stack proven, add the Steam-distributed titles. Each uses SteamCMD under the hood inside its own container, pulling the dedicated server binary by app ID. Valheim’s Linux dedicated server binary installs under app ID 896660, confirmed by current SteamCMD quick-start guides using the command below inside the container.
./steamcmd.sh +force_install_dir ./valheim +login anonymous +app_update 896660 validate +quitPterodactyl’s egg system automates this pull automatically when you assign the Valheim egg to a new server, so you generally never type this command by hand, but it is worth understanding what is happening under the container’s hood when a deploy takes ten minutes to finish downloading a 1 GB game binary.
Repeat the same process for Rust and Palworld, sizing each container according to the RAM table in Step 9. Palworld in particular benefits from being deployed with the recommended AWS Marketplace reference configuration as a baseline: a minimum of 4 GB RAM, UDP port 8211 for the game itself, UDP port 27015 for the Steam query protocol, and a default max player count of 32 before you need to scale RAM further.
Step 8: Configure Port Allocations and Firewall Rules
Each game server needs its own port allocation, assigned through Admin > Nodes > Allocations in the panel, then opened at the OS firewall level. Running four games on one VPS means juggling eight to twelve open ports, so keep a written map of what belongs to what before you lose track.
sudo ufw allow 25565/tcp comment 'Minecraft'
sudo ufw allow 2456:2457/udp comment 'Valheim'
sudo ufw allow 28015:28017/udp comment 'Rust'
sudo ufw allow 8211/udp comment 'Palworld game'
sudo ufw allow 27015/udp comment 'Palworld query'
sudo ufw allow 8080/tcp comment 'Pterodactyl daemon SFTP'
sudo ufw status numberedIf you later move to a Kubernetes-based setup instead of a single VPS, be aware that exposing UDP-heavy game traffic through a standard LoadBalancer service can add up to roughly 0.5 milliseconds of extra routing latency in worst-case scenarios, according to a Kubernetes community discussion on the topic. For a Pterodactyl VPS deployment this is a non-issue since Wings binds directly to host ports, but it matters if you eventually outgrow a single-node stack.
Step 9: Right-Size RAM and CPU Allocations Per Game
Over-allocating RAM to a container that does not need it is the fastest way to burn cloud budget without improving performance. The table below reflects real-world per-player memory footprints gathered from 2026 VPS hosting guides and AWS Marketplace reference deployments.
| Game | Base RAM (idle server) | Per-player footprint | Recommended container RAM (8-10 players) |
|---|---|---|---|
| Minecraft: Java | 1 GB | ~150 MB | 2-3 GB |
| Valheim | 1.5 GB | ~100 MB | 2-4 GB |
| Rust | 4 GB | ~300 MB | 8-10 GB |
| Palworld | 3 GB | ~350 MB | 4-6 GB |
Rust is consistently the outlier: its procedurally generated maps and heavy entity count make it the most RAM-hungry of the four by a wide margin, which is why sizing guides recommend treating it closer to its own dedicated instance rather than one container among several on a shared 8 GB VPS.
Step 10: Tune Network Latency for Competitive Multiplayer
Once the servers are running, the difference between a server that “works” and one players actually stay on comes down to latency consistency, not raw throughput. A widely cited 2026 UDP optimization guide sets clear targets: average round-trip time under 20 milliseconds and jitter (measured as mdev in a ping trace) under 2 milliseconds for competitive gaming, with sustained jitter above 5 milliseconds signaling real path or buffer problems that manifest as visible lag spikes.
# Measure current latency and jitter to the VPS
ping -c 100 -i 0.1 your-vps-ip | tail -3
# Test UDP throughput specifically
iperf3 -c your-vps-ip -u -b 1M -t 30
# Reduce NIC interrupt coalescing to trade CPU for latency
sudo ethtool -C eth0 rx-usecs 0 tx-usecs 0
# Raise the backlog queue for burst traffic
sudo sysctl -w net.core.netdev_max_backlog=10000Pairing this with the fq_codel or CAKE queuing discipline, and tagging game traffic with DSCP Expedited Forwarding (--set-dscp 46) if your provider’s network respects QoS markings, keeps game packets from queuing behind background traffic like backup uploads or panel API calls running on the same box.
Step 11: Automate Backups and Crash Recovery
Pterodactyl ships with built-in backup scheduling per server, storing snapshots either locally or to S3-compatible object storage. Configure this through each server’s Schedules tab rather than relying on manual exports, since a corrupted Rust save file six hours before a wipe is not a mistake you want to make twice.
# Example: panel .env entry for S3-compatible backup storage
BACKUP_DRIVER=s3
AWS_BACKUPS_BUCKET=your-backup-bucket
AWS_DEFAULT_REGION=us-east-1
AWS_ACCESS_KEY_ID=your-access-key
AWS_SECRET_ACCESS_KEY=your-secret-keySet a schedule to trigger a backup every six hours plus one immediately before any scheduled restart, and configure a retention policy that keeps the last three to five backups per server rather than accumulating snapshots indefinitely, which quietly inflates your object storage bill over a few months.
Step 12: Apply Cloud Cost Optimization to the Whole Stack
This is where the FinOps side of the tutorial earns its place. A four-week cost-optimization framework published in mid-2026 for engineering teams maps cleanly onto a self-hosted game server stack, and it is worth running through even on a single VPS.
- Week 1 — tag every resource (VPS, backup bucket, snapshot volumes) and identify what is actually driving your bill; for most game server stacks it is storage and bandwidth, not compute.
- Week 2 — right-size over-provisioned containers using the table from Step 9, and if you are testing new eggs or map wipes, do it on a cheaper burstable instance rather than the production node.
- Week 3 — audit for orphaned resources: old world backups, unused server allocations from games you stopped hosting, and detached storage volumes left over from a migration.
- Week 4 — set a billing alert or anomaly threshold so a runaway backup job or a DDoS-driven bandwidth spike does not surprise you a month later on the invoice.
The table below shows realistic monthly costs for the four-game stack described in this guide across three common VPS sizing tiers.
| Tier | Specs | Games supported | Approx. monthly cost |
|---|---|---|---|
| Starter | 4 vCPU / 8 GB RAM / 100 GB SSD | Minecraft + Valheim (2 games, small groups) | $24 – $36 |
| Standard | 6 vCPU / 16 GB RAM / 160 GB SSD | Minecraft + Valheim + Palworld (3 games) | $48 – $64 |
| Full Stack | 8 vCPU / 24 GB RAM / 240 GB SSD | All 4 games including Rust | $72 – $96 |
Object storage for rotating backups typically adds another $2-$8 per month depending on world sizes and retention length. Compared to running four separate managed game-hosting subscriptions, which frequently run $15-$25 each per game, a self-hosted Pterodactyl stack at the Standard or Full Stack tier usually breaks even within the first one to two months.
Step 13: Set Up Monitoring and Alerting
The panel’s dashboard shows live CPU, RAM, and disk usage per server, but it does not alert you when a container crashes at 3 a.m. Install a lightweight monitoring agent on the host and configure Wings’ built-in crash detection to auto-restart failed containers.
# Check overall host resource usage
docker stats --no-stream
# View Wings' own health and container state
sudo wings diagnostics
# Confirm auto-restart is enabled per server in the panel
# Admin > Servers > [server] > Startup > Crash Detection: EnabledFor anything beyond a hobby deployment, pairing this with an external uptime checker that pings each game’s UDP or TCP port every few minutes closes the gap between “the container is running” and “players can actually connect,” which are not always the same thing after a firewall rule gets accidentally reset during an update.
What Success Looks Like: Verifying the Full Stack Is Actually Running
A deployment that “looks done” in the panel’s dashboard is not the same as a deployment that will hold up under real player load. Before announcing your server IP to anyone, run through these checks and compare the output against what a healthy stack should show.
$ docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
NAMES STATUS PORTS
pterodactyl_minecraft_a1b2c3 Up 2 hours 0.0.0.0:25565->25565/tcp
pterodactyl_valheim_d4e5f6 Up 2 hours 0.0.0.0:2456-2457->2456-2457/udp
pterodactyl_rust_g7h8i9 Up 47 minutes 0.0.0.0:28015-28017->28015-28017/udp
pterodactyl_palworld_j1k2l3 Up 1 hour 0.0.0.0:8211->8211/udp, 0.0.0.0:27015->27015/udpEvery container should show a stable uptime, not a low number that keeps resetting to zero, which would indicate a crash loop. A container restarting every few minutes almost always traces back to the RAM under-provisioning pitfall described below, not a genuine software bug.
$ sudo wings diagnostics
Pterodactyl Wings Diagnostics
------------------------------
Wings Version: v1.12.1
Docker Version: 27.3.1
Kernel: Linux 6.8.0-generic x86_64
Servers Managed: 4
Servers Running: 4
CPU Usage (host): 38%
Memory Usage: 17.2 GB / 24 GB (71%)
Disk Usage: 112 GB / 240 GB (46%)
Panel Connection: OK (last heartbeat 3s ago)A memory usage figure sitting comfortably under 80% with all four games running gives you headroom for the RAM spikes that happen during world saves or map wipes, which are the moments a marginally-sized stack tends to fall over. If this figure is already above 85% with no players connected, revisit the sizing table from Step 9 before players show up and push it further.
5 Common Pitfalls When Running a Multi-Game Cloud Stack
1. Under-provisioning RAM for Rust while sizing the whole VPS around Minecraft. Because Rust’s memory footprint is three to four times higher per player than Minecraft’s, a stack sized for “four games, 8 players each” on an 8 GB box will consistently crash Rust first under load.
2. Forgetting to open UDP ports at the cloud provider’s network firewall level, not just ufw. Most cloud platforms layer a security-group firewall on top of the OS firewall. Players get “connection timed out” errors that look identical whether the block is at ufw or at the provider’s edge, so check both.
3. Running the panel’s queue worker (pteroq) disabled or crashed silently. Scheduled backups, email notifications, and SSL renewal reminders all depend on this service. It fails quietly, and the first sign is usually a missing backup weeks later.
4. Letting backup retention grow unbounded. Without a retention policy, Rust world saves alone can add tens of gigabytes to object storage every month, quietly inflating a bill that started at $3.
5. Skipping the Docker image pin and using the “latest” tag in production. A silent image update can change PHP or MariaDB behavior mid-operation. Reference deployments from mid-2026 explicitly pin versions like panel v1.15.0, MariaDB 11.8.8, and Redis 8.10.0 rather than tracking “latest” for exactly this reason.
Troubleshooting: 8 Issues You Will Likely Hit
1. “502 Bad Gateway” on the panel login page. Usually means PHP-FPM is not running or nginx is pointed at the wrong socket. Check systemctl status php8.3-fpm and confirm the nginx config’s fastcgi_pass path matches your PHP version.
2. Server stuck on “Installing…” indefinitely. The Wings daemon likely lost connection to the panel mid-install, or the Docker image for that egg failed to pull. Check docker images on the node and re-trigger the install from the server’s Settings > Reinstall Server option.
3. Players can join Minecraft but not Valheim, despite both showing “online” in the panel. This is almost always a UDP-specific firewall gap, since Minecraft is TCP and Valheim is UDP. Re-check step 8’s firewall rules specifically for the UDP protocol.
4. Backups fail with an S3 access denied error. Double-check the IAM policy attached to the access key covers s3:PutObject, s3:GetObject, and s3:ListBucket on the exact bucket ARN, not just read access.
5. Rust server crashes every few hours under moderate player load. This is almost always insufficient RAM allocation rather than a bug. Bump the container from 8 GB to 10-12 GB before assuming something else is wrong.
6. SFTP file access from a game’s file manager times out. Confirm port 2022 (Wings’ default SFTP port) is open at both the OS firewall and the cloud provider’s security group, and that Wings itself is running.
7. High jitter and rubber-banding despite low average ping. Average latency numbers hide the problem here. Re-run the ping test from Step 10 and look specifically at mdev; anything consistently above 5 ms points to a network path issue, not a game server misconfiguration.
8. Panel shows the node as offline even though Wings is running. Usually a mismatched SSL certificate or an expired daemon token. Regenerate the node’s auto-deploy token in the panel and reapply it to the node’s config.yml.
Advanced Tips for Scaling Beyond a Single VPS
Once a single node stops being enough, either because you are hosting for a growing community or because Rust and Palworld are fighting over the same CPU cores during peak hours, Pterodactyl supports multi-node deployments natively. Add a second VPS as a new Wings node under the same panel, and the admin UI lets you assign new servers to whichever node has capacity, without players ever needing to know which physical machine they connect to.
For teams already running Kubernetes elsewhere in their stack, it is worth knowing that Pterodactyl itself is not Kubernetes-native (Wings manages Docker directly rather than through kubelet), so treat it as a complementary tool rather than a workload you fold into an existing cluster. If your actual goal is running dozens of ephemeral match-based game servers at scale rather than a handful of persistent community servers, that is a genuinely different problem better suited to a purpose-built game server orchestrator running on Kubernetes, not Pterodactyl.
On the cost side, reserved or committed-use VPS pricing (paying 6-12 months upfront) typically shaves 15-30% off the on-demand rates used in the cost table above, which is worth doing once your stack has proven stable for a full billing cycle. Spot or preemptible instances, by contrast, are a poor fit for persistent game servers since an interruption mid-session drops every connected player.
One more scaling consideration worth planning for early: geographic latency. A single VPS in one region serves nearby players well but adds 100-150 ms of round-trip time for anyone connecting from another continent. If your community spans regions, running a second Wings node closer to that player base and letting each community pick its nearest node is a more sustainable fix than trying to tune away distance-based latency at the network layer, since no amount of queuing discipline changes the speed of light over a transatlantic link.
Hardening the Panel Against Brute-Force and Bot Traffic
A publicly reachable login page for a system that controls file access, backups, and billing for multiple game servers is a predictable target for credential-stuffing bots within days of DNS propagating. Two-factor authentication is built into the panel and should be enabled on every admin account before the first server is deployed, not after the first suspicious login alert.
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.d/pterodactyl.conf <<'EOF'
[pterodactyl-panel]
enabled = true
port = http,https
filter = pterodactyl-panel
logpath = /var/www/pterodactyl/storage/logs/laravel-*.log
maxretry = 5
bantime = 3600
findtime = 600
EOF
sudo systemctl restart fail2banOn the Wings side, restrict the daemon's SFTP and API ports to known IP ranges wherever possible, using the cloud provider's security group rather than ufw alone, since a security group block happens before traffic ever reaches the instance's network stack. If your player base connects from unpredictable IPs, at minimum rate-limit the SFTP port with fail2ban using the same pattern above, pointed at Wings' own log output instead of the panel's Laravel log.
It's also worth disabling the panel's public registration endpoint once your admin and any co-op accounts exist, since an open registration form on a game server panel is functionally an open invitation for someone to create a low-privilege account and start probing the API for misconfigured permissions. This is a single toggle under Admin > Settings > General, easy to forget because the default during initial setup is enabled.
Complete Working Project: The Full Deployment Checklist
Putting every step together, a complete working deployment looks like this in sequence:
- Provision an 8 vCPU / 24 GB RAM Ubuntu 24.04 LTS VPS with 240 GB SSD storage
- Harden SSH access and create a non-root sudo user
- Install PHP 8.3, MariaDB 11.8.8, Redis 8.10.0, Composer, and nginx
- Deploy Pterodactyl Panel v1.15.0, run migrations, and create an admin account
- Issue a Let's Encrypt certificate and enable the pteroq queue service
- Install Docker and Wings v1.12.1, then register the node in the panel
- Deploy a Minecraft server first to validate the full pipeline
- Add Valheim, Rust, and Palworld via their respective eggs, sized per the RAM table
- Open every required TCP/UDP port at both ufw and the cloud provider's firewall
- Configure S3-compatible backups on a 6-hour schedule with 3-5 backup retention
- Apply network tuning (netdev_max_backlog, interrupt coalescing, fq_codel) for consistent jitter
- Set up crash detection and an external uptime checker for each game's port
- Run through the four-week FinOps checklist once the stack has been live for a month
Following this sequence end to end typically takes 90-120 minutes for someone comfortable with basic Linux administration, and closer to three hours for a first-time deployment where every command is being verified as it runs. Most of that extra time in a first attempt goes into DNS propagation waits for the SSL certificate step and into troubleshooting the inevitable firewall rule that got missed on the first pass through Step 8, rather than into the actual installation commands themselves.
Frequently Asked Questions
Can Pterodactyl run on a $5-a-month VPS?
Technically yes for a single lightweight game like Minecraft with two or three players, but the panel itself needs roughly 1 GB of RAM before any game container is added, so anything below 4 GB total RAM will struggle the moment you add a second server.
Is Pterodactyl free to use commercially?
Yes. Pterodactyl is open-source and free, which is why it underpins many commercial game hosting businesses that layer billing software like WHMCS on top of it rather than building a panel from scratch.
Do I need a separate node for each game?
No. A single Wings node can run multiple game containers simultaneously, which is the entire premise of this tutorial. Separate nodes only become necessary once one VPS runs out of CPU, RAM, or disk headroom.
What is the difference between the Panel and Wings?
The Panel is the web-based control interface and database (built on Laravel), while Wings is the daemon that actually talks to Docker on each node to start, stop, and manage the game server containers. The Panel can manage many Wings nodes at once.
Why does Rust need so much more RAM than other games on this list?
Rust's procedurally generated maps, large entity counts, and building persistence system are considerably more memory-intensive than Valheim or Minecraft's chunk-based worlds, which is reflected in the roughly 300 MB per-player footprint versus Valheim's roughly 100 MB.
Can I migrate an existing SteamCMD-based server into Pterodactyl?
Yes, by creating a new server with the matching egg and then uploading the existing world/save files through the panel's file manager or SFTP access, rather than reinstalling the game fresh.
How much does object storage for backups typically cost?
For a 4-game stack with 6-hour backup intervals and a 3-5 backup retention policy, expect roughly $2-$8 per month depending on world sizes, with Rust and Palworld worlds contributing the largest share of that total.
Is Pterodactyl secure enough for a public-facing server?
Pterodactyl was built with security as a core design goal, running every game server inside an isolated Docker container rather than directly on the host, which limits the blast radius if any single game server binary has a vulnerability.
Related Coverage
- Deploy a Multiplayer Game Server With AWS GameLift: 12 Steps [2026]
- Microsoft Defender for Cloud: 12 Steps, 100 Min [2026]
- SpacetimeDB Tutorial: Multiplayer Backend in 13 Steps [2026]
- Sunshine and Moonlight on AWS G7: 12 Steps, 90 Min [2026]
- Codespaces vs Gitpod vs Cloud Workstations: $199 Gap [2026]
