Delivering Your Game Files
How game studios get their dedicated server build onto the platform using CDN sources - Steam, automated pipelines, or manual SFTP upload.
You build your game in Unity, Unreal, or your own engine. The platform then runs your dedicated server build as game servers in the cloud. This page covers the step in between: getting your server files onto the platform so they can be deployed.
You do this by creating a CDN source. A source defines where your server files come from and how they stay up to date. The platform pulls or receives your files, packages them into versioned snapshots, and serves the latest snapshot to every game server when it boots.
How file delivery works
The path from your build to a running game server is the same no matter which delivery method you pick:
You create a CDN source that describes where your files come from (Steam, a download pipeline, or a manual upload).
The platform processes the source in an isolated container and collects the resulting files.
The files become an immutable snapshot, a timestamped and versioned copy. Every change produces a new snapshot.
You link the source to a game branch so the platform knows which files that branch should run.
Game servers pull the latest snapshot at boot. When you publish new files, servers pick them up on their next start.
You build the source once. From then on, updating your game means updating the source, either by pushing a new build or by triggering a re-sync.
Three ways to deliver files
Studios work differently, so the platform supports three delivery methods. You choose one per source.
SteamCMD: your server build is published on Steam (a public or owned app, optionally a beta branch) and the platform downloads it directly. Best if you already ship your dedicated server through Steam.
Pipeline: your build artifacts live somewhere reachable by URL, such as your CI, an object store, or a release server. You define ordered steps to download, extract, and assemble the files. Best for custom build outputs and CI/CD workflows.
Manual: you upload files yourself over SFTP. The platform does no downloading and only snapshots what you put there. Best when your build process is bespoke or you want full control.
You can mix methods across sources. A studio might use SteamCMD for one game and a Pipeline for another.
Before you start
You need to be a brand member with the right CDN permissions. Creating sources requires
cdn-sources.add, and viewing them requirescdn-sources.view. The Permissions reference section below lists them all.Provide your dedicated server files, not the client build. Game servers run headless.
Know which platform your server targets, Windows or Linux. It must match the branch the source will feed.
Step 1: Create a category
Sources are organized into categories. A category is a folder that groups related sources, such as all branches of one game.
Go to Workspace > Games > CDN Sources.
Under My Categories, click Add Category.
Fill in the Create CDN Category form:
Name: the display name, for example
DayZ Servers.Folder Name: used in the CDN path. Lowercase letters, numbers, and hyphens only. This cannot be changed later.
Description: optional.
Click Create Category.
Your content lives at a path built from your brand, the category folder, and the source folder:
{brandId}/{categoryFolderName}/{sourceFolderName}Folder names are permanent, so pick them carefully. They cannot be reused even after a category or source is deleted.
Step 2: Add a source
Open the category and click Add Source.
Fill in the basics:
Name: display name, for example
Main Branch.Folder Name: the final path segment. Permanent once created.
Description: optional.
Download Method: SteamCMD, Pipeline, or Manual.
Platform: Windows or Linux.
Active: when active, the platform processes the source periodically. When inactive, the platform ignores it and serves whatever snapshot already exists. Leave a source inactive while you stage files, then activate it.
Complete the method-specific configuration described below.
Click Create Source.
The rest of this section covers each method in detail.
Method A: SteamCMD
Use this when your dedicated server is distributed through Steam.
In the SteamCMD Configuration section:
Steam App ID: the numeric app ID of your dedicated server, for example
223350.Requires Steam Login: enable this only if the app is not available anonymously, such as an owned or restricted app. Most public dedicated servers download anonymously.
Steam Credential: when login is required, select a stored Steam credential. If you have none, add one first (see the Steam credentials section below).
Steam Beta Branch: optional. The name of a Steam beta branch, for example
experimental.Beta Password: optional, if the beta branch is password-protected.
The platform runs SteamCMD in an isolated container, installs your app into the source's storage, and only downloads changed files on later runs (delta updates). Steam's internal manifest files are left out of the published snapshot automatically.
Use a dedicated Steam account for downloads, and make sure it does not have Steam Guard two-factor enabled. SteamCMD cannot complete an interactive 2FA prompt during a download.
Method B: Pipeline
Use this when your build lives outside Steam, such as a CI artifact server, an object store, or any HTTP download.
A pipeline is an ordered list of steps that run in an isolated container. You build it in the Pipeline Configuration section, which has two modes:
Visual: add and reorder steps with a form-based editor.
JSON: edit the raw step definition directly.
Pipeline variables
Steps reference three working locations. Use these variables instead of hard-coded paths:
%TEMP_DIR%: ephemeral scratch space for downloads and intermediate files.%WORK_DIR%: your working directory. Anything you place here is published to the CDN, so assemble your final server files here.%USER_DATA%: a persistent folder for custom tools or installers you upload via SFTP. It is read-only during the pipeline.
The pipeline's job is to finish with your completed server files sitting in %WORK_DIR%. That is what becomes the snapshot.
Step types
Download: fetch a file from a URL to a path, typically into
%TEMP_DIR%.Extract: unpack an archive. Supports
zip,tar, and7z, or auto-detect by extension.Execute: run a command, with optional arguments and working directory. Use this for build or assembly tools.
Move: move files or folders from one path to another.
Copy: copy files or folders, leaving the originals in place.
Delete: remove files or folders you do not want published.
SteamCMD: run a Steam download as one step of a larger pipeline, for example to fetch a base game from Steam and then overlay custom files.
Example pipeline
Download a server build from your release server and extract it into the published output:
{
"steps": [
{
"action": "download",
"url": "https://builds.yourstudio.com/server/latest.zip",
"to": "%TEMP_DIR%/server.zip"
},
{
"action": "extract",
"source": "%TEMP_DIR%/server.zip",
"to": "%WORK_DIR%",
"format": "zip"
}
]
}When the pipeline finishes, everything in %WORK_DIR% is captured as the new snapshot.
Method C: Manual (SFTP)
Use this when you want to push files yourself and skip automated downloading.
Manual Mode: files must be uploaded manually to the CDN server. The platform only manages snapshots of the files you upload.
To upload files:
Create the source with Download Method set to Manual.
Open the source and go to its CDN View.
In the SFTP Access card, click Create SFTP User.
The panel shows your Username, Port, and Path, along with a password that is shown only once. Save it immediately, because it is not displayed again.
Connect with any SFTP client and upload your server files into the source's
datafolder. The platform snapshots whatever is indata.
SFTP is also available on SteamCMD and Pipeline sources, where it serves a different purpose. Drop custom tools or installers into the user_data folder so your pipeline can read them through %USER_DATA%.
To revoke access, use Delete SFTP User on the same card.
Snapshots and versioning
Each time a source is processed and the files have changed, the platform creates a new snapshot: an immutable, timestamped copy such as snapshot_20260602_143052. This is what game servers download.
Snapshots are content-addressed. If nothing changed since the last run, no new snapshot is created.
A small number of recent snapshots are kept so deployments stay consistent during a rollout.
Game servers always pull the latest snapshot at boot. Servers already running are unaffected until they restart.
Step 3: Connect a source to a game branch
A source does nothing until a game branch points at it. The branch is what your customers' servers actually run.
Go to Workspace > Games, open your game, and edit the branch.
In the Data Configuration card, set Data Source to CDN Source.
Choose your source from the picker. It lists your own categories along with any Public Sources (Marketplace) you are allowed to use.
Save the branch.
If you set Data Source to None, the branch starts servers with no pre-installed files. You would then install files another way, such as a setup script at server boot.
Multiple branches can point at the same CDN source. This helps when several variants of a game share the same base files.
Updating your game files
How you ship an update depends on the delivery method:
SteamCMD: publish your new build to Steam. The platform picks it up on its next scheduled check.
Pipeline: publish a new artifact at the URL your pipeline downloads from. The next run fetches it.
Manual: upload the new files over SFTP.
To apply an update right away instead of waiting for the next scheduled check, open the source's CDN View and click Force Update (requires cdn-sources.force-update). This triggers an immediate re-process, and if the files changed, a new snapshot.
Monitoring a source
The source's CDN View shows the state of delivery:
CDN Status: current status (
OK,Error,Processing,Pending), the current version, and when it was last checked and updated.Snapshots: the snapshots currently stored, with their sizes.
CDN Distribution: whether the latest snapshot has propagated to the platform's distribution nodes.
Logs: the download and processing logs, filterable by date and level (requires
cdn-sources.logs). Check these first when a source shows an error.
Sharing a source publicly
You can publish a source to the marketplace so other brands can use it as the data source for their own branches. This is optional and off by default.
From the category view, toggle a source to Public (requires
cdn-sources.set-public).Public sources expose only safe metadata. Your credentials, pipeline definition, and access token are never shared.
Other brands can then select your source under Public Sources (Marketplace) when configuring a branch.
Permissions reference
CDN source actions are gated by these brand permissions:
cdn-sources.view: view categories and sources.cdn-sources.add: create categories and sources.cdn-sources.edit: modify categories and sources, and manage SFTP users.cdn-sources.delete: remove categories and sources.cdn-sources.set-public: toggle a source's marketplace visibility.cdn-sources.force-update: trigger an immediate re-sync.cdn-sources.logs: view download and processing logs.
A brand owner has every permission their brand has enabled. Other members need each one granted to them individually.
Steam credentials
For SteamCMD sources that require login, store your Steam account separately:
Go to Credentials in the panel and add a new credential.
Choose the Steam type.
Fill in a Name, Steam Username, and Steam Password.
The credential is stored encrypted and can then be selected on any SteamCMD source. Use a dedicated Steam account for downloads rather than a personal one.
Choosing a method
Already ship your dedicated server through Steam? Use SteamCMD.
Have a CI pipeline that produces a downloadable artifact? Use a Pipeline.
Push files by hand, or have a one-off build process? Use Manual.
If you are not sure, start with Manual to get files flowing, then automate with SteamCMD or a Pipeline once your build process settles.