The PingCore Window

What each section of the PingCore window in Unity does: Connect, Ship (Build, Push, Release), Status and Player hosting, plus the same build and push from the command line.

Window > PingCore connects a Unity project to one fleet in your workspace, builds and pushes its Linux dedicated game server, releases updates to running game servers, and shows what the fleet runs. This page describes each section. Run Beacon Rush on PingCore uses it from start to finish.

The window

Open Window > PingCore. The window is one scrolling page with four sections: Connect, Ship, Status and Player hosting.

Each section has a status chip (done, to do, ready, connect first, outside the plugin or off), one line saying where it stands, and "Next:" followed by the one thing to do, when there is one. Click a section's header to fold or unfold it.

Ship and Status read connect first until you are signed in with a fleet picked. When you come back to the window and its last read of the fleet is more than a minute old, it reads the fleet again, so a deployment added in the panel shows up without a click.

Screenshot: the PingCore window with Connect done, Ship ready and Status done.

Connect

Sign in

The plugin signs in with an API key. PingCore finds your workspace from the key, so there is no address to type.

  1. In the panel, open Settings > API Keys and click Create New Key.

  2. Set Key Type to Brand, name the key, and click Create Key.

    You should see the new key, starting usr_. It is shown once.

  3. In the PingCore window, paste the key into API key (usr_) under Connect. To keep it in memory only until the Editor quits, tick This session only.

  4. Click Sign in.

    You should see Verify and Sign out in place of the key field, and the line "No fleet is picked for this project yet. Next: Pick the fleet this project ships to."

A Brand key belongs to the workspace: your teammates can see and revoke it, and it stops working when its creator leaves the workspace. Every key acts with the brand permissions of the brand member who created it. The plugin advises: "Use a key of a brand member who holds only the brand permissions the plugin needs, not the workspace owner's key." Those permissions are:

  • fleets.view, my-games.view, my-games.templates and brand.servers.view to read the fleet, its game and its startup command;

  • cdn-sources.edit for Push to issue a push token;

  • fleets.manage for Release;

  • discovery.view for Player hosting.

Pick the fleet

  1. Open the Fleet list. Each entry shows the fleet, its game and its number of deployments, for example Beacon Rush (Beacon Rush (Unity Dev), 0 deployments) #12.

  2. Pick your fleet.

    You should see the Connect chip turn done with "This project ships to Beacon Rush.", and under the list a line such as "Beacon Rush (#12) runs Beacon Rush (Unity Dev); Discovery app dscp_xxxxxxxx; 0 deployments."

Picking a fleet writes the fleet's id and its game's id into ProjectSettings/PingCoreEditor.json, and the public id (dscp_) of the fleet's Discovery app into your PingCoreClientSettings asset. In SampleGame that asset is Assets/Client/Settings/PingCoreClientSettings.asset. A project with none gets Assets/PingCore/Resources/PingCoreClientSettings.asset.

When the workspace has no fleet, Connect reads "Set up your game and a fleet in the panel first." Click Open Fleets in the panel, add the fleet, then click Refresh.

A fleet with no deployment is picked like any other and Connect still reads done. Status reads "Your fleet has no deployment, so no game servers are running. Add one in the panel." Build and Push work without a deployment.

Refresh reads your fleets again. Open the fleet in the panel opens the fleet's page. Verify checks the stored key again, and Sign out deletes it (Signing out).

Ship

Ship has the Build profile and Build version fields, then three rows, Build, Push and Release, each with its own button. A row shows what it is doing while it runs, its result when it is done, or the reason and Retry when it fails. Only one row runs at a time.

When everything is in place, the chip reads ready with "Ready to ship to Beacon Rush." If the branch you push to gets its files from a container image or Steam, the chip reads outside the plugin: the plugin pushes to CDN sources only.

Build

  1. Check Build profile. It lists only build profiles for Linux with the Dedicated Server subtarget. In SampleGame, Assets/Settings/Build Profiles/Beacon Rush Server.asset is already picked.

  2. Check Build version. It defaults to today's date and your git commit, such as 2026.10.09-a1b2c3d (-local outside a git checkout). Default puts the default back.

  3. Click Build.

    You should see the row finish with "Built Builds/Server/2026.10.09-a1b2c3d."

Build names the executable after the process your game's startup command launches, and the line under the row says so: "The build writes BeaconRushServer.x86_64, the file your game launches (./BeaconRushServer.x86_64)." When your template sets launch more than one file, a Server executable list appears under the build profile and Build waits until you pick one.

Build runs your build profile as it is, with its own scenes, scripting backend and defines. It refuses to start in Play mode or while scripts compile, and it switches the Editor to the Linux server target for the build and back afterwards, which recompiles your scripts. The build guard checks every build.

Push

Push uploads a build folder to the CDN source of your game's branch. Neither Build nor Push needs a deployment.

  • Push to branch lists your game's branches with their platform and source, for example Main Branch (linux, CDN source #31). With one branch there is nothing to pick. The line under it reads "Pushes to CDN source #31.", or says why it cannot push. Open branch in panel opens the branch, where its data source is set.

  • What it sends. The last build, or a folder you pick with Choose folder.... The line starting "Push sends" gives the folder, its file count and size. Unity's do-not-ship folders are left out.

  • The startup-command check. Before uploading, Push reads your game's startup command again and refuses a build that does not hold the file it launches, for example "Your game launches ./BeaconRushServer.x86_64; this build has no such file."

Push needs the CDN source's push token (cdnpush_). The line above Use an existing push token says whether one is stored. There are two ways to get one:

  • Let Push issue it. On your first push a dialog, "Issue a push token?", warns that issuing a token replaces the current one at once, so any other copy stops working (in CI, a script or a teammate's Editor). Click Issue it, or Cancel to push nothing.

  • Use an existing one. If a teammate or CI already pushes to this source, paste their token into Use an existing push token and click Use token.

    You should see "The push token for CDN source #31 is checked and kept in your credential store (never shown). Push uses it."

Later pushes reuse the stored token. Replace push token... issues a new one only when you ask. See CDN Sources and Push Tokens.

To push:

  1. Click Push.

    You should see the row run with "Pushing" and the folder summary, then finish with "Pushed snapshot" and the name the CDN gave the new version.

Screenshot: the Ship section with Build and Push done.

Push runs the pingctl bundled in the Editor package after checking it against its pinned SHA-256. To run your own copy, set its path under Your own pingctl, or set the PINGCTL_BIN environment variable to it before you start Unity. Your own pingctl wins over the variable. Your own copy runs without the SHA-256 check, and the plugin never runs a pingctl it finds on your PATH.

Which build your game servers run

  • A new deployment installs the newest build you pushed. A first run needs no Release: push, then add the deployment in the panel. Push before you deploy; see Troubleshooting if you did not.

  • Until a release pins its deployment, a fleet game server takes the newest pushed build when it first boots and whenever it restarts or recycles. It never restarts on its own to fetch one.

  • Release pins the fleet's deployments to one build and moves their running game servers onto it.

  • A deployment added to the fleet after a release is not pinned. It installs the newest push, which may not be the released build.

Release

Release ships an update to game servers that are already running. It moves the fleet's deployments onto the snapshot your last push published, then follows the rollout.

  1. Push the update.

  2. Check the line under Release.

    You should see "Release moves fleet #12 onto snapshot, the snapshot your last push published."

  3. Click Release.

    You should see "Waiting for fleet 12's build targets to list snapshot." for up to 90 seconds, then "Release 5 to snapshot:" with the release's state and one line per location.

  4. Wait for the row to read "Release 5 of snapshot onto fleet 12 completed."

While a release runs, Stop stops watching it (the release carries on, and Continue watches it again), Cancel release cancels it, and Acknowledge dismisses a failed release. How a release moves through a fleet, and what happens to a match in progress, is on Shipping an Update.

With no deployment, the Release row is disabled with "Pushed builds wait in the CDN source. Add a deployment to the fleet in the panel to run one." and an Add a deployment in the panel button. Ship's next action then reads "Build, then Push. Release waits for a deployment; see Release below." Once the fleet has a deployment it reads "Build, then Push, then Release."

Status

Status shows what the fleet runs now. It is read only: deployments are added and scaled in the panel.

With no deployment it reads "Your fleet has no deployment, so no game servers are running. Add one in the panel." and offers Add a deployment in the panel, which opens the panel's deploy page for this fleet.

Otherwise it shows the fleet and when it was read, such as "Beacon Rush (active), read 14:02:11.", then one line per deployment with Open in panel:

EU West: active; 1 game server (1 ready, 0 in session, 0 draining); running 2026.10.09-a1b2c3d

The line ends with the build version the deployment's game servers report, or "no build reported yet". Refresh reads the fleet again.

Player hosting

Player hosting is only for games whose players host their own game servers (listen hosts). A game on a fleet does not need it. With nothing set it reads off and "Off: no community app is set, so player builds cannot host."

It shows:

  • Discovery apps (public ids, not secrets): the fleet app Connect wrote, and the Community app listen hosts register with. Change lists your workspace's open apps.

  • Community heartbeat token (listen hosts only): the Set token field, Clear and Confirm for build.

  • Build guard view of every configured token: what the build guard sees in each client settings asset.

Confirm for build has the steps, and Self-Hosted Game Servers and Listen Hosts explains when you need them.

Banners at the top

  • The Editor is on a dedicated server profile, for example "Your active build profile is Beacon Rush Server, a dedicated server profile, so client scenes cannot run in Play mode. Switch to a player profile in Build Profiles." Click Open Build Profiles and switch to a player profile. The plugin never switches it for you.

  • A settings file could not be read. The banner names the file.

Files the plugin writes

  • ProjectSettings/PingCoreEditor.json: the fleet and game ids, the branch Push pushes to, the build profile and the Server executable you picked.

  • UserSettings/PingCoreEditorUser.json: your own choices, such as your own pingctl, the folder Push sends and This session only.

  • Your PingCoreClientSettings asset: the Discovery app public ids.

Both settings files refuse anything that looks like a credential. Your key and push tokens go to your credential store (where they are kept).

From the command line

Scripts and CI can run the same build and push without the window.

Build the game server headless with the same code Build uses:

"<Unity editor>" -batchmode -nographics -quit -projectPath <path to SampleGame> -buildTarget Linux64 -standaloneBuildSubtarget Server -executeMethod PingCore.Editor.Cli.BuildServer.Run -buildProfile "Assets/Settings/Build Profiles/Beacon Rush Server.asset" -pingcoreProduct BeaconRushServer -pingcoreVersion 2026.10.09-1 -logFile build.log

The build lands in Builds/Server/2026.10.09-1/. -pingcoreProduct names the executable and must match the file your startup command launches. Without it the build takes the project's product name. Without -pingcoreVersion, the version is the UTC date and time. The command exits 0 when the build and the build guard both pass, 1 when either fails, and 2 when the arguments or the project are unusable.

Then push it with the pingctl bundled in the Editor package, with the push token in the environment, never on the command line:

PINGCORE_PUSH_TOKEN=<from your secret store> <pingctl> push Builds/Server/2026.10.09-1 --exclude BeaconRushServer_BurstDebugInformation_DoNotShip/ --exclude BeaconRushServer_BackUpThisFolder_ButDontShipItWithYourGame/

The bundled binary is in the Editor package under Tools~/pingctl/<os>-<arch>/. With the repository cloned, that is Packages/io.pingcore.editor/Tools~/pingctl/; with a git install, Library/PackageCache/io.pingcore.editor@<hash>/Tools~/pingctl/. The <os>-<arch> folders are windows-amd64, macos-arm64, macos-amd64 and linux-amd64.

Before you run it, check it the way Push does: its SHA-256 must equal binaries.<os>-<arch>.sha256 in Tools~/pingctl/manifest.json. Do not run it if they differ. Get the digest with sha256sum on Linux, shasum -a 256 on macOS, or Get-FileHash in PowerShell, which prints it in upper case. On macOS and Linux, also chmod +x it.

Uploading Game Files with pingctl covers its flags.

The same rule applies as in the window: a new deployment runs the newest push. To move running game servers onto it, use Start release on the fleet page in the panel, or the MCP tool create_fleet_release.