Dedicated Server Delivery

Treat a dedicated server as a release product with its own target, artifact contract, runtime configuration, and recovery path. The path must establish what runs, what it can access, what proves readiness, and which exact unit can be restored.

Define the server targets#

Create dedicated targets deliberately instead of deriving their identity from a general-purpose build. A target definition should declare the operating system, architecture, build configuration, runtime mode, content set, startup entry point, and required runtime dependencies. It should also state whether the target is for local verification, an automated environment, or a promoted runtime.

Separate target intent from machine selection: the target defines output, while worker capability defines where it builds. Workers can then be replaced without changing release identity.

Keep target inputs declared#

Version the target definition with source. Pin engine, compiler, SDK, plugin, packaging, and build-script inputs; record source and build-definition revisions in the manifest. Include the revision or deterministic identity of each checked-in configuration template and content profile.

Package only the runtime unit#

A deployable package should contain the server executable, declared runtime libraries, required cooked data, a versioned configuration template, and the start and stop contract. Exclude editor tools, workspaces, source trees, build caches, and credentials. The package must be reproducible from its manifest even when the original worker no longer exists.

Keep configuration and secrets outside the artifact#

Treat artifact content and runtime settings as separate contracts. The artifact contains a safe, versioned template and explicit configuration keys. The runtime environment supplies values that vary by deployment, such as endpoint selection, logging destinations, or operational limits.

Inject secrets at runtime through an approved secret boundary with the narrowest access needed. Do not bake them into images, packaged files, command history, test fixtures, or logs. A server should fail clearly when a required setting or secret is absent, rather than silently starting with an unsafe default. Document which component owns rotation, access review, and incident revocation.

Preserve artifact identity#

Publish each package to immutable storage with a manifest. At minimum, record source revision, build-definition revision, target, platform and architecture, engine and toolchain identity, content identity, checksums, compatibility identifier, configuration-template revision, and package location.

Promotion must select an exact manifest, not a folder that happens to contain a recent archive. The runtime should report enough of that identity to connect a running process back to its package without exposing secrets. This makes an incident investigation and a rollback start from evidence rather than guesswork.

Prove readiness before promotion#

A smoke test should install the package into a clean runtime, supply non-secret test configuration, start it, verify the health contract, and collect startup evidence. Include missing configuration, incompatible content, and unavailable dependency cases.

Separate liveness from readiness#

Liveness answers whether a process is still running. Readiness answers whether it has loaded the required content, applied configuration, initialized dependencies, and can accept the intended session or request. Keep the checks separate so an alive but unready server cannot promote.

Use a bounded canary#

A canary deploys the exact candidate package through the normal runtime path with an explicit observation window and owner. Define the acceptance evidence, stop condition, and rollback trigger before starting it. A canary is useful only when it exercises the configuration, admission, and readiness boundaries that differ from package creation.

Promote and roll back as one unit#

Promote the package, manifest, approved runtime configuration reference, compatibility decision, and validation evidence together. Do not rebuild while promoting. A release gate should block when identity is incomplete, readiness evidence is absent, or compatibility requirements are not met.

Preselect a prior proven package as the rollback unit. Rollback changes the runtime selection back to that immutable package and its compatible configuration reference. It should be possible to perform from the runbook without restoring a worker, recreating an archive, or asking a single person to remember undocumented steps.

Assign ownership at every handoff#

Name operational roles for target definitions, packaging, configuration templates, secret access, artifact retention, smoke evidence, canary decisions, promotion approval, and rollback execution. One role may own several responsibilities, but no handoff should be unowned. Record escalation and recovery procedures beside the delivery definition so ownership survives a staffing change.

Implementation sequence#

1. Inventory current server outputs and separate dedicated targets from client-oriented packaging.
2. Declare the target inputs, worker capabilities, and package contents in versioned definitions.
3. Publish an immutable package manifest and make promotion consume it.
4. Move variable configuration and secrets to explicit runtime boundaries.
5. Add clean-install smoke checks and separate readiness from liveness.
6. Define a bounded canary, promotion evidence, and a retained rollback unit.
7. Exercise a rollback and update the ownership map from the actual handoffs.

Practical checklist#

• Each server target declares platform, architecture, configuration, runtime mode, and content inputs.
• Package contents exclude source, cache, editor tooling, and credentials.
• The artifact manifest records reproducible build and compatibility identity.
• Runtime configuration templates are versioned separately from injected values.
• Secrets are injected at runtime and omitted from artifacts and logs.
• A clean runtime smoke test validates startup and required dependencies.
• Liveness and readiness have distinct checks and failure behavior.
• Canary evidence, stop conditions, and rollback triggers are defined before promotion.
• Promotion selects immutable artifacts with their evidence and configuration reference.
• Operational ownership includes recovery, access, retention, and rollback.

A dedicated-server path is dependable when every release can be identified, started, observed, promoted, and reversed without hidden machine or configuration state.