How PingCore Runs Your Servers

PingCore provides the base images, the supervisor that runs inside them, and the Kubernetes clusters they schedule onto. This spans multiple operating systems and geographic regions, and it's ready to go the moment you import a game.

This page explains what sits between your game binary and the player connecting to it.

Base images

PingCore maintains two families of official base images:

Windows: based on mcr.microsoft.com/windows/servercore, for games that require the Windows runtime. This covers most AAA dedicated servers, titles built with Unreal, and anything using DirectX-era native libraries.
Linux: minimal Linux base, for games that ship Linux binaries or run cross-platform.

Both images come with the PingCore supervisor preinstalled and tuned for gameserver workloads. We recommend using them as your starting point because they're heavily optimised and save you from building the supervisor integration yourself.

You can bring your own image if you need to. Custom images need to include a supervisor-compatible entrypoint so PingCore can manage the server's lifecycle. If you have a use case our base images don't cover, contact support and we'll help you get set up.

The PingCore supervisor

Every base image ships with the PingCore supervisor running as PID 1 inside the container. It's a small Node.js process that acts as the entrypoint and runs for the entire lifetime of the server.

The supervisor handles:

First-boot game file sync: pulls the game from the configured CDN source before the game starts.
Config file generation: fetches the runtime config from the PingCore API and writes rendered template files to disk (server config, startup scripts, world files, anything your template set defines).
CLI argument resolution: resolves template fields into the actual command-line arguments used to launch the game binary.
Game process supervision: spawns your game server as a foreground child, streams stdout and stderr, forwards SIGTERM and SIGINT, and exits with the game's exit code.
File access: runs an SFTP server so you can connect to the server's files with any SFTP client.
Control API: an in-container HTTP API on port 8080 the web panel uses to read logs, send console commands, restart the server, and manage its lifecycle.

You never write or maintain the supervisor. It just runs.

What the supervisor does at startup

On every pod boot:

Fetch the runtime config from the PingCore API using the pod's per-server auth token
Write every rendered config file to its configured path
Resolve CLI arguments using template field values and port allocations
Start the SFTP server in the background
Start the control API in the background
Exec the game server binary as the foreground process
Stream logs and forward signals until the game exits

The game sees a fully-prepared filesystem and a ready-to-use command line. It does not need any awareness of Kubernetes, PingCore, or the supervisor.

Health checks and lifecycle

The supervisor and the control API give PingCore enough visibility to:

Detect crashed or hung game processes and restart pods automatically
Report live status to the panel (running, stopped, starting, unhealthy)
Respond to panel-triggered actions such as restart, stop, start, reinstall, and send console command
Stream live console output and log file tails to connected browser clients

You get this behaviour for free on every server, regardless of the game.

Windows and Linux

Every location offers both Windows and Linux node pools. A single brand can run Windows-based games and Linux-based games side by side in the same workspace, in any location, billed on the same account.

How the platform keeps them apart:

Each deployment spec has a kubernetes.io/os node selector auto-set from the main container's platform (windows or linux)
Pods schedule only onto nodes matching their OS
Persistent Volume Claims use the corresponding storage class for that OS
Ephemeral volumes work identically on both

You pick the OS at the container level when you configure a game. Everything downstream (scheduling, storage, networking) follows from that choice.

When to choose which

Windows: required for Windows-only game servers, including many official dedicated servers for UE4/UE5 titles and games using Windows-specific APIs.
Linux: preferred for anything that ships a Linux binary. Smaller base image (~150MB vs ~400MB for Windows), faster pod startup, and lower per-server overhead.

If a game ships both Windows and Linux dedicated servers, use Linux. It's cheaper to run and spins up faster.

Global locations

PingCore operates clusters across 10+ geographic locations spanning the Americas, Europe, Asia, and Oceania. Each location is a self-contained Kubernetes cluster connected to the central platform.

Locations are exposed through the deploy form at Games > Deployments > Deploy Servers. When you select a location, PingCore:

Provisions the pod on a node in that cluster
Allocates network ports from that cluster's public IP pool
Returns the connection address (region-specific public IP plus allocated ports)

Every location supports both Windows and Linux node pools, so the OS choice does not restrict which regions you can deploy to.

Picking a location

Deploy to the region closest to your player base. For games with players spread across continents, create multiple deployments (one per region) and route players via your matchmaker or server browser.

What you still control

The managed runtime handles the plumbing. You still control everything that makes your game yours:

Which image to use (Windows or Linux variant, or a custom image if you've brought your own)
CPU and memory limits per container
Environment variables, static or template-driven
Config file templates and their fields
Persistent and ephemeral storage
Port layout and protocol (TCP, UDP, TCPUDP)
Which region to deploy to, and how many instances