Dedicated Game Server Hosting Cost (2026): CPU, RAM, Egress

A dedicated game-server bill is a capacity-planning problem, not a “how much does 1,000 CCU cost?” lookup. Two games with the same peak CCU can have radically different bills: one may hold 100 players in a lightweight process for 15-minute sessions, while another runs 8-player physics-heavy worlds for hours. The host sees CPU time, memory, network and occupied capacity, not your marketing MAU.

Start with player-hours, not peak CCU

Peak CCU is useful for sizing the top of the fleet, but monthly cost is driven by the area under the concurrency curve. If you have telemetry, integrate the curve directly. Before launch, use a measured or explicitly assumed average-to-peak ratio and make that assumption visible.

average_ccu = measured_average_ccu
# or, before launch:
average_ccu = peak_ccu * measured_avg_to_peak_ratio

player_hours = average_ccu * billing_hours
session_hours = player_hours / players_per_session
active_process_hours = session_hours * processes_per_session

processes_per_instance = min(
  cpu_fit,
  ram_fit,
  network_fit,
  engine_or_license_fit
)

active_instance_hours = active_process_hours / processes_per_instance
buffered_instance_hours = active_instance_hours * (1 + ready_capacity_fraction)

compute_cost = buffered_instance_hours * instance_hourly_rate

For a normal one-process-per-match dedicated server, processes_per_session = 1. Persistent worlds and MMO-style shards need a different model because a process can remain alive without a full session of players. The important point is that players per process and processes per instance are load-test outputs, not genre constants.

Estimate egress separately

Measure bytes sent by the server during a representative match. If your telemetry is in average outbound megabits per second per connected player, a useful conversion is:

egress_gb ≈ avg_outbound_mbps_per_player * player_hours * 0.45
network_cost = egress_gb * egress_rate_per_gb

total_hosting_cost =
  compute_cost + network_cost + storage + image_registry + orchestration + logs + support_ops

The 0.45 factor converts 1 Mbit/s sustained for one hour to roughly 0.45 GB. Use your measured payload, compression and send cadence. Do not use a generic “tick rate × state size” guess once you have a real build.

Also do not assume bandwidth is always the largest line item. Current providers deliberately use different billing shapes:

2026 example	Compute shape	Network shape	What it means for your model
Edgegap Edge Cloud	$0.00115/vCPU/min, usage-based	$0.10/GB egress	Model compute minutes and outbound GB independently.
Gameye on-demand	$0.07/vCPU-hour for 1 vCPU : 2 GB, billed per second	Egress included	Bandwidth still affects technical capacity, but not a separate invoice line.
Gameye reserved	$0.027/vCPU-hour for 1 vCPU : 2 GB	Egress included	Baseline capacity can be cheaper than burst capacity; model the mix.
GameLift Servers generation 6+	Instance-hour pricing, On-Demand or Spot	Eligible network bandwidth is $0 in supported regions outside China	For eligible fleets, compute/capacity can dominate because the egress line disappears.

Those rates are snapshots, not universal recommendations. Region, CPU generation, RAM ratio, commitments, support and workload constraints still matter. Re-check the linked vendor price sheets before budgeting a launch.

CPU vs RAM vs network: profile the real server

The cheapest instance is the smallest one that satisfies all of your constraints with safe headroom. Typical constraints include:

• single-thread CPU: a simulation thread misses its frame/tick budget before aggregate CPU is full;
• aggregate CPU: several independent processes saturate the host;
• RAM: worlds/assets/pathfinding state cap process density;
• network: packet/bit throughput or NIC limits cap density even when CPU and RAM fit;
• startup latency: a technically cheap instance family is too slow to become ready for your queue target;
• storage or I/O: persistent-world checkpoints, mods or large asset reads change the shape.

Run a representative server build with bots or recorded workloads and increase session density until one of those constraints becomes unacceptable. That measured processes_per_instance is one of the most valuable numbers in your hosting model.

Ready capacity is not the same as idle waste

“On demand” does not necessarily mean boot a new instance after the matchmaker finds eight players and make them wait. Production fleets normally separate allocation from scale-out:

1. keep enough ready capacity to absorb near-term arrivals;
2. allocate a ready process immediately;
3. scale underlying capacity when the ready buffer falls below target;
4. drain and release surplus capacity as demand falls.

A starting approximation is:

required_ready_sessions ≈ peak_session_arrival_rate
                          * effective_scale_out_time
                          * safety_factor

That ready-capacity buffer costs money but buys lower queue-to-connect latency. Scale-to-zero can make sense for dev environments or slow queues if users can tolerate cold starts. A live competitive queue usually needs some ready capacity. Persistent worlds may need capacity even with zero connected players because the world itself is the workload.

Do you need a dedicated server at all?

Workload	Running authoritative process?	Typical cost driver
Async/turn-based match	Usually no	API/database requests and storage
Listen-server co-op	Host player runs it	Relay, discovery and backend services if used
Session dedicated server	For the session	player-hours, process density, buffer and network
Persistent world	Often beyond player presence	world-hours, baseline reserved capacity, storage/checkpoints

A listen server shifts simulation compute to a player; it does not make the whole architecture “free.” You may still pay for relay traffic, accounts, persistence, telemetry and discovery. Likewise, a free cloud tier is provider-specific: check CPU/RAM/runtime limits, egress, sleeping behavior and acceptable-use rules rather than assuming all free tiers ban, or permit, game traffic.

One VPS vs managed session hosting

A single VPS or bare-metal box can be the lowest-complexity paid step when a measured build fits and one location is acceptable. It is not automatically “a $5 server,” and the right instance size depends on the same profiling numbers above. You own deployment, monitoring, health replacement, capacity and incident response.

Managed session hosts buy a control plane and regional capacity model. They may allocate containers/processes from ready pools, mix reserved and burst capacity, or scale instances behind the scenes. Compare the full operating model, not just hourly CPU price.

Three useful cost metrics

• Monthly total: the number finance ultimately pays.
• Cost per player-hour: monthly_hosting_cost / player_hours; useful across different CCU curves.
• Cost per session-hour: useful when sessions have stable party sizes but variable audience scale.

Cost per peak player can still be shown as a capacity statistic, but it is a poor optimization target because a brief launch spike and a sustained all-day peak produce the same denominator.

Worked model: what to measure before asking for a quote

A useful hosting worksheet contains these inputs:

• peak CCU and hourly/daily CCU curve;
• average session duration and players per session;
• vCPU and RAM per game-server process at target player count;
• single-thread frame/tick headroom;
• measured average and burst outbound Mbps per player;
• processes per instance/host;
• server startup-to-ready time;
• target queue-to-connect latency and resulting ready buffer;
• regions and regional concurrency split;
• persistent-world hours, checkpoint/storage volume and retention if applicable.

With those numbers, vendor calculators become useful. Without them, a “1,000 CCU” quote mostly reflects the vendor's assumptions rather than your game.

Where Crux fits

Crux is primarily the backend-of-record side of this diagram: player identity, durable documents, economy/inventory primitives, leaderboards, live configuration and server registry. Those services can remove the need for a continuously running process from async/turn-based workloads, and a dedicated server can use them outside its simulation hot path.

The generic registry can track server heartbeats and metadata. Crux's current built-in matcher is an exact game_mode + region pairer; it is not an SBMM/party/backfill allocator. Single-use Runtime join tickets and managed allocation belong specifically to the capacity-gated closed alpha Runtime, currently a narrow Godot/Linux/EU ephemeral-session product, not to every server registered with Crux.

The Crux cost calculator compares persistent-backend/BaaS workload costs; it is not a dedicated game-server hosting quote. Use this page's player-hour/process-density model for the game-server fleet, then model the backend layer separately so you do not hide one bill inside the other.

For the operational side of that fleet, continue with the game-server orchestration guide. For the architecture decision itself, see listen server vs dedicated server vs managed hosting.