What the Pterodactyl panel hides

Pterodactyl is the panel most game hosts hand you, and two of its numbers are read wrong by nearly everybody who has not run the panel themselves. Both misreadings cost money — one by overbuying, one by blaming the wrong thing for lag.

Pterodactyl's own documentation covers installing it. This is about what the numbers mean once somebody else has.

The CPU limit is not cores

A server allocated "100% CPU" has not been given one core. It has been given a ceiling expressed as a percentage of one core. 200 means it may use up to two cores' worth. 400 means four.

That part people eventually work out. The part they do not is that a limit of 0 means unlimited (not zero) and that the limit is a ceiling rather than a reservation. Nothing is held for you. If four containers on the node all want their ceiling at once, they contend, and each gets less than its number promises.

This is why a server that benchmarks fine at 3am stutters at 9pm on the same allocation. Nothing about your configuration changed. The neighbours woke up, and the honest version of that trade is what separates shared hosting from dedicated.

The memory limit is a wall, not a budget

Pterodactyl enforces memory through the container runtime, and the enforcement is a kill. Exceed it and the process is terminated — not slowed, not swapped, killed.

For a Java server this interacts badly with the heap setting. Give a container 4GB and set -Xmx4G, and you have told Java it may use all of the memory while leaving nothing for the JVM's own overhead: metaspace, thread stacks, direct buffers, the garbage collector's structures. The JVM grows past the limit doing ordinary work and the container kills it.

The heap has to be meaningfully smaller than the container. How much smaller depends on the server, but a heap equal to the limit is always wrong, and the crash it produces looks like a random restart with nothing in the log.

Why nothing is in the log

That is the third thing the panel hides. A container kill is not an application crash: the process does not get to write a stack trace, because it is not asked to stop. It is removed.

So the console shows normal operation and then nothing. People spend days looking for a plugin fault that does not exist. The tell is the exit status rather than the log contents, and it is the same investigative dead end described in diagnosing a crash that leaves no trace.

Allocations, and the port you forgot

An allocation is an IP and port pair assigned to your server. A server needing a query port, an RCON port and a game port needs those allocations to exist, and a game that expects the query port to be the game port plus one will not find it if the panel handed you two unrelated numbers.

This is the most common cause of a server that runs perfectly and appears on no listing at all. The game is up, the query port is not reachable, and every poller concludes the server is offline. It is worth testing from outside rather than assuming, for the same reason any listing problem starts with what the outside world can reach.

Wings, and the layer people forget exists

The panel is a web application. It does not run your server; a daemon called Wings does, on whatever machine the node points at, and the two are separate programs that can disagree.

This matters the first time the panel says the server is offline and the game is demonstrably still running, or the reverse. Neither is lying. The panel is reporting what Wings last told it, and if the connection between them dropped, that report is stale.

It also means the panel's console is a relay rather than the real console. Output that Wings did not capture, such as anything a wrapper script wrote before the container started, never reaches you, which is one more reason the log you want is frequently somewhere the interface does not look.

What the panel is genuinely good at

Restart scheduling, file access without SSH, and per-user permissions that let you give a moderator console access without giving them the box. Those are real, and they are why the panel is everywhere.

It is a control surface, not an abstraction over the underlying machine. The machine still has finite cores, finite memory and a kernel that kills things. A panel that shows you green bars while the node is oversubscribed is not lying to you: it is showing you your limits, which were never a promise about what you would actually get.

Read the allocation numbers as ceilings, keep the heap under the wall, and measure what you actually receive rather than what you were sold. That measurement is the same work as watching uptime and tick times over days, and it is the only thing that tells you whether the plan you are paying for is the plan you are running on.