CDN Sources

Three ways to get your game files onto PingCore: upload directly to our CDN, pull from Steam, or build a custom ingest pipeline.

A CDN source is where PingCore pulls a game's files from at first boot. Every branch on a game links to a CDN source. When a pod starts, the supervisor syncs files from the source into the container before launching the game.

Manage sources at Games > CDN Sources (/cdnsources).

Structure

CDN Sources are organised in two levels:

  • Category: a top-level grouping for a game or game family (for example "Counter-Strike 2", "Minecraft Java")

  • Source: a specific variant inside a category (for example "Main", "Experimental", "Linux build")

A game branch references a single source. You typically have one category per game and one source per branch you ship.

Three ways to get files in

Every source picks one Download Method. PingCore gives you three options so you can choose whichever fits your release process.

1. Upload directly to the CDN (Manual)

You push your game files straight into PingCore's CDN. Use this when you build your own server binaries, don't ship through Steam, or want full control over what gets deployed.

Flow:

  1. Create a source with Download Method = Manual

  2. On the source detail page, click Create SFTP User

  3. PingCore generates a username, port, path, and one-time password

  4. Connect with any SFTP client and upload your files

  5. Commit the upload as a snapshot so new deployments pick it up

Good fit for:

  • Custom-built game servers compiled in-house

  • Games not published on Steam

  • Private or pre-release builds

  • Anything where you control the file layout end to end

2. Pull from Steam (SteamCMD)

PingCore pulls the game files directly from Steam using the official SteamCMD tooling. Point the source at a Steam App ID and we handle the rest, including beta branches and authenticated downloads for restricted apps.

Configure:

  • Steam App ID: the numeric ID of the dedicated server (for example 223350 for Source SDK Base)

  • Steam Beta Branch: optional, for non-public builds

  • Beta Password: optional, for password-gated betas

  • Requires Steam Login: tick if the app isn't anonymously downloadable, then select a stored Steam credential to authenticate with

Good fit for:

  • Any game that publishes a dedicated server on Steam

  • Studios who already ship through Steam and want zero additional workflow

  • Testing against Steam beta branches without setting up parallel infrastructure

3. Build a custom pipeline (Pipeline)

For anything that doesn't fit the two models above, compose a pipeline of ingest steps. Each step runs in order and has access to three working directories: %TEMP_DIR% for scratch, %WORK_DIR% for the final output CDN syncs, and %USER_DATA% for persistent files you've uploaded via SFTP.

Available step types:

  • Download: fetch a URL to disk

  • SteamCMD: pull from Steam (can combine with non-Steam steps in the same pipeline)

  • Extract: unpack a zip, tar, tar.gz, or 7z archive

  • Execute: run a command with arguments

  • Move / Copy: shuffle files between directories

  • Delete: clean up intermediate files

Build pipelines visually with the drag-and-drop editor, or drop into JSON mode for full control.

Good fit for:

  • Games that need custom patches applied before deployment

  • Multi-source builds (base game from Steam, mods from SFTP, config from a URL)

  • Anything that needs a post-download setup step

Why route through the CDN at all

If your game is on Steam, you could theoretically have every server pull from Steam on every boot. PingCore's CDN sits in between for four reasons:

  • Speed: game files are cached regionally once, not re-downloaded from Steam per server. Pod startup is measured in seconds, not minutes.

  • Reliability: your servers don't depend on Steam's availability at boot time. A Steam outage doesn't stop your deployments.

  • Configuration you can't apply at the source: extract archives, drop in modified config files, run setup scripts, apply patches, layer mods, restructure directories. All of this happens once, in the CDN, not on every individual server.

  • Version pinning: snapshots let you lock a deployment to a known-good build even after the upstream source updates. Roll forward when you're ready, not when Valve pushes a patch.

For studios using Manual uploads, the CDN is simply the drop target. Your build pipeline pushes here and deployments consume from here, without you standing up any infrastructure of your own.

Snapshots and updates

A source has a current version that reflects what's live. When you re-run a download (either manually via Force Update or on the source's schedule), PingCore creates a new snapshot. Deployments pick up the newest snapshot by default, but you can pin a branch to a specific snapshot if you need to hold back from a rolling update.

Manage this on the source detail page under CDN Status.

Public sources

Mark a source as public to let other brands reference it directly. Public sources show up in the CDN Sources list for every brand on the platform, alongside a brand's own categories.

Imported cores that reference public sources work out of the box in the importing brand's workspace. Private sources cause a partial-import warning: the importing brand keeps the game and branch but has to wire up a data source of their own.

Requires the cdn-sources.set-public permission.

Permissions

  • cdn-sources.view: see categories and sources

  • cdn-sources.add: create categories and sources

  • cdn-sources.edit: modify existing sources, manage SFTP, manage pipelines

  • cdn-sources.delete: remove categories and sources

  • cdn-sources.set-public: toggle public visibility

  • cdn-sources.force-update: trigger an immediate sync outside the schedule

  • cdn-sources.logs: view download and sync logs

Brand owners have all of these automatically.