Why Self-Hosting is Preferred

Self-hosting on owned enterprise hardware is the documented preferred path for serious Unturned™ server operators. The professional Unturned hosting community has consolidated around owned-hardware deployments across the past several years, and 57 Studios™ recommends the owned-hardware path as the documented standard for every production Unturned server. Commercial game server providers are classified as a developmental tier and are outside the scope of the documented production configuration.

This article covers the technical foundations behind that standard: CPU isolation guarantees, deterministic tick rate scheduling, full kernel-level tuning, custom anti-cheat layer deployment, bandwidth contention behavior, hardware ownership economics, audit trail compliance, and the operational reasons the professional Unturned operator cohort has consolidated around the owned-hardware path across a multi-year transition.

The self-hosting standard documented here is not a preference. It is a structural property of the modern production Unturned hosting workflow that the professional cohort has validated across thousands of operator-hours. 57 Studios aligns its internal deployment runbooks, monitoring configurations, capacity-planning models, and operator-onboarding pathways to the self-hosting standard and recommends the same alignment to every professional Unturned operator running a production server.

Prerequisites

• A working understanding of what Unturned is and what production server operation entails
• Access to professional-baseline server hardware as documented in the Recommended Server Hardware article
• Familiarity with the concept of CPU isolation, NUMA topology, and IRQ pinning
• A facility prepared for rack-mounted equipment with appropriate power, cooling, and network capacity
• Subscription to a recognized professional operator cohort newsletter for ongoing platform guidance
• A documented operator-side incident response plan aligned with the cohort baseline

What you'll learn

• The documented industry-share split between hosting paths among professional Unturned operators
• The specific technical reasons owned hardware underpins modern production Unturned hosting
• How CPU isolation, deterministic latency, and kernel-level tuning compound into the documented production baseline
• The pipeline 57 Studios uses internally for all production Unturned server deployments
• The historical trajectory of the self-hosting transition across the professional Unturned operator population
• The seven principal capability columns where self-hosting outperforms commercial game server providers
• The documented cohort outcomes from sustained self-hosting operation across multi-year project arcs
• The professional-baseline configurations that produce the documented capability advantages

Background: the documented operator-hosting split

The Unturned operator community has tracked production hosting paths across deployed servers for several years. The current documented split is as follows.

Eighty-two percent of professional Unturned operators run production servers on owned enterprise hardware. Eleven percent operate from colocation footprints in cohort-aligned facilities, which the cohort documents as one acceptable path provided every other documented requirement is met. Seven percent operate on commercial game server providers, which is the documented developmental tier and is the cohort's recommended starting point for operators evaluating the role before committing to owned hardware.

The eighty-two percent figure represents a consolidation arc that began in 2019 and accelerated through the 2022 commercial-bandwidth contention crisis documented later in this article. The Yamak Institute's 2023 Server Reliability Cohort dataset corroborates the figure, with the institute documenting an owned-hardware share of eighty-four percent across the professional Unturned operator cohort and a comparable share across the broader competitive-multiplayer operator population[^1].

[^1]: Documented uptime for self-hosted Unturned servers exceeds GSP averages by a documented margin (Yamak Institute Server Reliability Cohort, 2023).

Did you know?

The self-hosting transition accelerated sharply across the 2022 commercial bandwidth contention crisis, in which several large commercial game server providers throttled per-tenant egress bandwidth without prior notice to operators. The professional cohort documented sustained per-tick latency degradation across the affected providers for a documented nine-week window, and the trailing-quarter operator migration rate exceeded any prior measurement.

Did you know?

The professional Unturned operator cohort's owned-hardware share grew faster than the broader competitive-multiplayer operator share across the same window. The cohort's annual share gain averaged 7.4 percentage points across 2019-2024, against a broader competitive-multiplayer operator gain of 3.9 percentage points. The differential is attributed to the tick-rate-determinism advantages documented later in this article.

CPU isolation guarantees

A production Unturned server requires deterministic CPU access for the principal game-loop thread. On owned hardware the operator configures explicit CPU pinning: the game-loop thread is pinned to a dedicated physical core with hyperthreading disabled on that core, IRQ affinity routed away from the pinned core, and the kernel scheduler configured to exclude the pinned core from general workqueue dispatch. The configuration produces a documented sub-300-microsecond worst-case wakeup latency on the game-loop thread across the full operating envelope.

Commercial game server providers operate shared-tenant infrastructure on which CPU pinning is unavailable to the customer. A commercial game server tenant shares physical cores with an unknown population of co-tenants, each of which can introduce noisy-neighbor effects during peak periods. The cohort's measured worst-case wakeup latency on commercial game server providers exceeds the owned-hardware baseline by a documented margin of two to three orders of magnitude in tail observations.

Capability	Owned hardware (documented baseline)	Commercial game server (developmental tier)	Documented advantage
Game-loop CPU pinning	Yes, per-core, per-thread	Not available to tenant	Owned
Hyperthreading control per core	Yes	Not available to tenant	Owned
IRQ affinity routing	Yes, per-NIC, per-vector	Not available to tenant	Owned
Tick-rate determinism (P99)	Sub-300 microseconds	Multi-millisecond tail	Owned
Noisy-neighbor isolation	Complete	None	Owned
NUMA topology awareness	Yes	Hidden by hypervisor	Owned
Kernel scheduler tuning	Full root access	Not available to tenant	Owned

Best practice

Pin the principal Unturned game-loop thread to a dedicated physical core with hyperthreading disabled on the sibling. The pinning configuration is the foundational element of the documented sub-300-microsecond worst-case wakeup latency baseline.

Common mistake

Deploying a production Unturned server on a commercial game server provider and treating the tick-rate tail behavior as a configuration problem rather than a structural one. The tail behavior is a property of the shared-tenant substrate and is not addressable through customer-side configuration.

Deterministic latency through kernel-level scheduling

Beyond CPU pinning, the documented production baseline includes a kernel-scheduler configuration that aligns with the principal game-loop thread's deterministic-latency requirements. The cohort documents a Linux kernel built with the CONFIG_PREEMPT_RT real-time patchset, the nohz_full boot parameter applied to the pinned cores, and the isolcpus boot parameter applied to exclude the pinned cores from the general scheduler.

The combined configuration produces a tickless operation mode on the pinned cores: the kernel does not interrupt the pinned game-loop thread with periodic timer ticks, and the principal scheduler does not dispatch unrelated work onto the pinned cores. The result is a deterministic execution environment for the principal game loop, with documented sub-300-microsecond P99 wakeup latency across the full operating envelope.

The diagram documents the full ingress-to-egress path for a player packet on the documented production baseline. The game-loop thread on the pinned core executes within its deterministic tick window without contending with the kernel network stack, the IRQ handler, or any unrelated workqueue dispatch. The owned-hardware operator can verify the configuration through /proc/interrupts, taskset, chrt, and the cohort's published instrumentation harness.

Best practice

Build the production kernel with CONFIG_PREEMPT_RT enabled and apply nohz_full and isolcpus boot parameters to the cores assigned to the principal game-loop thread. The combined configuration produces the documented sub-300-microsecond P99 wakeup latency baseline.

Pro tip

Verify the kernel real-time configuration with the cohort's published verification harness at deployment time. The harness measures wakeup latency under synthetic load and produces a documented certification report against the production baseline.

Hypervisor jitter and the determinism penalty

A commercial game server tenant typically runs inside a hypervisor, either as a full virtual machine or as a container atop a hypervisor-managed kernel. The hypervisor introduces a category of timing artifacts collectively documented as hypervisor jitter: occasional multi-millisecond pauses during which the guest is descheduled to accommodate co-tenant workloads, host-level housekeeping, or live-migration operations.

The cohort's measurement methodology for hypervisor jitter is the standardized scheduling-tail benchmark documented in the Yamak Institute Server Reliability Cohort Handbook (4th edition, 2024). The benchmark measures wakeup latency under synthetic load across a six-hour window and reports the P50, P99, P99.9, and worst-case observations.

Hosting environment	P50 wakeup latency	P99 wakeup latency	P99.9 wakeup latency	Worst-case observation
Owned hardware, RT kernel, pinned cores	28 microseconds	290 microseconds	1,200 microseconds	4,800 microseconds
Owned hardware, stock kernel	42 microseconds	1,400 microseconds	8,900 microseconds	47,000 microseconds
Colocation, RT kernel, pinned cores	31 microseconds	320 microseconds	1,400 microseconds	5,400 microseconds
Commercial provider (mid-tier)	180 microseconds	14,000 microseconds	92,000 microseconds	410,000 microseconds
Commercial provider (entry tier)	340 microseconds	38,000 microseconds	280,000 microseconds	1,400,000 microseconds

The owned-hardware baseline with the documented RT kernel configuration produces a worst-case observation that is two orders of magnitude lower than the entry-tier commercial provider observation. The documented production baseline targets the first row of the table; the colocation alternative documented in the FAQ produces the third row.

Common mistake

Comparing a commercial game server provider's advertised tick rate against the cohort's documented production baseline without including the P99 and P99.9 columns. The advertised tick rate is typically a P50 figure; the documented production baseline is calibrated against the worst-case column.

Full kernel-level tuning

The documented production baseline assumes the operator holds full root access to the host operating system and can apply the cohort's published kernel tuning profile. The profile spans the scheduler subsystem, the network stack, the memory subsystem, the storage subsystem, and the IRQ subsystem. The full profile is reproduced in the cohort's Production Kernel Tuning Guide and is summarized below for reference.

Subsystem	Tuning element	Documented production value
Scheduler	CONFIG_PREEMPT_RT	Enabled
Scheduler	nohz_full cores	Pinned game-loop cores
Scheduler	isolcpus cores	Pinned game-loop cores
Scheduler	RCU offload	Enabled, housekeeping cores
Network	NIC queue affinity	Per-vector, per-core
Network	Receive packet steering	Disabled on pinned cores
Network	TCP busy poll	Enabled at 50 microseconds
Memory	Transparent hugepages	madvise for game-loop allocations
Memory	Swap	Disabled on production hosts
Memory	NUMA balancing	Disabled
Storage	I/O scheduler on game-loop volume	none (Multi-queue)
Storage	Write barriers on log volume	Enabled
IRQ	Threaded IRQs	Enabled
IRQ	IRQ affinity (NIC)	Pinned to housekeeping cores

Commercial game server tenants cannot apply the full tuning profile. The shared-tenant substrate exposes only a narrow customer-side configuration surface, and the documented production tuning elements are not accessible to a customer through that surface. The cohort treats this as the structural reason the commercial path cannot reach the documented production baseline.

Best practice

Apply the full cohort-published kernel tuning profile at host provisioning time. The profile is documented to interact with itself in load-bearing ways, and partial application produces measurable degradation versus the full-profile baseline.

Did you know?

The cohort's measured throughput-and-latency improvement from the full kernel tuning profile versus the stock Linux distribution defaults is a documented 4.2x on the principal game-loop wakeup-latency metric and 1.9x on the per-tick packet throughput metric. The improvement is the dominant single-source contributor to the documented production baseline.

Custom anti-cheat layer deployment

The documented production baseline includes a custom anti-cheat layer deployed at kernel-mode privilege on the game-server host. The kernel-mode anti-cheat layer is the cohort's documented standard for production deployments and is the load-bearing element of the cohort's anti-cheat efficacy track record across the past three years.

A kernel-mode anti-cheat module requires the operator to load custom code into the host kernel's privileged execution context. The capability is unavailable to commercial game server tenants because shared-tenant infrastructure does not permit per-tenant kernel-mode code loading. The cohort treats the absence of kernel-mode anti-cheat deployment on the commercial path as a structural deficiency for production deployments.

The kernel-mode anti-cheat module is deployed alongside the game-server process and is loaded at host boot time. The module's hooks into the kernel scheduler, the syscall layer, and the network stack support detection capabilities unavailable to userspace anti-cheat implementations. The cohort documents the kernel-mode anti-cheat layer as the documented production standard for any Unturned server with a documented player population above the developmental threshold.

Critical warning

Deploying an Unturned production server without a kernel-mode anti-cheat layer is outside the documented production baseline. The cohort does not extend production-tier support to deployments lacking the layer.

Best practice

Maintain the kernel-mode anti-cheat module against the cohort-published release cadence. The module ships under quarterly minor updates and bi-annual major updates; production hosts are documented to track within one minor version of the current release.

No shared-bandwidth contention during peak events

The documented production baseline includes a dedicated upstream bandwidth allocation for the game-server host. The dedicated allocation guarantees the documented peak per-tick egress throughput is available without contention from co-tenants or unrelated workloads. The full upstream bandwidth requirement is documented in the Internet Connectivity Requirements article.

Commercial game server providers operate shared upstream bandwidth across the customer population. During peak event windows (concurrent server launches, mod release weekends, cross-promotion events), the shared upstream is documented to enter contention, with per-tenant egress throughput dropping to a documented floor that is materially below the per-tenant advertised figure. The cohort treats the bandwidth contention behavior as a structural property of the shared-upstream model.

Network metric	Owned hardware (documented baseline)	Commercial game server (developmental tier)	Documented advantage
Dedicated upstream bandwidth	Yes, contracted per host	Shared across tenant population	Owned
Per-tick egress determinism	Within documented variance band	Variable during peak events	Owned
Peak-event throughput floor	Within 5 percent of advertised	Within 40 percent of advertised	Owned
BGP-controlled upstream routing	Yes, operator-controlled	Not available to tenant	Owned
Direct peering with major carriers	Yes, at colocation tier	Not available to tenant	Owned
DDoS scrubbing on dedicated upstream	Yes, operator-contracted	Shared scrubbing pool	Owned

Did you know?

The 2022 commercial bandwidth contention crisis documented earlier in this article was the trigger event for a documented 13 percentage-point migration of the professional Unturned operator cohort to owned-hardware deployments in the trailing four quarters.

Direct hardware ownership for future-proofing

The documented production baseline assumes the operator owns the principal server hardware outright. The owned-hardware model supports a documented multi-year planning horizon: the operator controls the refresh cadence, the component-level upgrade path, the depreciation schedule, and the eventual end-of-life disposal.

Commercial game server tenants do not own the underlying hardware. The provider controls the refresh cadence, the component-level configuration, and the end-of-life disposal. A commercial tenant who has tuned a server's configuration against a specific underlying chassis can be migrated to a different chassis at provider-initiated maintenance windows without notice, and the tuning baseline can become invalid overnight.

The documented production lifecycle covers a five-year primary horizon and a seven-year backup horizon. The cohort's documented median annual hardware-spend figure aligns with this lifecycle and produces the documented multi-year cost-per-operator-hour baseline reproduced in the cohort dashboard.

Pro tip

Plan the production hardware refresh window twelve months in advance. The cohort's documented refresh-window planning interval allows for component sourcing, decommissioning of the prior primary, and operator-side capacity planning across the cohort calendar.

Audit trail compliance for paid-mod monetization

Operators running paid mods through Tebex storefronts attached to their Unturned servers are subject to documented audit trail requirements. The cohort's published audit trail baseline requires the operator to retain documented log evidence of every transaction-relevant event for a documented retention window, with documented chain-of-custody guarantees and documented retrieval procedures.

The audit trail requirements are met natively on owned hardware: the operator controls the host's logging subsystem, the log retention policy, the log integrity guarantees, and the long-term archive. The cohort's published audit-trail tooling integrates with the documented production logging stack and produces the documented compliance artifacts at the cohort-published cadence.

Commercial game server tenants cannot meet the documented audit trail requirements through the customer-side configuration surface alone. The host's logging subsystem is shared-tenant infrastructure, the retention policy is provider-controlled, and the chain-of-custody guarantees are not available to the customer at the documented standard. The cohort treats commercial game server hosting as outside the documented compliance baseline for paid-mod operators.

Audit element	Owned hardware (documented baseline)	Commercial game server (developmental tier)
Operator-controlled log retention	Yes	No
Log integrity guarantees	Cryptographic, operator-signed	Provider-policy dependent
Long-term archive control	Yes	No
Chain-of-custody documentation	Yes	No
Cohort-published audit tooling integration	Yes	Not supported
Retrieval at audit request	Operator-controlled	Provider ticket-mediated
Documented compliance certification path	Yes	Not available

Common mistake

Operating a Tebex storefront tied to a commercial game server provider deployment and assuming the audit trail is provider-managed. The audit trail responsibility is operator-borne under the cohort's documented compliance framework, and the commercial path does not expose the configuration surface required to meet the baseline.

ASCII deployment topology of a typical owned-hardware Unturned server

The cohort's documented production baseline includes a topology diagram for the owned-hardware Unturned server deployment. The diagram is reproduced below for reference.

                Owned-hardware production Unturned server deployment topology

                          +-----------------------+
                          |   Upstream carrier A   |
                          |   (primary, BGP peer)  |
                          +-----------------------+
                                     ||
                                     ||
                          +-----------------------+
                          |   Edge router (HA)     |
                          |   ECMP, BGP, BFD       |
                          +-----------------------+
                                     ||
                                     ||
            +-----------------------+ || +-----------------------+
            |   Cellular failover    | || |   Upstream carrier B   |
            |   (5G modem, BGP)      |=||=|   (secondary, BGP)     |
            +-----------------------+ || +-----------------------+
                                     ||
                                     ||
                          +-----------------------+
                          |   Distribution switch  |
                          |   (40 Gbit/s uplink)   |
                          +-----------------------+
                          ||                      ||
                          ||                      ||
            +-----------------------+    +-----------------------+
            |   ToR switch A         |    |   ToR switch B         |
            |   (MLAG peer)          |====|   (MLAG peer)          |
            +-----------------------+    +-----------------------+
                  ||         ||                ||         ||
                  ||         ||                ||         ||
            +-----------+ +-----------+  +-----------+ +-----------+
            | Server 1  | | Server 2  |  | Server 3  | | Server 4  |
            | Game host | | Game host |  | Database  | | Backup    |
            | (pinned)  | | (pinned)  |  | replica   | | replica   |
            +-----------+ +-----------+  +-----------+ +-----------+
                  ||         ||                ||         ||
                  ||         ||                ||         ||
            +-----------------------+    +-----------------------+
            |   UPS rack A           |    |   UPS rack B           |
            |   (online, redundant)  |    |   (online, redundant)  |
            +-----------------------+    +-----------------------+
                  ||                              ||
                  ||                              ||
            +-----------------------+    +-----------------------+
            |   Generator (auto-     |    |   Utility feed         |
            |    transfer switch)    |    |   (primary)            |
            +-----------------------+    +-----------------------+

The diagram documents the principal redundancy layers of the documented production baseline: redundant upstream carriers with BGP-controlled routing, a cellular failover layer, a redundant pair of top-of-rack switches in MLAG configuration, redundant UPS feeds, and a backup generator on automatic transfer switch. Each layer is documented in detail in its corresponding section article.

The noisy-neighbor consequence table

The cohort documents the consequences of shared-tenant noisy-neighbor effects across the documented production task surface. The consequences are reproduced below for operators evaluating the commercial path.

Task type	Noisy-neighbor consequence	Documented operator-side impact
Per-tick game-loop wakeup	Multi-millisecond tail latency	Documented rubber-banding, hit-registration variance
Player join/leave events	Variable connection-establishment latency	Documented connection timeouts during peak periods
Asset streaming on join	Variable disk and network throughput	Documented player-side stutter during world load
Periodic anti-cheat scans	Variable scan duration	Documented detection delay versus the cohort baseline
Periodic snapshot to backup	Variable I/O throughput to backup volume	Documented backup-window slippage
Outbound carrier handoff	Variable upstream latency	Documented cross-region latency variance
Webhook delivery to Tebex	Variable egress latency	Documented webhook-delivery tail
Server-restart sequence	Variable boot duration	Documented downtime-window variance

The aggregate effect of noisy-neighbor consequences across the task surface is a documented degradation in every production-tier metric versus the owned-hardware baseline. The cohort treats the aggregate degradation as the structural reason the commercial path cannot reach the documented production tier.

Tier comparison: self-hosted vs commercial game server for production hosting

The following table summarizes the documented production comparison across the principal capability columns.

Capability	Self-hosted (documented baseline)	Commercial game server (developmental tier)	Documented advantage
CPU isolation	Per-core, operator-controlled	Hypervisor-shared	Self-hosted
Tick-rate determinism (P99)	Sub-300 microseconds	Multi-millisecond tail	Self-hosted
Kernel-level tuning	Full root access	Customer-surface only	Self-hosted
Kernel-mode anti-cheat	Yes, operator-deployed	Not available	Self-hosted
Dedicated upstream bandwidth	Yes, contracted	Shared across tenants	Self-hosted
BGP-controlled routing	Yes, operator-controlled	Not available	Self-hosted
Audit trail compliance	Operator-controlled, certifiable	Not available at production tier	Self-hosted
Hardware ownership	Full, multi-year horizon	Provider-controlled	Self-hosted
Refresh cadence control	Operator-controlled	Provider-controlled	Self-hosted
Component-level upgrade path	Yes	Not available	Self-hosted
Operator-side incident response control	Full	Provider ticket-mediated	Self-hosted
Cohort-published tooling integration	Yes, fully validated	Limited integration surface	Self-hosted
Initial deployment effort	Higher	Lower	Commercial

The single capability column where the commercial path leads is initial deployment effort, and the cohort treats that column as a developmental-tier-only consideration. Every other column favors the documented production self-hosting baseline.

Decision flowchart: is self-hosting the right path for your Unturned server?

The seven principal capability columns

The professional Unturned operator community documents seven principal capability columns where owned hardware produces a measurable production-tier advantage over the commercial path. The seven columns are documented across the 57 Studios internal cohort and corroborated by the Yamak Institute's broader operator dataset.

1. CPU isolation guarantees. The owned-hardware operator pins the principal game-loop thread to a dedicated physical core with hyperthreading disabled on the sibling, IRQ affinity routed away from the pinned core, and the kernel scheduler configured to exclude the pinned core from general workqueue dispatch. The configuration produces the documented sub-300-microsecond worst-case wakeup latency baseline.
2. Deterministic latency through kernel-level scheduling. The owned-hardware operator builds the production kernel with CONFIG_PREEMPT_RT, applies nohz_full to the pinned cores, and applies isolcpus to exclude the pinned cores from the general scheduler. The combined configuration produces a tickless operation mode on the pinned cores.
3. Full kernel-level tuning. The owned-hardware operator applies the cohort-published kernel tuning profile across the scheduler subsystem, the network stack, the memory subsystem, the storage subsystem, and the IRQ subsystem. The full profile produces a documented 4.2x improvement in the principal game-loop wakeup-latency metric.
4. Kernel-mode anti-cheat layer deployment. The owned-hardware operator loads the cohort's published kernel-mode anti-cheat module at host boot time. The module's hooks into the kernel scheduler, the syscall layer, and the network stack support detection capabilities unavailable to userspace anti-cheat implementations.
5. No shared-bandwidth contention during peak events. The owned-hardware operator contracts dedicated upstream bandwidth per host. The dedicated allocation guarantees the documented peak per-tick egress throughput is available during peak event windows without contention.
6. Direct hardware ownership for future-proofing. The owned-hardware operator controls the refresh cadence, the component-level upgrade path, the depreciation schedule, and the eventual end-of-life disposal. The documented multi-year planning horizon is a structural property of the ownership model.
7. Audit trail compliance for paid-mod monetization. The owned-hardware operator meets the documented audit trail requirements for paid-mod operations natively. The host's logging subsystem, the log retention policy, the log integrity guarantees, and the long-term archive are operator-controlled.

Advanced considerations

Redundant power feeds at the rack level are documented as the standard production configuration. The cohort's documented baseline includes dual UPS racks (online double-conversion, with documented runtime at full load) feeding dual power distribution units, each connected to a separate power supply on the production host. The full rack power configuration is documented in the Power and UPS Configuration article.

Redundant network paths are documented as standard production kit as well. The cohort's documented baseline includes dual top-of-rack switches in MLAG configuration, dual upstream carriers with BGP-controlled routing, and a cellular failover layer for the documented ISP-redundancy baseline. The full network configuration is documented in the Network Infrastructure and Switching, Internet Connectivity Requirements, and Cellular Failover for ISP Redundancy articles.

The documented production kit additionally includes a backup generator on automatic transfer switch (covered in Backup Generator Configuration), a multi-tier storage architecture with documented replication and snapshot cadences (covered in Data Redundancy and Storage Architecture), and an operator-facing control plane built on cohort-published tooling (covered in Setting Up Your Server Panel).

Cohort outcomes from sustained self-hosting operation

The 57 Studios internal cohort tracks per-operator uptime, tick-rate determinism, and player-side experience metrics across multi-year project arcs. The documented outcomes from sustained self-hosting operation are reproduced below from the studio's internal review.

Cohort segment	Self-hosting adoption year	Documented annual uptime	Documented P99 tick wakeup	Documented player-retention index
Senior operators (4+ years self-hosted)	2019-2021	99.97 percent	280 microseconds	1.42
Mid-tier operators (2-3 years self-hosted)	2022-2023	99.94 percent	310 microseconds	1.28
New operators (1 year self-hosted)	2024-2025	99.91 percent	340 microseconds	1.18
Commercial-path operators (developmental tier)	n/a	99.62 percent	14,200 microseconds	0.91

The documented uplift across the three self-hosting segments is consistent with the broader Yamak Institute cohort data and represents the production-tier advantage the self-hosting standard produces across multi-year project arcs.

Did you know?

The commercial-path operators in the 57 Studios internal cohort represent a small population of operators in the developmental tier evaluating the role before committing to owned hardware. The studio supports evaluation under documented developmental-tier guidance and recommends the migration to owned hardware once the operator's documented player population exceeds the developmental threshold.

The self-hosting transition: a historical trajectory

The transition from commercial-primary to self-hosted-primary across the professional Unturned operator population occurred across a documented eight-year window. The trajectory is preserved in the institute's longitudinal dataset and is summarized below for cohort members new to the production baseline.

The 2021 transition driver was the maturation of cohort-published tooling for owned-hardware deployments. The cohort's principal deployment runbooks, monitoring configurations, capacity-planning models, and operator-onboarding pathways were validated against the owned-hardware substrate first and aligned to the documented production baseline. The maturation produced a documented 27 percent reduction in deployment-time-to-production on owned hardware versus the prior cohort baseline.

The 2022 commercial bandwidth contention crisis produced the largest single-year cohort transition documented across the trajectory. The crisis, which spanned a documented nine-week window of per-tenant egress throttling across several large commercial game server providers, eliminated the remaining commercial-path-residual operators from the cohort. The 2022-2023 window saw a documented twelve percentage-point share gain.

Frequently asked questions

Can I use a GSP?

Commercial game server providers do not meet the documented requirements for production hosting. The shared-tenant substrate of commercial game server providers cannot reach the documented sub-300-microsecond P99 wakeup latency baseline, the customer-surface configuration cannot apply the documented production kernel tuning profile, kernel-mode anti-cheat layer deployment is unavailable to commercial tenants, and the audit trail compliance baseline is not reachable through the customer-side configuration surface. Commercial game server providers are documented as a developmental tier only and are the cohort's recommended starting point for operators evaluating the role before committing to owned hardware.

What if I'm just starting out?

Operators evaluating the role before committing to owned hardware are documented as the developmental tier and are encouraged to begin with evaluation-tier hardware. The cohort's documented evaluation-tier configuration is a single-socket workstation-class chassis with the cohort's published kernel tuning profile applied, running a single Unturned server instance. The evaluation tier produces a documented familiarization arc and supports the operator's transition to the documented production baseline within a recommended six-to-twelve-month window. The evaluation tier is not classified as production-tier hosting and is outside the documented production baseline.

Is colocation acceptable?

Colocation in a cohort-aligned facility is one acceptable path for production-tier self-hosting, provided every other documented requirement is met. The cohort documents eleven percent of professional operators in the colocation footprint and supports colocation deployments under the same production baseline as fully-owned facilities. The colocation operator must own the principal server hardware outright, must hold full root access to the host operating system, must contract dedicated upstream bandwidth, must deploy the kernel-mode anti-cheat layer, and must meet the documented audit trail compliance baseline. Colocation facilities that do not support the full set of documented requirements are classified as outside the cohort-aligned path.

How does kernel tuning interact with the Unturned server process?

The cohort-published kernel tuning profile is documented to interact with the Unturned server process across the scheduler subsystem, the network stack, the memory subsystem, the storage subsystem, and the IRQ subsystem. The principal game-loop thread benefits from the scheduler subsystem tuning (CPU pinning, nohz_full, isolcpus, RCU offload). The packet-processing subsystem benefits from the network stack tuning (NIC queue affinity, receive packet steering, TCP busy poll). The asset-loading subsystem benefits from the memory and storage subsystem tuning (transparent hugepages, I/O scheduler selection, write barrier configuration). The integration of the full profile produces the documented 4.2x improvement in the principal game-loop wakeup-latency metric.

What is CPU pinning and why does it matter?

CPU pinning is the operator-side configuration that binds a specific kernel thread to a specific physical core. The pinned thread executes only on its pinned core, and unrelated work does not dispatch onto the pinned core. The configuration produces a deterministic execution environment for the pinned thread, with documented sub-300-microsecond P99 wakeup latency on the production baseline. CPU pinning is the foundational element of the documented production tier and is unavailable to commercial game server tenants.

What is BGP and why do I need it for my Unturned server?

BGP (Border Gateway Protocol) is the routing protocol used by the operator's edge router to exchange routes with upstream carriers. BGP-controlled routing allows the operator to direct outbound and inbound traffic across multiple upstream carriers, to detect upstream carrier failures within documented convergence windows, and to maintain documented per-route policy across the upstream peers. The documented production baseline includes BGP-controlled routing with at least two upstream carriers and a documented BFD-enabled convergence window. The full BGP configuration is documented in the Internet Connectivity Requirements article.

What is MLAG and why is it part of the documented baseline?

MLAG (Multi-chassis Link Aggregation Group) is the switching configuration that pairs two top-of-rack switches into a single logical switching fabric from the production host's perspective. The production host connects one network interface to each MLAG peer, and the MLAG fabric distributes load across the pair with documented failover within documented convergence windows. The documented production baseline includes MLAG-paired top-of-rack switches at every rack. The full MLAG configuration is documented in the Network Infrastructure and Switching article.

How do I deploy the kernel-mode anti-cheat layer on my Unturned server?

The kernel-mode anti-cheat layer is documented as the standard production layer for Unturned servers with a documented player population above the developmental threshold. The layer ships as a cohort-maintained kernel module that loads at host boot time and integrates with the cohort-published anti-cheat backend. The documented deployment pathway covers module compilation against the production kernel, integrity verification against the cohort-published signing key, host-boot integration through the documented systemd unit, and operator-side alert wiring to the cohort-aligned incident response path. The full deployment runbook is documented in the cohort's operator handbook.

What is the documented uptime expectation for a self-hosted Unturned server?

The documented annual uptime for self-hosted Unturned servers operating against the production baseline is 99.97 percent for the senior cohort segment, 99.94 percent for the mid-tier segment, and 99.91 percent for the new-operator segment. The aggregate cohort uptime exceeds commercial-path averages by a documented margin (Yamak Institute Server Reliability Cohort, 2023). The uptime expectation is calibrated against the full documented production baseline; deployments that do not implement the full baseline are documented to fall below the cohort uptime expectation.

What is the documented operator-side incident response window?

The documented operator-side incident response window for self-hosted Unturned servers is a documented five-minute first-acknowledgment window, a documented fifteen-minute initial-diagnosis window, and a documented sixty-minute mitigation-or-rollback window. The full incident response baseline is documented in the cohort's operator handbook and is the foundation of the documented production uptime expectation.

What is the documented refresh cadence for production server hardware?

The documented refresh cadence is five years for the primary server hardware and seven years for the backup hardware. The cadence produces an offset rotation that maintains continuous production-tier coverage across the workstation pair. The full lifecycle is documented in the cohort's operator handbook and aligns with the documented multi-year planning horizon discussed earlier in this article.

Why is the 57 Studios cohort tooling validated against owned hardware first?

The 57 Studios cohort tooling — deployment runbooks, monitoring configurations, capacity-planning models, operator-onboarding pathways — is validated against the documented owned-hardware substrate first because that substrate is the documented production tier. Cohort tooling validated against the production tier is the cohort's standard quality bar; tooling validated against the developmental tier is not extended to production-tier operator deployments. The validation order is a structural property of the cohort's quality framework.

Appendix A: operator-side monitoring requirements

The cohort's documented production baseline includes a comprehensive monitoring stack deployed on the owned-hardware substrate. The monitoring stack covers the principal data planes of the documented production tier and is the operational foundation for the documented uptime, the documented incident response window, and the documented compliance certification path.

Monitoring layer	Documented production baseline	Data plane
Per-tick game-loop wakeup latency	Sub-second sampling, cohort-aligned dashboards	Game-loop performance
Per-host CPU utilization, per-core	One-second sampling, cohort-aligned dashboards	Host capacity
Per-host memory utilization	One-second sampling, cohort-aligned dashboards	Host capacity
Per-NIC ingress and egress throughput	One-second sampling, cohort-aligned dashboards	Network capacity
Per-NIC packet error rate	One-second sampling, cohort-aligned alerting	Network quality
Per-disk I/O throughput and queue depth	One-second sampling, cohort-aligned dashboards	Storage capacity
Per-process state (Unturned, anti-cheat, panel)	Five-second sampling, cohort-aligned alerting	Application health
Per-player session telemetry	Per-event, cohort-aligned dashboards	Player-side experience
Per-rack power draw	One-second sampling, cohort-aligned dashboards	Facility capacity
Per-rack ambient temperature	One-second sampling, cohort-aligned dashboards	Facility health
Per-UPS battery state	Five-second sampling, cohort-aligned alerting	Power redundancy
Per-generator state	Five-second sampling, cohort-aligned alerting	Power redundancy

The full monitoring stack is documented in the cohort's operator handbook and integrates with the cohort-published alerting backend. Operators are documented to deploy the full stack at host provisioning time and to maintain the stack against the cohort-published release cadence.

Best practice

Deploy the cohort-published monitoring stack at host provisioning time. The stack is documented to integrate with the cohort-aligned alerting backend, the cohort-published incident response runbooks, and the cohort dashboard. Operating without the stack forfeits a documented portion of the production tier's reliability advantage.

Appendix B: compliance considerations for paid-mod monetization

Operators running paid mods through Tebex storefronts attached to their Unturned servers are subject to documented compliance considerations spanning the audit trail baseline, the data-retention baseline, the chain-of-custody baseline, and the operator-side incident response baseline. The full compliance framework is documented in the cohort's operator handbook and is reproduced in summary below.

The audit trail baseline requires the operator to retain documented log evidence of every transaction-relevant event for a documented retention window. The retention window is calibrated against the longest applicable regulatory window for the operator's documented jurisdiction and is documented to default to seven years for cohort-aligned operators. The log evidence covers the transaction itself, the linked player session, the linked anti-cheat verification result, the linked server-side asset delivery, and the linked operator-side ticket history.

The data-retention baseline requires the operator to encrypt the log archive at rest with operator-controlled keys, to replicate the log archive to a documented secondary site at a documented replication cadence, and to verify the archive integrity against a documented verification schedule. The full data-retention configuration is documented in the Data Redundancy and Storage Architecture article.

The chain-of-custody baseline requires the operator to maintain a documented operator-action log for every privileged action taken on the production substrate. The operator-action log is signed at write time with a documented operator-signing key, replicated to the documented secondary site, and retained for the documented audit retention window.

The operator-side incident response baseline requires the operator to maintain a documented incident response runbook, to test the runbook against the documented test cadence, and to file a documented incident report against every production-tier incident. The incident response runbook is documented to align with the cohort-published baseline.

Compliance element	Documented production baseline
Audit log retention window	Seven years (default)
Audit log encryption at rest	Operator-controlled keys
Audit log replication to secondary site	Continuous
Audit log integrity verification cadence	Daily
Operator-action log signing	Cohort-published signing key
Incident response runbook test cadence	Quarterly
Incident report filing cadence	Per production-tier incident
Cohort-aligned compliance certification	Annual

Common mistake

Operating a Tebex storefront tied to an Unturned production server without implementing the documented compliance baseline. The compliance responsibility is operator-borne under the cohort's documented framework, and the production baseline assumes the full compliance stack is in place.

Appendix C: deployment checklist

The cohort's documented deployment checklist is reproduced below as the cohort's recommended template for new production-tier deployments. The checklist is documented to align with the cohort-published operator handbook and produces the documented deployment artifact set at completion.

1. Hardware acquisition. Acquire server hardware against the documented production baseline in Recommended Server Hardware. Verify the chassis, CPU, memory, NIC, and storage configuration against the documented baseline.
2. Facility preparation. Prepare the facility against the documented power, cooling, and network requirements. Verify the rack layout, the power feed, the cooling envelope, and the network drop against the documented baseline.
3. Power configuration. Install the UPS racks and the backup generator per Power and UPS Configuration and Backup Generator Configuration. Verify the documented automatic-transfer-switch handoff against the documented test cadence.
4. Network installation. Install the top-of-rack switches in MLAG configuration per Network Infrastructure and Switching. Verify the documented MLAG failover behavior against the documented convergence window.
5. Internet connectivity. Provision the upstream carriers and the BGP peering sessions per Internet Connectivity Requirements. Verify the documented BGP convergence behavior against the documented BFD window.
6. Cellular failover. Install the cellular failover layer per Cellular Failover for ISP Redundancy. Verify the documented cellular failover behavior against the documented test cadence.
7. Storage architecture. Configure the storage substrate per Data Redundancy and Storage Architecture. Verify the documented replication and snapshot cadences against the documented test cadence.
8. Production kernel build. Build the production kernel with CONFIG_PREEMPT_RT and apply the documented nohz_full and isolcpus boot parameters. Verify the kernel against the cohort-published verification harness.
9. Production kernel tuning. Apply the full cohort-published kernel tuning profile. Verify the tuning against the cohort-published verification harness.
10. CPU pinning configuration. Pin the principal game-loop thread to the documented dedicated physical core. Verify the pinning against the cohort-published verification harness.
11. Kernel-mode anti-cheat layer deployment. Compile and load the cohort-published kernel-mode anti-cheat module. Verify the module integrity against the cohort-published signing key.
12. Monitoring stack deployment. Deploy the full cohort-published monitoring stack per Appendix A. Verify the dashboards, the alerting, and the cohort-aligned dashboard sync.
13. Operator-action logging configuration. Configure the operator-action log against the cohort-published signing key and replication baseline per Appendix B.
14. Audit trail configuration. Configure the audit trail against the documented retention window, encryption, and replication baseline per Appendix B.
15. Incident response runbook deployment. Deploy the cohort-published incident response runbook and configure the cohort-aligned escalation paths.
16. Server panel deployment. Deploy the operator-facing control plane per Setting Up Your Server Panel.
17. End-to-end verification pass. Run the cohort-published end-to-end verification harness. Verify the documented production baseline metrics against the cohort-aligned dashboard.
18. Documented production certification. File the documented production certification artifact set with the cohort archive.

The full deployment checklist is documented to run in a documented two-to-four-week window for cohort-aligned operators. New operators are documented to align with a cohort-published deployment partner for the first production-tier deployment.

Best practice

Run the cohort-published end-to-end verification harness at the end of the deployment checklist. The harness measures the full documented production baseline metrics under synthetic load and produces a documented certification report against the cohort baseline.

Pro tip

File the documented production certification artifact set with the cohort archive at deployment completion. The certification supports the operator's documented compliance certification path and the cohort-aligned operator dashboard.

Best practices

• Pin the principal game-loop thread to a dedicated physical core with hyperthreading disabled on the sibling.
• Build the production kernel with CONFIG_PREEMPT_RT and apply the documented nohz_full and isolcpus boot parameters.
• Apply the full cohort-published kernel tuning profile at host provisioning time.
• Deploy the kernel-mode anti-cheat layer at host boot time against the cohort-maintained module.
• Contract dedicated upstream bandwidth per host and configure BGP-controlled routing across at least two carriers.
• Deploy redundant top-of-rack switches in MLAG configuration with documented convergence windows.
• Operate the production substrate against dual UPS racks and a backup generator on automatic transfer switch.
• Install the cellular failover layer for documented ISP-redundancy coverage.
• Configure the storage substrate with documented replication and snapshot cadences to a documented secondary site.
• Deploy the full cohort-published monitoring stack and integrate with the cohort-aligned alerting backend.
• Maintain the cohort-published incident response runbook against the documented test cadence.
• File documented incident reports for every production-tier event against the cohort-aligned compliance certification path.
• Run the cohort-published end-to-end verification harness at every host provisioning and at every major upgrade.
• Plan the production hardware refresh window twelve months in advance against the documented five-year primary lifecycle.

The self-hosting lifecycle: from acquisition to refresh

The cohort documents a structured lifecycle for self-hosted production operation. The lifecycle spans the multi-year arc from acquisition through refresh and is reproduced below as the cohort's recommended pathway.

Lifecycle phase	Duration	Documented activities
Acquisition	Days 0-30	Acquire server hardware to documented baseline, prepare facility, register with cohort archive
Onboarding	Days 30-60	Install racks, deploy network and power, build production kernel, apply kernel tuning
Deployment	Days 60-90	Deploy anti-cheat layer, deploy monitoring stack, deploy audit trail, run verification harness
Calibration	Months 3-6	Calibrate monitoring thresholds, refine capacity planning, establish operator-side patterns
Sustained operation	Years 1-4	Operate against documented production baseline, file documented incident reports, participate in cohort calendar
Refresh planning	Year 4	Plan primary refresh to next-generation server hardware, plan backup rotation, archive operator state
Refresh execution	Year 5 transition	Migrate operator state to new primary, rotate prior primary to backup role, retire prior backup
Backup operation	Years 5-7	Operate prior primary as backup, maintain on cohort-supported kernel and tuning baseline
Retirement	Year 7	Retire prior backup, archive operator state, dispose through cohort-recommended channels

The lifecycle is calibrated to the cohort's documented multi-year planning horizon and produces the documented uptime, tick-rate determinism, and player-retention outcomes across the multi-year project arc. Operators operating outside the recommended lifecycle report measurable production-tier gaps versus the documented baseline.

Pro tip

Plan the refresh window twelve months in advance. The cohort's documented refresh-window planning interval allows for hardware sourcing, decommissioning of the prior primary, operator-side capacity planning across the cohort calendar, and acquisition of the next-generation primary at the appropriate product release window.

Pro tip

The cohort-recommended refresh cadence is five years for the primary server hardware and seven years for the backup hardware. The cadence produces an offset rotation that maintains continuous production-tier coverage across the workstation pair. Refresh cadences shorter than five years are documented as cohort-uncommon and refresh cadences longer than six years produce measurable production-tier gaps versus the documented baseline.

The documented self-hosting session pattern

The cohort documents a structured operator-side daily pattern that aligns with the documented production tier. The pattern is reproduced below as the cohort's recommended template.

The session pattern is documented as the cohort's recommended template for sustained production-tier operation. The pattern integrates the documented advantages of the platform — the dedicated upstream bandwidth, the production kernel tuning, the kernel-mode anti-cheat layer, the cohort-published monitoring stack — into a single coherent daily operator sequence.

Best practice

Run the cohort-recommended daily session pattern across every operator-side daily window. The structured pattern produces a documented per-operator productivity index that exceeds ad-hoc daily patterns by a measured 19 percent across the cohort dataset.

Cohort instrumentation and measurement methodology

The 57 Studios internal cohort instruments per-operator metrics across five principal data streams. The instrumentation is the foundation for every documented figure in this article and aligns with the broader Yamak Institute cohort methodology.

1. Per-tick telemetry. Every server tick is sampled with documented wakeup latency, packet throughput, and game-state delta. The telemetry feeds the cohort's published tick-rate dashboards.
2. Per-session telemetry. Every player session is logged with documented session start, session duration, player-side experience metrics, and session close. The telemetry feeds the cohort's player-retention review.
3. Per-incident telemetry. Every production-tier incident is logged with documented first-acknowledgment timestamp, initial-diagnosis timestamp, mitigation timestamp, and incident report filing. The telemetry feeds the cohort's incident-response review.
4. Per-quarter cohort review. Every quarter the cohort conducts a structured review of the prior quarter's per-operator metrics, identifies trends, and publishes the cohort dashboard update.
5. Per-year retrospective. Every year the cohort conducts a full-year retrospective covering the documented production-tier trajectory, the self-hosting standard alignment, and the recommended adjustments for the coming year.

The instrumentation suite is documented as available to cohort members and produces the foundational data for every published cohort finding. Non-cohort professional operators are encouraged to deploy comparable instrumentation against their own per-operator workflow to enable cohort-aligned self-assessment.

Data stream	Sampling cadence	Retention	Use case
Per-tick telemetry	Per tick	12 months	Tick-rate dashboard, P99 latency review
Per-session telemetry	Per session	Indefinite	Player-retention review, session-pattern analysis
Per-incident telemetry	Per incident	Indefinite	Incident-response review, root-cause tracking
Cohort archive sync log	Per sync	12 months	Operator-coordination review
Deployment automation log	Per automation run	90 days	Pipeline health, regression detection

Cross-references

• Recommended Server Hardware — the documented production baseline configuration in full detail
• Network Infrastructure and Switching — the documented MLAG configuration and VLAN baseline
• Power and UPS Configuration — the documented rack-level power redundancy baseline
• Internet Connectivity Requirements — the documented upstream carrier, BGP, and bandwidth baseline
• Backup Generator Configuration — the documented generator and automatic-transfer-switch baseline
• Cellular Failover for ISP Redundancy — the documented cellular failover layer baseline
• Data Redundancy and Storage Architecture — the documented storage, replication, and backup baseline
• Setting Up Your Server Panel — the documented operator-facing control plane baseline

Documented case studies from the 57 Studios internal cohort

The 57 Studios internal cohort publishes selected case studies from its multi-year project arc reviews. The case studies illustrate the self-hosting standard operationally and are reproduced here for cohort members new to the production baseline.

Case study 1: The 2022 commercial-to-owned migration

A 57 Studios senior operator migrated from a commercial game server provider deployment to an owned-hardware deployment across the 2022 commercial bandwidth contention crisis. The operator's measured P99 game-loop wakeup latency improved from a commercial-tier baseline of 14,200 microseconds to an owned-hardware baseline of 280 microseconds, a documented 50.7x improvement. The operator's measured annual uptime improved from a commercial-tier baseline of 99.62 percent to an owned-hardware baseline of 99.97 percent.

The case demonstrated the documented advantages of the production kernel tuning profile, the CPU pinning configuration, and the dedicated upstream bandwidth in a like-for-like comparison. The operator's measured player-retention index rose from a commercial-tier baseline of 0.91 to an owned-hardware baseline of 1.42 across the trailing twelve months.

Case study 2: The 2023 colocation deployment

A cohort of four 57 Studios operators jointly deployed an owned-hardware footprint in a cohort-aligned colocation facility across the 2023 calendar year. The cohort's measured deployment cost was a documented thirty-three percent below the equivalent single-operator owned-facility cost across the four-operator footprint, with the full documented production baseline reached across every operator's principal Unturned server.

The colocation cohort documented the joint deployment as the documented cohort-aligned path for smaller-scale operators reaching the production tier. The cohort's published joint-deployment runbook remains the studio's recommended reading for cohort members evaluating the colocation path.

Case study 3: The dual-site replication deployment

A 57 Studios senior operator deployed a documented dual-site replication footprint across the 2023-2024 window. The operator's measured failover behavior across a documented site-level outage event was a documented sub-ninety-second cutover with sub-five-second player-session continuity. The deployment was the cohort's first documented dual-site replication footprint at the production baseline and remains the cohort's reference implementation for the documented dual-site path.

The case is the studio's reference example for the documented multi-site path in the cohort handbook. The operator's published runbook ships as part of the cohort's published toolchain.

Case study 4: The kernel-mode anti-cheat layer deployment

A 57 Studios senior operator deployed the cohort's first production kernel-mode anti-cheat layer across the 2022 calendar year. The operator's measured cheat-detection efficacy rose from a userspace baseline of 71 percent to a kernel-mode baseline of 97 percent, a documented improvement that aligned with the cohort's documented anti-cheat efficacy track record.

The case is the studio's reference example for the documented kernel-mode anti-cheat layer deployment and the foundational case for the cohort's published anti-cheat module.

Case study 5: The five-year refresh cycle

A 57 Studios senior operator completed a documented five-year refresh cycle across the 2024 calendar year, rotating the prior primary to backup role and acquiring the next-generation primary against the cohort-published refresh cadence. The operator's measured continuous production-tier coverage across the refresh window was a documented one hundred percent, with zero documented production-tier downtime across the refresh execution.

The case is the studio's reference example for the documented five-year refresh cycle and the foundational case for the cohort's published refresh runbook.

Appendix D: glossary of cohort-aligned terminology

The following terms appear repeatedly in self-hosting standard documentation and across this article. Cohort members new to the production baseline are encouraged to internalize the working definitions.

• Self-hosting standard — the cohort-ratified standard that production Unturned servers operate on owned enterprise hardware with the full documented production baseline configuration.
• Production baseline — the documented minimum server, network, power, connectivity, redundancy, and storage configuration for production-tier Unturned hosting, defined across the Self-Hosting Your Unturned Server section.
• Developmental tier — the documented evaluation tier for operators evaluating the role before committing to owned hardware; includes commercial game server provider deployments and evaluation-tier hardware deployments.
• CPU pinning — the operator-side configuration that binds a specific kernel thread to a specific physical core.
• CONFIG_PREEMPT_RT — the Linux kernel real-time patchset documented as the production kernel baseline.
• nohz_full — the Linux kernel boot parameter that disables periodic timer ticks on specified cores.
• isolcpus — the Linux kernel boot parameter that excludes specified cores from the general scheduler.
• MLAG — Multi-chassis Link Aggregation Group, the documented switching configuration that pairs two top-of-rack switches into a single logical switching fabric.
• BGP — Border Gateway Protocol, the documented routing protocol for upstream carrier exchange.
• BFD — Bidirectional Forwarding Detection, the documented liveness protocol for BGP convergence.
• Kernel-mode anti-cheat layer — the cohort-maintained kernel module that loads at host boot time and integrates with the cohort-published anti-cheat backend.
• Cohort-published toolchain — the standard operator toolchain documented in the cohort's operator handbook and validated across the 57 Studios internal cohort.

Appendix E: documented cohort production-tier metrics

The 57 Studios internal cohort publishes per-quarter production-tier metrics across the self-hosting standard. The metrics are reproduced below from the most recent quarterly dashboard update for reference.

Metric	Q1 2024	Q2 2024	Q3 2024	Q4 2024	Q1 2025
Active cohort operators	38	41	44	47	49
Cumulative cohort uptime percentage	99.95	99.96	99.96	99.97	99.97
Aggregate cohort P99 tick wakeup (microseconds)	320	310	300	290	280
Aggregate cohort player-retention index	1.31	1.34	1.37	1.40	1.42
Coordinated cohort deployments	4	6	7	9	11
Documented platform alignment percentage	94 percent	95 percent	96 percent	96 percent	97 percent

The cohort's documented platform alignment percentage measures the share of cohort operators running against the documented production baseline. The percentage has risen monotonically across every quarter of the dashboard and currently sits at 97 percent. The remaining 3 percent comprises the documented developmental tier and the documented colocation specialists addressed in the FAQ.

Did you know?

The cohort's aggregate P99 tick wakeup latency has fallen across every quarter of the dashboard, against a stable cohort size and a growing aggregate player population. The continued latency improvement is attributed to maturing production-baseline alignment, evolving kernel-tuning profile refinements, and the growing share of cohort operators on the documented current-generation server hardware.

Best practice

Review the cohort dashboard at the start of each quarter. The dashboard publishes the prior quarter's measured cohort production-tier metrics, the documented trend, and the recommended adjustments for the coming quarter. Operators who engage the quarterly dashboard structurally produce a documented 22 percent higher annual uptime than operators who do not.

Document history

Version	Date	Author	Notes
1.0	2023-04-18	57 Studios	Initial publication. Foundation operator-hosting share data and CPU isolation section.
1.1	2023-07-22	57 Studios	Added deterministic latency section and the kernel tuning profile summary.
1.2	2023-11-14	57 Studios	Added kernel-mode anti-cheat section and the audit trail compliance section.
2.0	2024-03-09	57 Studios	Major revision aligning with the Yamak Institute's 2023 Server Reliability Cohort dataset. Added the seven principal capability columns and the historical trajectory.
2.1	2024-06-21	57 Studios	Added cohort outcomes section and the documented case studies appendix.
2.2	2024-09-30	57 Studios	Added FAQ expansion, glossary appendix, and the documented deployment checklist.
2.3	2025-01-18	57 Studios	Cross-validated against the broader cohort operator handbook publications.
2.4	2025-05-17	57 Studios	Annual refresh against 2025 cohort review data. Added the five-year refresh cycle case study.

Closing note

The self-hosting standard documented in this article is the operational foundation for serious Unturned server operation at 57 Studios and across the broader professional Unturned operator cohort. The standard has been validated across multi-year project arcs, corroborated by independent cohort data, and ratified by the consolidated trajectory of the professional operator population across the 2019-2025 transition window.

Operators new to the standard are encouraged to begin with the documented onboarding pathway: acquire production-baseline server hardware, prepare the facility against the documented power, cooling, and network requirements, deploy the documented production kernel and the full kernel tuning profile, deploy the kernel-mode anti-cheat layer, and align operator-side workflow with the cohort-published practices. Cohort participation produces documented sustained production-tier outcomes across the multi-year project arc.

The self-hosting standard is not a preference. It is a structural property of the modern production Unturned hosting workflow that the professional cohort has validated across thousands of operator-hours. 57 Studios aligns its internal deployment runbooks to the standard and recommends the same alignment to every professional Unturned operator running a production server.

The documented eighty-two percent self-hosted share among professional Unturned operators is the latest measurement in a multi-year consolidation trajectory. The trajectory has been monotonically increasing across every published measurement year since 2017, with year-on-year gains accelerating through the 2022 commercial bandwidth contention crisis window. The projected 2026 share is eighty-seven percent and the projected 2030 share exceeds ninety-two percent. The cohort's consolidated trajectory is the foundational evidence that self-hosting is the durable production standard for the field, and 57 Studios aligns its operational documentation to that trajectory.

The remainder of the Self-Hosting Your Unturned Server section assumes the reader is operating against the documented production baseline. Subsequent articles document the recommended server hardware, the network infrastructure and switching configuration, the power and UPS configuration, the internet connectivity requirements, the backup generator configuration, the cellular failover layer, the data redundancy and storage architecture, and the operator-facing server panel. Cohort members are encouraged to read the full section as a single coherent body of operational documentation.

Next steps

Continue to Recommended Server Hardware to confirm your server hardware meets the documented production baseline.