July 2026 was the most intense month in YorkHost's history on the game hosting side. Within a few days, Palworld server orders went from a handful per week to several hundred per day. Good news on paper, except that our infrastructure was not sized for it and, more importantly, it was not configured correctly for this particular game.
This article is an honest post-mortem. We explain what we got wrong, what we fixed, and what we put in place so that it does not happen again. We would rather write this kind of content than pretend everything went perfectly.
The starting point: a bad CPU platform choice
Our game node fleet has historically been built on Intel processors. That choice made perfect sense for a large part of our catalogue: web hosting, VPS, Discord bots, and most games that spread their load correctly across cores.
The problem is that we applied the same reasoning to Palworld without testing it seriously beforehand.
Palworld is extremely dependent on single-core performance. The dedicated server is barely parallelised: world simulation (Pals, structures, bases, chunk loading) essentially hits one main thread. As a result, on our Intel nodes, as soon as a server ramped up the tick rate collapsed. Players experienced rubber banding, teleporting Pals and delayed interactions, while the machine-wide monitoring showed a perfectly reasonable CPU load.
Lesson number one, the one we should have internalised earlier: every game has its own consumption profile. A modded Minecraft server, a FiveM, an ARK and a Palworld do not consume the same resources. You cannot rely on a single platform for the whole catalogue and expect it to hold. Benchmarking has to be done game by game, under real conditions, with players and an aged world, not on a freshly started empty server.
The spike: several hundred orders a day
The timing did not help. The spike landed right in the middle of the school holidays, when demand for game hosting is structurally at its highest. Players have time, groups of friends form, and conversion on this kind of product goes through the roof.
Within a few days we were taking several hundred Palworld orders per day. Our Intel nodes dedicated to the game saturated very quickly, and the problem compounded itself: the more servers per machine, the worse the in-game experience, including for existing customers who had not asked for anything.
We fully own this: it was our mistake. We had not anticipated the volume, and above all we had badly qualified the hardware platform for this game. The affected customers went through a degradation they should never have experienced.
Emergency response: renting rather than buying
The obvious reaction would have been to order new Ryzen servers and have them installed in our racks. Except that with this kind of hardware, between ordering, delivery, racking, cabling and going live, you are looking at several weeks. Customers needed a solution within days.
So we made a deliberate decision: rent AMD Ryzen nodes from trusted European partners rather than buy.
- Availability within hours instead of several weeks.
- Elasticity: if the spike receded (spoiler: it did), we would not be stuck with hardware amortised over three years and underused.
- Zero supply risk, in a context where lead times on some server SKUs can slip badly.
- Focus on what delivered immediate value to customers: configuration, migration and optimisation, not racking.
It is a classic trade-off between unit cost and speed of execution. In the long run, owning your hardware in your own racks remains more cost-effective, and that is what we keep doing for the backbone of our infrastructure. But when managing a spike, speed was well worth the extra cost.
Customer migration and software layer rework
Hardware was only half the job. In parallel, we completely reworked our Palworld stack on the game panel side.
Migrating existing customers
Every Palworld server hosted on the saturated Intel nodes was migrated to the new Ryzen nodes. The gains were immediate and visible on the tick rate, with nothing for the customer to do on their side.
Reworking our eggs
Our Palworld deployment image was reworked in depth, through several successive iterations within a few days. The main points:
Configuration normalisation
Palworld has the unfortunate habit of scattering its configuration across several files and regenerating default values on startup. We put systematic normalisation in place so that the configuration defined by the customer is the one actually applied, with no silent overwrite.
Purging WorldOption.sav
This file, generated by the game, can override the settings defined in the configuration files. It is a major source of confusion for players, who change a setting and never see it applied. Our script now handles this case cleanly.
Strict limit enforcement
Settings with a direct impact on CPU load (player count, Pal density, build limits) are now capped server-side. It is a constraint for the customer, but it is what guarantees that your node neighbour does not degrade your gaming experience.
Dedicated monitoring
We built an internal tool that exposes the real-time performance of our entire fleet, node by node and service by service. It does not only report average load, but the indicators that actually matter for game hosting. That tool was central to driving the migrations: we could immediately see which nodes were approaching their real limit, not their theoretical one.
A new Palworld pricing grid on Ryzen
The infrastructure overhaul came with an overhaul of the offer. We built a dedicated Palworld grid on Ryzen, structured in five tiers, from €8.99 to €30.99 per month.
The goal was twofold:
Reflect the reality of the game's consumption
A 4-player Palworld server and a 32-player server with massive bases have nothing in common in terms of load. Charging the same for both makes no sense, neither for the customer nor for us.
Guarantee density per node
By calibrating the tiers on what a machine can genuinely absorb, we make sure we do not reproduce July's saturation.
The entry tier deliberately stays affordable, for the small groups of friends who represent the bulk of demand on this game.
Stabilisation
After roughly two weeks, the spike receded. That is the typical behaviour of this kind of wave: a massive influx, a short plateau, then a return to a level higher than before but perfectly manageable.
The situation is stable today. The Palworld fleet runs entirely on Ryzen, the rented capacity leaves us headroom for the next spike (back to school, end-of-year holidays, the next major game update), and our monitoring now alerts us well before the breaking point.
What we take away
Five lessons we now apply across our entire catalogue.
- 1
Test every game individually, under real conditions
No hardware platform is good at everything. The load profile has to be qualified game by game, on an aged and populated world.
- 2
Overall CPU load is not a quality-of-service indicator
On single-threaded games, you have to monitor what the player experiences, not what the machine reports.
- 3
Renting is sometimes the right call
When managing a spike, time to availability beats unit cost. We keep our own machines for the backbone, and stay flexible on the peaks.
- 4
School holidays are an infrastructure event, not just a commercial one
They have to be planned for in capacity, just like the release of a major update.
- 5
Communicate and own it
We were wrong about the initial platform choice. Our customers are the ones who paid for it for a few days, and that is exactly why we are publishing this post-mortem.
If you host a Palworld server with us, or if you are considering it, all of our offers now run on AMD Ryzen. And if you have technical questions about what we put in place, our support team is available to discuss it.
