Dedicated game servers: deployment, observability and handover checklist

The short answer

A dedicated game server is operable when the people who will run it can build, deploy, configure, observe, roll back and recover it without the developer who wrote it. Until that is true, the server is a working program, not a service.

That definition is useful near release or before LiveOps because it turns a vague feeling ("it runs on staging, we should be fine") into evidence you can check. Each area below asks for something concrete: a pipeline, a document, a dashboard, a rehearsed procedure. If the evidence is missing, the area is not done, however well the server performs in playtests.

This article walks through those areas in the order they usually break, then collects them into one checklist table with an owner and a "done when" condition for each line.

Two owners, one boundary

Most handover problems are ownership problems. Two roles are involved, even when the same company fills both:

• The game developer owns what runs inside the process: the headless server build, its start-up contract, the game-specific health signals, logs and metrics, version compatibility and how a match behaves when something fails.
• The infrastructure operator owns where and how the process runs: hosting accounts, regions, hosts or clusters, the container registry, secrets, log and metric pipelines, alert routing, capacity and budget, and who is on call.

The boundary between them is a contract: how the server is started, which configuration it expects, which signals it emits, how it must be stopped and what "healthy" means. Write that contract down early. Most of the checklist is a test of whether both sides have kept their part of it.

1. A reproducible build

Everything else depends on being able to produce the exact server you intend to run. In practice that means:

• The headless server is built by an automated job from a tagged commit, not exported from someone's editor.
• Engine version, packages and build settings are pinned, so the same tag produces the same result next month.
• Every build carries a build ID (version, commit, build number) that the server prints at start-up and attaches to its logs.
• Server-only code paths and stripped assets are tested in this build, not assumed from the client.

The typical failure is quiet: a server that only builds on one machine, or a hotfix that cannot be reproduced because nobody knows which local change went into it.

2. Deployment

Deployment should be a repeatable action, not a session of manual commands on a server. For containerized servers, the image definition lives in the repository, the image is tagged with the build ID, and staging and production are deployed by the same mechanism with different inputs.

The game developer is responsible for an image that starts cleanly from documented inputs. The operator is responsible for the registry, the deployment platform and access to it. A good test of this boundary: can the operator deploy a new build to staging using only the documentation?

3. Configuration

Configuration is where "works on staging" most often fails in production. List every setting the server reads: ports, region or environment names, backend endpoints, match rules, tick or simulation settings, log level, credentials. For each one, record the default, the value per environment, whether it is a secret, and who may change it.

Two behaviors make configuration safe. The server validates its configuration at start-up and refuses to start with a clear log message when something is missing or invalid. And secrets come from the operator's secret store, never from the image or the repository.

4. Regions and capacity assumptions

This is the area where teams are most tempted to quote a number. Resist it until the number has evidence. Capacity depends on the game simulation, the hosting model, the hardware and how players actually behave, so a figure from a different game, or from a quiet playtest, tells you very little.

Instead of a number, maintain a short assumption register. Each entry states:

• the assumption (for example: players per match, matches per host, memory and CPU per match, target regions, expected peak hours),
• its basis: measured (link the test and build ID), estimated (state the reasoning) or unknown,
• the date and the build it applies to,
• the owner and the test that will replace it with a measurement.

Cost follows the same rule: document the cost drivers (instance or host type, regions, idle capacity, egress, log and metric retention) and which assumptions they depend on, rather than a single monthly figure that nobody can trace. The game developer measures what one match costs in resources; the operator turns that into host sizing, quotas and a budget.

5. Logs, metrics and crash observability

A player reports a disconnect at 21:40 on a Saturday. Can the operator find that match, read its server log and see what the process was doing? That scenario is a better test than any dashboard screenshot.

• Logs are structured and carry the build ID, server or match ID and region on every line. Retention and access are defined.
• Metrics cover the process (CPU, memory, restarts) and the game (server frame or tick time, players connected, match state, connection failures). The game developer defines which game metrics matter; the operator owns collection, storage and alert routing.
• Crashes produce a captured report or dump, and the debug symbols for every released build are stored so the report can be read later. Restart policy is explicit, so a crash loop is visible instead of silently consuming capacity.
• Alerts start with conservative, documented initial thresholds and each one links to a runbook entry. An alert nobody knows how to act on is noise.

6. Versioning

Client, server, network protocol and content versions must have a defined compatibility rule. The session or matchmaking flow should only send a client to a server it can talk to, and a mismatched client should receive a defined message rather than a timeout. Write the rule down: which version changes require a coordinated client and server release, and which can ship independently.

7. Rollout and rollback

Dedicated servers host live matches, so "deploy a new version" is never just a restart. Decide and document:

• whether new matches start on the new version while existing matches finish on the old one (draining), and how long draining may take;
• how the server reacts to a termination signal: stop accepting players, finish or end the match cleanly, flush logs, exit within the grace period;
• how to roll back: the previous image is kept, the procedure is written, and it has been rehearsed in staging;
• who decides to roll back, and based on which signals.

The game developer defines the compatibility constraints and shutdown behavior; the operator executes rollouts and rollbacks.

8. Failure scenarios

List the failures you expect and the behavior you want for each. A short table is enough: scenario, player-facing behavior, detection signal, runbook step. Typical entries include a server crash mid-match, the loss of a host, a region becoming unavailable, a backend dependency (sessions, authentication, persistence) going down, a bad configuration value, and running out of capacity during a peak.

You will not rehearse all of them before release. Rehearse the few with the highest impact, and make sure the rest at least have a detection signal and an owner.

9. Ownership and runbook

The runbook is the handover. It contains the architecture overview, the deployment, rollback and scaling procedures, the configuration reference, the dashboards and what normal looks like on them, the failure-scenario table, the assumption register, known limits, the cost drivers and the escalation path, including what happens outside working hours.

Ongoing operation after handover is a separate decision. If the developer stays involved, the scope and response expectations are agreed explicitly. If not, the operator must be able to work from the runbook alone.

The handover checklist

Use this table in the release or LiveOps readiness review. "Developer" means the team that owns the server code and build; "Operator" means the team that owns hosting and day-to-day operation.

What we draw on

Our own reference is Bad Goons, Sourcegarden Studio's current original IP, which is in active development. It runs Unity headless builds on authoritative Linux dedicated servers with containerized deployment, and capacity, shutdown, health, logs and version rollout are treated as game-facing concerns rather than as someone else's infrastructure problem. Bad Goons is designed for 64-player matches; that is a design target, not a measured capacity, which is exactly why this article recommends an assumption register over a headline number.

The checklist is general professional guidance built from that work. It is not a claim that every item has been exercised against live player traffic.

Where this fits in the project

The checklist is the end of a process that starts much earlier. If the boundaries between the realtime match and the services around it are still unclear, start with the network model on the multiplayer development side, and with what to define before you ask for a game backend estimate. The cheapest moment to agree ownership is before the first deployment, not the week before launch.

If your server already runs but the evidence above is thin, a short review against this table usually shows where to start. That is the kind of work we do in game backend development: deployment, observability and a handover your team can operate.