How Much Does It Cost to Build and Run an Online Multiplayer Game? Part 1: Rolling Your Own

The worst time to find out about multiplayer hosting costs is after shipping, when the bill arrives. If online multiplayer is a key part of your project, you need to figure out how much it’s going to cost you to run and adjust your business plan accordingly.

This article gives you a model to predict those costs before you commit to a path or a technology. The formulas apply whether you self-host on bare metal, rent cloud instances, or buy a managed service, and there is an interactive calculator at the end so you can plug in your own game.

This is part one of two and covers just the method for working out what it costs to build and run a multiplayer backend yourself. Part two takes these numbers and compares rolling your own against managed services, including our own Reactor. That comparison is where our bias comes in, so it stays in part two; the method here does not depend on any of it.

The five costs

Every multiplayer game’s running cost reduces to five things:

1. Bandwidth (egress): the bytes your servers send to players.
2. Compute: the CPU and memory running the simulation or relay.
3. Backend services: matchmaking, accounts, persistence, analytics.
4. Cost to build it: the engineering time to get it working.
5. Cost to maintain it: the ongoing time to keep it running.

The first three are recurring infrastructure. The last two are labor, which for most teams is the larger number. The cost to build it is unique, as the entirety of that cost is paid prior to release. It is still an added cost and is amortized over a period of time. You can always separate that line item out and just include it in your game development budget if you want.

We will compute each, then total them with a worked example.

Concurrency: MACCU, CCU-months, and how they relate to MAU

Hosting cost scales with concurrent users, but “concurrent users” is a moving target. Getting it wrong throws estimates off by an order of magnitude. Player counts rise and fall on a daily cycle: a trough in the local pre-dawn hours, a climb through the day, an evening peak. You can watch this in public data. SteamDB charts concurrent players for individual games, and Steam’s own stats page shows the platform-wide curve. They all have the same general shape.

Two distinct numbers come off that curve, and they must not be conflated:

• Peak CCU: the height of the curve, the most players connected at once. You size your servers for this.
• MACCU (Monthly Average Concurrently Connected User): the average height across the month, which is the area under the curve divided by the hours in the month. You pay for this. It is a metric we defined in our kazap.io economics writeup; measure it by sampling CCU at a fixed interval (we used every 5 seconds) and averaging.

Estimating MACCU from peak. Before you have live data, you can estimate. The ratio of average to peak depends mostly on geography. A game concentrated in one region has a sharp evening spike and a deep overnight trough, so its average lands around 30 to 50% of peak. A game spread across the globe has staggered regional peaks that flatten the curve, pushing the average toward 50 to 65% of peak. The chart above is a single-region example at about 46%. Pick a ratio for your situation, then replace it with a measured number the moment you have one.

The billing unit: the CCU-month. To turn an average concurrency into something you can multiply by a price, use a CCU-month: one concurrent user, served for one full month. It is a usage unit, like a kilowatt-hour. The conversion is the cleanest part of this whole article:

Over one month, the CCU-months you consume equals your MACCU.

An average concurrency of 300 is 300 CCU-months that month, or 3,600 over a year at that level. The unit earns its keep by separating the two cost behaviors: bandwidth and metered compute scale with CCU-months, while capacity you provision up front scales with peak CCU. A game that peaks at 2,000 but averages 300 pays for 300 if its hosting is usage-metered, and closer to 2,000 if it runs fixed servers sized for the peak. That gap is often the single biggest lever on the bill. Per-CCU pricing models, used by relay services like Photon and in part by Coherence, bill against connected-user-time, which maps to CCU-months directly. Per-vCPU hosting bills compute time, which only maps to CCU-months if you scale capacity to match demand.

Where MAU comes in. Monthly active users is the number most teams quote, and on its own it is nearly useless for hosting estimates, because it says nothing about how long those users stay connected. Playtime is the link:

MACCU = MAU × (avg hours played per user per month) / 730

The 730 is hours in a month. This is just the user-hours your players generate, averaged over the month. Our kazap.io data shows how wide the gap can be: in its peak month, roughly 150,000 monthly active users produced an average concurrency of about 100, which is only about half an hour of play per user per month. That is normal for a casual .io game most people try once. A session-based competitive game or an MMO, where engaged players log dozens of hours a month, can have a MACCU-to-MAU ratio ten or twenty times higher. Two games with identical MAU can have hosting bills an order of magnitude apart, purely because of engagement. Reason from concurrency, not from MAU.

Line 1: Bandwidth

Bandwidth is usually the cost that scales hardest, and the one most often underestimated, because people count the game data and forget the wrapper around it. Build it up per player, per second, from four contributions:

Transforms. For each entity a player receives updates for, the position and rotation being synced. Uncompressed, a 3D transform is large, well over 30 bytes. Quantization plus a compact rotation encoding (the smallest-three quaternion trick) bring a general 3D transform to roughly 10 to 12 bytes on the wire: about 6 bytes for position at 16 bits per axis, about 4 for rotation, plus framing. A 2D game is smaller, around 3 to 4 bytes, because position is two axes and rotation is a single angle. From there, delta encoding and further compression push the average below the quantized size when motion is slow or predictable, sometimes under a byte, which is how dense crowds and .io games stay cheap. The figure is set by how much the motion varies, so use 10 to 12 bytes for a general 3D game and treat anything lower as a property of your game or your engine, not a given. See Glenn Fiedler’s snapshot compression writeup for the mechanics.

transform bytes/sec = entities_seen × bytes_per_transform × tick_rate

RPCs / events. Discrete events (a shot fired, a door opened). Count them per second and multiply by their serialized size. These are usually small relative to transforms unless your game is event-heavy.

NetVars / replicated properties. State that changes occasionally (health, ammo, score). Count the changes per second, not the variables: a value that does not change costs nothing on a delta-based system.

Protocol overhead. The part that gets forgotten. Every packet carries headers regardless of payload. Over UDP that is a 20-byte IPv4 header plus an 8-byte UDP header, and a reliability layer such as KCP adds about 24 bytes. So roughly 50 bytes per packet, and if you send one packet per tick per player, that overhead is paid every tick:

overhead bytes/sec = ~50 × packets_per_second   (≈ network tick rate)

At 30 Hz that is about 1.5 KB/s of pure header per player, before any game data. For a low-data game it can be most of the bill. TCP, websocket, and other reliable transports carry their own, often larger, overhead.

Putting it together. Sum the four into bytes per second per player, convert to a monthly figure per CCU-month, and multiply by your egress rate:

GB per CCU-month = (total bytes/sec) × 2,628,000 sec / 1,000,000,000
monthly bandwidth = GB_per_CCU_month × MACCU × egress_rate

Egress rates vary wildly by provider. Hyperscalers price egress as a profit center: AWS starts at $0.09/GB for the first 10 TB out of US-East. Developer-focused hosts are far cheaper, with Vultr at $0.01/GB overage and bare-metal providers often bundling a large transfer pool. A 10x difference in egress rate is normal, so this input matters as much as your byte count.

The trap that breaks the model: interest management. If every player sees every other player, entities_seen grows with the room, and per-player bandwidth scales with room size. A 16-player match is fine; a 200-player one is not, unless you cull what each player receives (only sync nearby entities). Decide early whether your game needs everyone to see everyone, because it changes the bandwidth line by an order of magnitude.

Line 2: Compute

Compute splits into two regimes:

Relay or light-authority games. The server mostly forwards messages and validates a little. CPU per player is low, so one modest instance serves hundreds of players. Compute is a minor line; bandwidth dominates.

Physics-heavy or fully authoritative games. The server runs the simulation: physics, AI, hit detection. CPU per player is high, so a single core might handle tens of players, not hundreds. Compute can rival or exceed bandwidth.

The honest way to price compute is per vCPU-hour, because that is the underlying resource whether you rent it or a managed service resells it. A current reference point: an AWS c7i.xlarge (compute-optimized, 4 vCPU) is $0.1785/hr on-demand in US-East, about $0.045 per vCPU-hour, and reserved or spot pricing cuts that substantially. Bare metal is cheaper per core if you keep it busy; managed services charge a premium for the operations they handle for you.

vCPU needed (at peak) = peak_CCU / players_per_core
monthly compute = vCPU_needed × $/vCPU-hour × hours_billed

The hours_billed term is where the peak-versus-MACCU distinction returns. Fixed servers sized for peak bill 730 hours a month whether full or empty. Autoscaled or per-minute capacity bills closer to your MACCU. The same game can have a 5x difference in compute cost based purely on whether capacity tracks demand.

Line 3: Backend services

Multiplayer is more than a game server. Budget for:

• Matchmaking / lobbies: often a small always-on service, or a managed feature.
• Accounts and auth: a managed identity provider, or your own. Many have generous free tiers below a threshold of monthly active users.
• Persistence: a database or key-value store for progression, inventory, leaderboards. Cost scales with reads/writes and storage.
• Analytics and telemetry: event ingestion and storage.
• Relay / NAT traversal (for peer or client-hosted topologies): STUN is cheap, TURN relays traffic and is billed like bandwidth.

For a small-to-mid game these often land in the tens to low hundreds of dollars a month, dominated by whichever service you have outgrown its free tier on. The point is to enumerate them, because they are easy to omit and then find on the bill.

Line 4: The cost to build it

This is usually the largest number, and the most overlooked, because it is labor rather than infrastructure. Anchor it in a defensible rate. The U.S. Bureau of Labor Statistics puts the median software developer wage at $133,080 (May 2024), with the 10th-to-90th percentile spanning roughly $80,000 to $211,000. Loaded cost (benefits, overhead) typically runs 1.25 to 1.4x salary, so call it roughly $50 to $150 per hour depending on seniority and region.

Now estimate the hours. Rolling your own authoritative netcode, with prediction, reconciliation, a serialization layer, and the backend services above, is a multi-month effort for an experienced engineer, and longer if it is the team’s first time. A conservative range for a production-grade custom stack is several hundred to a few thousand engineering hours. This can be reduced by employing a framework like Netcode for GameObjects/Entities, Mirror, or FishNet on Unity, but there is still some customization required to dial in the harder problems like prediction and bandwidth optimization.

AI coding assistants change this materially but not magically. GitHub’s controlled study found developers completed a specific task about 55% faster with Copilot, and real-world gains on novel systems work are usually smaller. A reasonable planning assumption is a 20 to 40% reduction in hours on the parts that are boilerplate-heavy (serialization, plumbing, tooling), and little speedup on the genuinely hard parts (netcode correctness, edge cases). Model it as a discount on your hour estimate, not a different category.

build cost = engineering_hours × (1 − ai_discount) × loaded_hourly_rate

Amortize this over the months you expect the game to run to compare it against the recurring lines.

Line 5: The cost to maintain it

Live multiplayer is never finished. Even with maximum automation (infrastructure as code, autoscaling, automated deploys, alerting), budget for:

• On-call and incident response: someone has to be reachable when a server falls over at peak.
• Updates: engine versions, dependency patches, security fixes, content updates that touch the netcode.
• Capacity tuning: as the player base grows and shifts regions.

Automation reduces the hours but does not zero them. A realistic figure for a stable, automated live game is a recurring fraction of an engineer: anywhere from a few hours a month for a small, quiet title to a substantial share of a full-time role for a busy one. Price it the same way, at the loaded hourly rate, and add it to the monthly total.

Worked example: a 32-player competitive shooter

Server-authoritative, 60 Hz network tick, hosted on metered cloud capacity. Peak 1,000 CCU, MACCU 300 (players come and go). Egress at a developer-host rate of $0.05/GB.

Bandwidth, per player. It is a 3D game, so a transform is about 12 bytes after quantization and rotation compression. (A 2D game would be nearer 3 to 4.)

That is 25,500 × 2,628,000 / 1e9 ≈ 67 GB per CCU-month. Across 300 MACCU: 20,100 GB × $0.05 = ~$1,005/month in bandwidth. (On AWS egress at $0.09 it would be ~$1,800; on a bare-metal transfer pool, close to zero.) Strong delta compression on predictable motion cuts the transform line well below 12 bytes, which is the lever an efficient engine pulls.

Compute: a 1-vCPU room holds the 32-player match, so peak needs ~31 vCPU; metered to MACCU it averages ~9 vCPU. At $0.045/vCPU-hour × 730 hours: ~$310/month (autoscaled). Fixed-for-peak would be closer to $1,000.

Backend: matchmaking, accounts, a small database, analytics: call it ~$150/month at this scale.

Recurring subtotal: ~$1,465/month at 300 MACCU.

Build: say 800 engineering hours for a custom stack, a 30% AI discount, at $130/hour loaded: 800 × 0.7 × $130 = ~$72,800 one-time. Over a two-year run that is ~$3,050/month amortized, several times the recurring infrastructure.

Maintain: a quarter of an engineer at $130/hour loaded ≈ ~$5,600/month.

The lesson the worked example makes obvious: for most teams the infrastructure (~$1,465) is the small number. The labor to build and maintain a custom stack (~$8,650/month amortized here) dwarfs it. That is the real decision, and it is why “build versus buy” is a cost question, not just an engineering one.

Next: is buying cheaper?

Those labor lines are exactly what a managed service removes, in exchange for pricing the infrastructure its own way, sometimes far higher. Part two runs this same example through Photon, Coherence, and our own Reactor, so you can see where buying wins and where rolling your own does.