Find How Small Teams Run Online Game Backends for Players on Tiny Budgets

The architecture diagrams that circulate in conference talks show online games running on fleets of servers, managed databases, global load balancers, and observability stacks with monthly bills in the tens of thousands. That is a reasonable picture of a game with millions of players. It is a terrible template for a two-person team launching a browser game that might have two hundred players on a good night.

Indie developers who succeed on small budgets tend to share a mindset. They read the big case studies for ideas but plan for their own scale, they compare hosting prices the way a careful shopper compares groceries, and they collect resources that champion doing more with less, from frugal hosting guides to pages like ankertoto built around the idea of a small starting stake. The result is often a backend that costs less per month than a streaming subscription and still gives players a solid experience.

Know your real numbers first

Budget planning starts with estimates, not tools. Before choosing any hosting, write down three numbers: expected peak concurrent players, messages per second per player, and how much state each match holds. A casual multiplayer puzzle game might see 50 concurrent players sending 2 messages per second each, with a few kilobytes of state per match. That workload fits comfortably on a single small virtual machine.

A fast-paced action game with 20 updates per second per player needs more, but even 200 concurrent players at that rate is 4,000 messages per second, which a single well-written Node.js or Go process can handle on a modest instance. The point is that most indie games overestimate their infrastructure needs by an order of magnitude.

A sample monthly budget

Here is a realistic setup for a browser game expecting up to a few hundred concurrent players, based on typical prices from mainstream providers. Prices vary by provider and region.

The total sits around 15 to 30 dollars per month. Serving the game client from a CDN keeps bandwidth costs near zero on the main server, a trick our article on browser caching explains in more detail.

The serverless temptation

Serverless platforms are often recommended to small teams because they charge per request and scale to zero. For APIs with spiky, infrequent traffic, this is genuinely cheap. For real-time games, it is frequently the expensive option. Persistent WebSocket connections and frequent small messages are exactly the pattern that per-request and per-connection-minute pricing punishes.

A rough comparison: 200 players connected for four hours a day on a serverless WebSocket product can easily cost more than a dedicated virtual machine running all month, and it adds cold-start latency on top. The usual advice to "go serverless to save money" assumes a request-response workload. For a game server, a single always-on machine is usually both cheaper and faster. Serverless remains a good fit for the surrounding pieces: account sign-up, leaderboards that update a few times a minute, and webhook handlers.

Squeezing more players from one machine

Once the backend runs on a small server, a few habits stretch its capacity further:

• Send deltas, not full state. Transmit only what changed since the last update. This can cut bandwidth by 80 percent or more in typical games.
• Use binary encoding. A compact binary format is smaller and faster to parse than JSON for high-frequency messages.
• Lower tick rates where players will not notice. A strategy game rarely needs 60 updates per second; 10 is often plenty.
• Profile before scaling. A single slow function in the game loop can halve capacity. Our guide to DevTools features most developers skip includes profiling tips that apply to server-side JavaScript too.

Planning for the good problem

Small teams often worry about what happens if the game suddenly becomes popular. The answer is to prepare a plan rather than pay for capacity in advance. Keep the server setup scripted so a second machine can be launched in minutes. Keep game state per match rather than global, so matches can be spread across servers later. Put a simple matchmaking step in front of game servers from day one, even if there is only one server behind it for now.

With that preparation, a sudden spike becomes an afternoon of work rather than a crisis. And if the spike never comes, the team has not spent a year paying for idle infrastructure.

Backups and the cost of losing data

The one area where small teams should never economise is backups. A cheap server is fine; a cheap server with no copy of the player database is a disaster waiting for a disk failure or a mistaken command. Losing a week of progress is one of the fastest ways to lose a small player base, and it is entirely preventable for the price of a coffee each month.

A sensible routine for an SQLite or small Postgres setup is a nightly snapshot copied to object storage in a different region, with seven daily copies and four weekly copies retained. Test a restore at least once a quarter by spinning up a temporary server and loading the latest snapshot. Teams that skip the restore test often discover, at the worst moment, that their backups were empty or corrupted. Writing the restore steps in a short document also means anyone on the team can recover the game, not just the person who set it up.

What players notice and what they do not

Players do not see your architecture. They notice latency, disconnects, and lost progress. A single well-placed server with good backups and sensible reconnect logic delivers a better experience than an elaborate distributed system that the team does not fully understand. Spending the saved money on a second region closer to a large group of players, or on a few more weeks of development, usually does more for the game than any amount of premature scaling.

Small budgets force clarity. Teams that embrace that constraint tend to build simpler systems, ship sooner, and keep their games running long enough to find an audience.