browser/platform/protocol/server-deployment.md

Server deployment lifecycle

deployment.plan.v1 gates only generic custom-command deployment execution: Platform sends a protected RunJobAssignmentResponse.executionInput.deployment when a server uses custom-command mode and Run executes the operator-reviewed argv-oriented command inside its local policy.

Guided or existing-server game setup is plugin-owned. Platform dispatches the plugin-declared lifecycle action reference, such as actions/install.json or a supervised actions/start.json bootstrap, and may include generic deployment context (mode, profileKey, serverRoot, and createInputs) so the plugin action can resolve its own behavior. Platform does not create a game-specific serverDeploymentPlan, and SCUM no longer requires a deployment.scum.v1 capability.

Capability and policy

Run advertises normal lifecycle capabilities (process.install, process.start, process.stop, process.status) and generic primitives such as scoped files, logs, artifacts, dependency helpers, and custom deployment plan execution. A Run that supports shell commands advertises its local shell policy out of band with operator configuration. Platform must not infer shell support from command text. Empty shell means argv-oriented execution.

Plugin-owned game lifecycle

Game plugins own concrete game policy: install/update commands, app ids, executable refs, default launch flags, stop-before-update behavior, and startup argument construction. For SCUM, the plugin action assets own the SteamCMD flow: stop SCUMServer.exe when updating, keep SteamCMD outside the server install root, run steamcmd.exe +force_install_dir <serverRoot> +login anonymous +app_update 3792580 +quit, and start <serverRoot>\\SCUM\\Binaries\\Win64\\SCUMServer.exe -port=<gamePort> -MaxPlayers=<maxPlayers> -log.

Generated Run distributions carry validated plugin lifecycle assets into the server-scoped workspace. Run materializes those assets at startup and executes them through generic action template handling; it does not branch on game ids, Steam app ids, SCUM executable paths, or launch flags.

Required local preflight

Before a custom-command action, Run validates the selected protected deployment body:

• absolute server root and working directory are allowed only where permitted by local Run policy;
• selected shell kind and custom-command policy are enabled;
• no raw command, path, secret, socket address, or credential is emitted in a result, diagnostic, log batch, or artifact name.

For plugin-owned actions, Run validates scoped action template paths, executable asset refs, bounded environment variables, and lifecycle action/capability matches. Deployment create inputs may be exposed to the action as bounded environment variables such as SERVER_CREATE_GAMEPORT; protected command text is not exposed unless the server explicitly uses custom-command mode.

Safe progress reports

Run reports bounded progress with percent, phase, and a safe message. The allowed phase vocabulary is queued, claimed, preflight, scan, install, configure, mapping, start, and health. On failure it reports a stable safe error code and summary, never the supplied path or command text.

Platform treats Run preflight as authoritative. It does not open a direct shell, SSH connection, raw socket, or host filesystem to compensate for a failed preflight.