Choosing How Game Files Reach Your Servers

The four combinations of content model and storage model, and what each one costs in boot time, disk, and update effort.

Two settings decide how a game server gets its files: the branch Data Source and the kind of volume mounted at the data path. This page compares the four combinations.

Content models

Set this on the branch, under Workspace > Games, open the game, Branches, edit the branch, Data Configuration, Data Source.

  • CDN Source or Depot Downloader (Steam): servers run a PingCore base image and the supervisor downloads the files at boot. See Delivering Your Game Files.

  • Baked into container image: you build an image that carries the game at GAME_IMAGE_ROOT (/opt/game on Linux, C:\game on Windows), and the supervisor copies that tree onto the data volume. See Baked-In Game Files.

A bring-your-own image still has to contain the PingCore supervisor. The platform pins every main container's command to it and ignores the image's own ENTRYPOINT and CMD. Read Building Your Own Server Image before you plan around a custom image.

Storage models

Both models exist per game, under the game's PVCs and Ephemeral Volumes tabs, and are attached to a container on its Volume Mounts tab.

  • PVC (Persistent): a volume that survives pod re-creation. Saves, logs and player-edited config stay across restarts, migrations and node maintenance.

  • Ephemeral (Temporary): an emptyDir that lives and dies with the pod. Everything on it is gone when the pod is replaced.

Whichever you mount at the data path, the supervisor sees it as PVC_DATA and installs the game into PVC_DATA/server. Setting up an ephemeral volume as the data volume takes three steps, described in Baked-In Game Files.

CDN or Depot Downloader on a persistent volume

This is the default for a long-lived rented server.

  • First boot: one full download, so minutes for a multi-GB build.

  • Scale-up: a new server is a new volume, so it pays the full download again.

  • Saves: on the PVC, kept across restarts and pod moves.

  • Updates: publish a new snapshot or Steam build. Servers pick it up on their next boot, or immediately on servers that have Auto Update enabled on the server's Overview.

  • Disk: one copy per server on the storage backend. The node holds the base image once.

  • Size: the PVC's Storage Size, at least the installed game plus saves and logs.

CDN or Depot Downloader on an ephemeral volume

This combination is cheap to keep and slow to start.

  • First boot: one full download.

  • Scale-up: every pod re-creation downloads the whole game again, including restarts, migrations and crash recovery.

  • Saves: gone with the pod. Only use it for stateless match servers.

  • Updates: automatic, because every new pod fetches the current snapshot.

  • Disk: node disk, charged against the pod's ephemeral-storage budget, released when the pod ends.

  • Size: the ephemeral volume's Size Limit, at least the installed game size. The platform adds that limit to the server's ephemeral-storage bound.

Baked into the image on a persistent volume

This is the fastest steady state for a studio that ships its own builds.

  • First boot: a local copy out of the image layer, no network fetch. The image pull itself still happens once per node and can take minutes when it is cold.

  • Scale-up: fast on a node that already has the image, because only the copy runs.

  • Saves: on the PVC.

  • Updates: push a new image tag, change the tag on the image row, and restart the deployment. The copy re-runs only when the image's .version differs from the one recorded on that volume.

  • Disk: the image once per node, plus one full copy per server on the storage backend.

  • Size: the PVC's Storage Size, at least the installed game plus saves and logs.

Baked into the image on an ephemeral volume

This suits fleets that scale up often and keep nothing between sessions.

  • First boot: a local copy, no network fetch.

  • Scale-up: the fastest of the four on a warm node.

  • Saves: gone with the pod.

  • Updates: push a new tag and roll the deployment. Every new pod copies from the image it was pulled with.

  • Disk: the image once per node, plus one full copy per server on node disk. The copy doubles the game's footprint on that node, because the image layer and the copy both exist.

  • Size: the ephemeral volume's Size Limit, at least the installed game size.

Disk cost

Image layers live in the node's image store and do not count against a server's ephemeral-storage bound. The copy does. So a 20Gi game on an ephemeral data volume costs the node 20Gi for the image plus 20Gi per server running there, and the server's own bound has to be large enough for its copy or Kubernetes evicts the pod part way through the install.

An in-place mode, where the game runs straight from the image root with no copy, would remove that duplication. In-place mode does not exist today, so size for the copy.

Where to go next