Baked-In Game Files | Pingcore Docs

Baked into container image is one of the branch data sources, alongside CDN Source and Depot Downloader (Steam). With it selected, the game files ship inside your container image and the supervisor installs them from there instead of downloading anything.

Set it under Workspace > Games, open the game, Branches, edit the branch, Data Configuration, Data Source. There is nothing else to fill in. The platform does not know where you put the files in your Dockerfile, so the location comes from the image: GAME_IMAGE_ROOT, which defaults to /opt/game on Linux and C:\game on Windows.

How it compares to the other sources

CDN Source fetches a snapshot from the PingCore CDN at boot. Files change without rebuilding an image, and servers pick up the new snapshot on their next start.
Depot Downloader (Steam) installs anonymously from Steam at boot, for builds you already publish there.
Baked into container image has no network step and no credentials anywhere. Shipping a new build means pushing a new image tag.

A branch has exactly one data source. When a payload somehow carries more than one, a fetched source wins over the baked-in one, because the image always physically has files whether or not the branch is configured to use them.

When the copy runs

The supervisor copies the image tree onto the server's data volume in four cases:

First boot of that volume, always.
Reinstall, which wipes the gameserver directory first, so the copy lands in an empty tree.
A boot on a volume with no recorded install. This is what happens when you switch an existing branch from CDN Source or Depot Downloader (Steam) to Baked into container image: the volume holds files from the old source, so the next boot installs from the image.
Any boot where the image's .version differs from the version recorded on that volume. The comparison is inequality, so an older build triggers a copy the same way a newer one does.

If the image ships no .version and no GAME_IMAGE_VERSION, the content is unversioned. Unversioned content installs on first boot and on reinstall only, because there is no way to tell one image's files from another's and recopying every boot would wipe out whatever the player changed.

The recorded version lives on the volume, not in the image, so two servers on the same branch can be at different versions until each one restarts.

What the copy does to existing files

The copy is additive. It never deletes.

A file that exists in both places is overwritten from the image.
A file that exists only on the volume is left alone. Saves, logs, player-edited config and uploaded mods survive an update.
A file you removed from the image stays on the volume until a reinstall.
The .version marker itself is not copied. It describes the image, and the version is recorded separately.
Relative symlinks inside the tree are kept as they are, so they re-resolve on the volume. A symlink with an absolute target, or one whose target escapes the image root, is skipped and named in the log.

Reinstall is the way to get an exact mirror of the image, because it empties the directory before the copy.

The `.version` file

One line, at the root of the image content tree, holding an opaque build id. Only the first non-empty line is read, and surrounding whitespace is trimmed.

If your build cannot write a file into the image, set GAME_IMAGE_VERSION with ENV instead. The file wins when both exist.

Sizing a persistent volume

Create the PVC under the game's PVCs tab, with PVC Name set to Data and Storage Size large enough for the installed game plus saves and logs. Mount it on the main container at the data path. The supervisor installs into PVC_DATA/server, so a 20Gi game needs more than 20Gi of volume.

Running without a persistent volume

An ephemeral data volume suits fleets that keep nothing between sessions. The setup is three steps.

Under Workspace > Games, open the game, go to Ephemeral Volumes and click Add Ephemeral Volume. Set Volume Name to data, leave Storage Medium on Disk (default), and set Size Limit to at least the installed size of the game.
Go to Containers, open the main container, and on Volume Mounts click Add Mount. Set Volume Type to Ephemeral (Temporary), pick the data volume, and set Mount Path to the same path a PVC would use, for example /gameserver.
Do not also mount a data PVC on that container. One volume goes at the data path.

The supervisor sees PVC_DATA either way and copies into PVC_DATA/server. The data source does not depend on which kind of volume is behind that path.

On an ephemeral volume:

Size Limit is not optional here. A copy larger than the limit gets the pod evicted part way through the install.
The limit is added to the server's ephemeral-storage bound: a 4Gi baseline plus the size limits of the disk-backed ephemeral volumes mounted by any container in the pod, emitted on the main container. A Memory (tmpfs) volume is charged to memory instead and adds nothing to that bound, which also makes it the wrong medium for game files.