# Fleet settings Admin → Settings groups fleet limits and retention by the work they affect. Search by name or description, or choose a category in the section list. Each row shows its default, effect, and whether it has changed. Switching categories or searching keeps your pending edits. The sticky **Save changes** bar saves all pending changes together. **Discard** restores the last saved values. Settings persist in SQLite, apply without restarting the controller, and are writable only by administrators. Upgrades preserve existing values and add new defaults. Use **Forever** for history with no age expiry and **No limit** for optional concurrency or telemetry count caps. **No age expiry** on artifact versions still allows the version-count policy to remove old unused versions. **No delay** applies to the game-file grace period; **No minimum** applies to minimum retained counts. Turning these modes off restores the last finite value. Numeric fields show the unit beside the value. ## Concurrency The existing fleet restart, startup and removal limits default to 1. Additional limits default to 0 (no additional cap): - Restarts per host, including starts and rebuild recovery. - Startups per host, including creation and rebuilds. - Removals per host, including migration source removal. - Combined lifecycle work across create/start/stop/restart/rebuild/destroy. - Rebuilds across the fleet, including host drain migrations. - Hosts downloading or verifying game files simultaneously, including manual imports. Limits are checked again before command submission after asynchronous preflight. Launch-file preparation reserves capacity. A lifecycle workflow counts once in the combined pool; unresolved commands and recovery keep capacity occupied. Migrations keep rebuild capacity through source removal and destination creation. Lower limits do not cancel admitted work. Game-file preparation slots are assigned on agent command delivery and survive interrupted transfers. Runtime pulls, the four file transfers per host and the two health probes per host remain unchanged. ## Retention For age settings, 0 means no expiry. An explicit version-count policy can still expire unused artifact versions when their age policy is disabled. Game-file grace is a delay: 0 adds no delay. A positive age and version count together preserve the minimum count as well as versions younger than the age threshold. | History or storage | Default | | ---------------------------------------------- | ----------------------------------------------- | | Campaigns | 7 days | | Successful routine operations | 1 day | | Provisioning workflows | Indefinite | | Agent actions | Indefinite | | Explicitly resolved failures | Indefinite | | Non-update maintenance jobs | 30 days | | Resolved recovery incidents | Indefinite | | Host resource history | 7 days | | Instance resource samples | 1 day | | Fleet occupancy metrics | 31 days | | Telemetry diagnostics | 7 days; 200 per server; 10,000 overall | | Completed/interrupted matches | Indefinite | | Closed betas and test evidence | Indefinite | | Campaign file bodies and closed beta snapshots | 30 days | | Completed launch and command file bodies | 30 days | | Unused artifact versions | No automatic expiry; no minimum count | | Unused game files | No grace period; keep latest 1 version per game | | Incomplete browser uploads | Indefinite | | Authentication audit events | Indefinite | | Minimum history count | 0 additional records | Telemetry age and count policies are independent; 0 disables each individual cap. Diagnostic responses remain bounded to 10,000 rows when the per-server retention cap is disabled. Metric and capacity chart time ranges are unchanged; increasing storage retention does not automatically add new chart ranges. Capacity learning continues to use its 24-hour window independently of longer sample retention. ### Cleanup and dependencies Background cleanup runs in bounded batches. New age policies for previously permanent history default to indefinite. Pending work, unresolved failures, recovery dependencies and explicitly protected records are never removed merely because they are old. Referenced artifact versions are retained, including versions referenced by historical campaigns and betas. Collection workflows with unfinished members, cancellation links and recovery slots can keep provisioning history longer than its configured age. Update attempts and dismissed watchdog incidents remain durable suppression evidence. Host setup, credential/decommission operations and referenced agent commands are protected. Expired unreferenced action history drops payloads, results and events but keeps compact terminal receipts and request fingerprints. Reusing an idempotency key cannot execute an expired command again. Agent mutation journals remain intact; this policy controls controller history, not the agent's execution recovery journal. ### File bodies and match history Expiring campaign file bodies preserves file paths, hashes and summary records but makes file comparisons and rollback unavailable. The detail page identifies this state and rollback requests fail explicitly. Active beta rollback images stay protected. Expiring matches removes their player participation rows and changes leaderboard/player totals; lifetime aggregates are not retained separately. Completed launch recipes and command receipts also retain their metadata when their file bodies expire. Unfinished workflows, unreconciled commands, unresolved failures and explicit holds preserve the bytes they need. Shared file bytes are deleted only after their final reference expires; library versions can keep a file available longer. Previously saved retention choices are preserved on upgrade. ### Database cleanup The database upgrade normalizes retention clocks to UTC and enables incremental vacuum. An existing database without a vacuum page map is rebuilt once at startup; allow time for this rebuild and free disk space up to twice the database size. The rebuild uses disk-backed temporary storage and a 16 MiB page cache instead of holding a temporary copy of the database in RAM. Container scratch files use `/data/.sqlite-tmp`; `[database]` startup logs identify the current migration. Normal cleanup releases unused file blobs in bounded batches and incrementally returns free pages to disk after larger prunes. ### Game files and incomplete uploads Game-file minimums apply per game. Grace starts when a version is superseded. Live, stopped, rebuilding and provisioning instances pin their files; unresolved operations and offline host copies also prevent controller deletion. Controller cleanup still waits for every host to report its copy absent. Incomplete browser uploads expire based on their last activity, including resume checks; active chunk writes and publication hold locks against cleanup. Metadata remains after files expire. Raising retention cannot restore previously deleted bytes. ### Preview and record protection Expand **Cleanup preview and protected records** to preview the values currently entered without saving them. Preview lists eligible records and known payload sizes; SQLite file space may be reused rather than immediately returned to the OS. Policies can overlap, so payload sizes should not be added together. Unknown row, index, upload and agent-disk overhead is not included. Use a record's ID from its detail URL or the preview to protect it. Protection can be removed in the same panel. Protecting a campaign or beta also protects its file bodies; protecting those bodies prevents deletion of their parent history. Game-file and incomplete-upload protections apply to storage cleanup. The minimum history count preserves recent records per history category. It does not apply to telemetry caps, metric/resource samples or game-file storage, which have their own policies. Explicit holds protect individual history/storage records, not individual resource samples or telemetry diagnostics. Failed campaigns, provisioning workflows and agent commands require explicit resolution before the resolved-failure period applies. Resolution does not bypass recovery/dependency checks. Resolving a failed campaign stops automatic campaign retry requests; it does not cancel commands already submitted.