Pterodactyl itself is not the main workload. The total requirement comes from every game server that may run at the same time, plus Linux, Panel, Wings, Docker and backup headroom.
This article is a capacity worksheet. Installation, nodes, allocations, eggs, users, commands and troubleshooting remain in the complete Pterodactyl guide.
Pterodactyl Node Sizing Steps
List the Game Servers
Record every instance that can run together.
Add Their RAM
Use the maximum allocation for each server.
Reserve Host Memory
Keep RAM for Linux and Pterodactyl services.
Check CPU and Storage
Plan for busy periods, worlds and backups.
Use the existing complete guide for Panel, Wings, nodes, allocations, eggs, users, files, backups, commands and troubleshooting.
Open the Complete Pterodactyl Guide →List Every Game Server You Will Run
Begin with the games, not the Panel. Write down every instance that may be online together, including test servers, proxies and temporary event servers.
| Server | RAM Allocation | CPU Pattern | Storage |
|---|---|---|---|
| Minecraft Paper | 4GB | Busy during exploration and plugins | World, plugins and backups |
| Factorio | 4GB | Steady simulation load | Save, mods and autosaves |
| Luanti | 2GB | Light private workload | World, game and mods |
Replace the examples with your own games and allocations. The worksheet should reflect what can run at the same time.
Add the RAM Allocations
Add the maximum RAM for every game server that may be active together. In the example above:
The 10GB total is not the final node size. Linux and Pterodactyl services still need their own memory.
Reserve RAM for Linux and Pterodactyl
Keep memory outside the game allocations for Linux, the Panel stack, database, Redis, queue worker, Wings, Docker, monitoring and filesystem cache.
Leave at least 20% to 30% of the machine outside game allocations. Keep more headroom when Panel, backups and several busy games share one node.
For the 10GB game-server example, a 16GB node gives a clearer operating margin than a 12GB node.
Plan CPU for the Busiest Time
Do not judge CPU needs while every game is idle. Consider the busiest normal period and tasks that can overlap:
- Players joining several servers at once
- Minecraft chunk generation or a heavy modpack
- Factorio simulation on an established factory
- Game updates and installer jobs
- Backup compression and world saves
Stagger backups and updates where possible. Choose VDS when several active containers need predictable dedicated vCPU availability.
Allow Storage for Live Data and Backups
Count more than the current game folders. The node also stores Linux, Docker images, installer files, worlds, saves, logs and local backups.
A 20GB game directory can require far more space after several backups, temporary archives and update files are included.
Keep spare working space and at least one backup away from the live node.
Example: Size a Three-Server Node
| Part of the Calculation | Example Allowance |
|---|---|
| Three game servers | 10GB RAM |
| Linux and Pterodactyl services | 3GB–4GB RAM |
| Growth and short peaks | Remaining headroom |
| Suitable starting total | 16GB RAM |
This is a worked example, not a universal minimum. A heavy modpack or busy Factorio save can change the result substantially.
Choose VPS or VDS
A Pterodactyl VPS suits a personal panel and a small number of moderate game servers. Choose VDS when several active containers compete for CPU or one demanding server needs more predictable processing.
Recalculate Before Adding Another Server
Repeat the worksheet whenever you add a game server, increase an allocation or retain more backups. Do not assume that unused capacity on one quiet day will remain available during the next busy session.