Freedom from downtime and latency with our dedicated bare metal servers.
Handle heavy real-time workloads with unparalleled speed and performance.
Bare metal performance with the flexibility of the cloud.
Effective server-side and tech-agnostic cheat detection.
Scaling game instances with automated global orchestration.
Low-latency game server management for a flawless experience.
Custom tools to detect, intercept, and deflect impending attacks.
Transfer data on a global scale fast, private, and secure.
Reach eyeball networks through meaningful peering relationships.
Go global with our custom and secure privately-owned data center.
When Mainframe Industries began building Pax Dei, the studio made an early decision that would shape everything that followed: the game would be persistent, region‑based, and designed to run continuously for years. Players don’t just log in and out. They live in specific worlds, form long‑term communities, and expect those worlds to remain stable over time.
That design philosophy places unusual demands on infrastructure. Hundreds of Unreal Engine servers, each responsible for a specific zone, need to be available globally, without turning operations into an unsustainable cost center.
Over time, Mainframe evolved from a traditional public‑cloud setup to a hybrid Kubernetes architecture that combines hyperscale services with dedicated bare‑metal servers. The result was a 60–70% reduction in game server costs, alongside improved resilience and operational clarity.
From the beginning, Mainframe ran entirely on AWS. The early backend followed a conventional pattern: EC2 instances, a Python application layer, Postgres, and manually managed game servers. Each zone in Pax Dei was mapped to its own Unreal Engine process, and servers were kept running regardless of player activity.
As the game world expanded, running always‑on servers for every zone became increasingly expensive. To address that, the team introduced containerization and built an internal orchestration system to manage zone lifecycles dynamically. The broader stack evolved in parallel — Python gave way to Rust and Go across most services, the team built Repli (a replication system spanning Unreal and the backend), introduced a messaging bus, and adopted Kubernetes as the orchestration substrate.
One of the key breakthroughs was aggressively reducing Unreal server startup times, making true on‑demand provisioning feasible. With startup latency measured in seconds rather than minutes, zones could be launched only when players entered them without compromising experience.
This significantly improved efficiency, but it didn’t fully solve the economic challenge.
As player activity became steadier, many zones ended up running continuously anyway. Each game server required multiple CPU cores and large amounts of RAM, and the cost structure of on‑demand cloud instances began to work against this kind of long‑lived, stateful workload.
As Arni Birgisson, Director of Cloud Services at Mainframe Industries, puts it, “Once game servers become stable and always running, you’re not really benefiting from cloud elasticity anymore.”
At that point, Mainframe began separating the problem by workload type. AWS still made sense for a large part of the stack — backend APIs, databases, S3, EFS — where managed services and elastic pricing fit the workload well. But game servers, which are large, stateful, and predictable, looked like a better fit for dedicated infrastructure.
Rather than abandoning cloud‑native tooling, the team doubled down on Kubernetes as the common abstraction layer. The goal was portability: game servers should run the same way everywhere, regardless of provider.
This requirement shaped the choice of i3D.net as a partner. Dedicated bare metal hardware could be provisioned with the specs the game required, while still allowing Mainframe to operate everything using the same Kubernetes‑based workflows they already had in AWS.
Beyond hardware and cost considerations, the collaboration itself played a key role. During design and implementation, i3D.net’s engineering team worked closely with Mainframe’s engineers, effectively acting as an extension of their internal team. Direct access to senior technical expertise, quick iteration cycles, and hands‑on support during rollout helped Mainframe move faster and avoid operational friction while bringing the hybrid architecture into production.
Talos Linux was chosen as the foundation for the i3D.net clusters due to its minimal, Kubernetes‑centric architecture, which aligns with Mainframe’s infrastructure‑as‑code model and minimizes operational surface area.
The rollout focused on keeping the system simple rather than hyper‑integrated. Build artifacts are centrally stored, game servers pull what they need at startup, and all communication with backend services happens over standard internet endpoints with strict access controls.
The orchestration layer itself is provider‑agnostic. It always prioritizes scheduling zones on dedicated infrastructure, but automatically scales into AWS when additional capacity is required or when operational conditions demand it.
This design has proven valuable not just in theory, but in production. During provider‑level incidents, Mainframe has been able to shift active game servers between environments with minimal disruption, simply by changing scheduling priorities.
Birgisson notes: “Being able to run on multiple providers, and dynamically shift workloads between them without re‑architecting, has become a core part of our resilience story.“
The most measurable outcome was cost. Moving game servers off on‑demand cloud instances reduced that part of Mainframe’s infrastructure spend by roughly two‑thirds.
But the architectural benefits went further. Decisions that previously caused internal tension, such as whether to launch a new world to improve player experience, became easier once the cost impact was predictable and manageable.
The hybrid model has delivered several practical advantages:
Performance was a deliberate focus during the i3D.net rollout. Benchmarking against the existing cloud baseline confirmed that the dedicated hardware met or exceeded it across the metrics that matter for gameplay.
With Kubernetes as the foundation, Mainframe now treats infrastructure as a spectrum rather than a single destination. Hyperscale cloud platforms remain the best option for certain services, while dedicated infrastructure better matches the behavior of game servers.
The team continues to explore where additional services might benefit from running closer to the game layer, while maintaining managed solutions where operational complexity outweighs cost savings.
The broader lesson, according to Birgisson, is about fit rather than ideology: “The question isn’t whether managed cloud services are good or bad. It’s whether the economics and operational model match the workload.”
For Pax Dei, answering that question led to a hybrid architecture that supports both the technical and creative ambitions of a long‑lived online world.
Explore how hybrid Kubernetes can unlock cloud flexibility with bare‑metal performance in our blog here.