Where to Host a Headless Game Server on Almost No Budget (and When You Don't Need One)

The question gets asked in some form every week: "where can I host a headless Godot server for free? I'm broke." The replies are usually a list of hosting providers, which skips the part that actually decides your bill. Before you pick a host, work out which of these three things you are hosting - because two of them do not need a server you rent by the month.

First: do you need a process, or a place to keep state?

Multiplayer is not one requirement. It is at least three, with wildly different costs.

• Real-time authoritative simulation. Shooters, physics, anything where the server must decide what happened 20-60 times a second. This needs a process running for the whole match, close to your players. This is the expensive one.
• Session co-op. Four friends in a survival world. Somebody's machine can host it. You need help with discovery and connection, not with simulation.
• Async / turn-based / competitive-by-numbers. Turn-based PvP, asynchronous raids, daily challenges, ghost racing, leaderboards, idle games. Nothing needs to be running between turns. You need durable state and a way to notify the other player.

That third category is where most "how do I afford a server?" questions actually live, and the answer is that you do not need a game server at all. You need somewhere to store a match document and read it back. An HTTP API and a database do it, they cost approximately nothing at indie volume, and there is no process to keep alive, monitor, or restart at 3am. If your game is async PvP, stop shopping for servers.

What an always-on box actually costs

If you do need a real-time server, the cost model is not what beginners expect:

• CPU is usually cheap. A headless build with simple gameplay serves a surprising number of concurrent players on one modest core. Physics-heavy or large-world games break this rule fast.
• RAM is the real constraint per instance. Each match instance holds a world. Multiply by concurrent matches and that is your box size. This is the number that decides whether you fit on the smallest tier.
• Bandwidth is the bill that surprises you. State updates at tick rate, per player, for the length of a match, add up. Egress is metered on most clouds and is frequently the largest line item. Bare-metal and budget VPS providers usually include far more transfer for the money than the big clouds do, which is why so many indie multiplayer games sit on cheap VPS boxes rather than on a hyperscaler.
• Your time is a cost. Patching, restarting a wedged instance, keeping builds in sync, watching logs. It does not appear on the invoice and it is often the biggest expense.

The ladder, cheapest first

1. Player-hosted (listen server or P2P). Genuinely free to you, and how most small co-op games ship. The costs are real but they are not money: NAT traversal, host advantage, and the game dying when the host quits. Worth reading the honest comparison of P2P, relay and dedicated before committing, because the trust model differs sharply.
2. Relay. You do not run the simulation, you just pay for traffic to pass through a relay so players can connect without port forwarding. Cheap, solves the NAT problem, keeps the host-advantage problem.
3. Free-tier compute. It exists and it works for prototypes and jams. Read the terms: instances that sleep when idle, hard monthly transfer caps, and clauses that exclude game servers are all common, and none of them are visible until launch day. Treat it as a test environment.
4. One cheap VPS. A few dollars a month, generous included transfer, root access, entirely predictable. This is the honest default for a first paid step, and plenty of shipped indie multiplayer games never outgrow it. You own the ops.
5. On-demand allocation. Boot an instance when a match starts, shut it down when it ends. This is what makes real-time multiplayer affordable for a game with evening peaks instead of constant load - you pay for matches, not for idle time. It requires an allocator that knows which instances are live, which is a primitive worth understanding rather than something to hand-roll.
6. Managed game hosting. Someone else runs the boxes and the updates. Costs more per unit and buys back your evenings.

The mistake that costs the most

Paying for a 24/7 instance to serve a game that has players for two hours an evening. A small game with a healthy community might see real concurrency for a few hours a day and near-zero the rest of the time, and a rented box charges the same for both. Two fixes: allocate on demand (boot per match), or freeze idle instances so an empty world stops consuming a paid slot. Either turns "always-on" into "on when someone is playing", which is usually a large multiple of difference in cost.

The second most expensive mistake is running a full authoritative server for a game that never needed one - see the previous section. A turn-based game on an always-on box is paying rent on an empty room.

When you genuinely do need the box

Do not talk yourself out of a dedicated server if you are building one of these:

• Competitive real-time play where fairness matters, because a player-hosted match gives the host authority over the truth.
• Physics or simulation the clients cannot be trusted to agree on.
• Persistent worlds that must keep ticking when no specific player is present.
• Anything where you need server authority for anti-cheat reasons rather than technical ones.

If that is you, the question is not "free or paid" - it is "on-demand or always-on", and the answer is almost always on-demand once you have more than one region to cover.

FAQ

Can I host a headless Godot or Unity server on free-tier cloud compute?
For development and jams, yes. For a launch, check three things in the terms: whether instances sleep when idle, what the monthly egress cap is, and whether game-server traffic is permitted at all. Free tiers are optimised for low-traffic web apps, and a tick-rate game server is not that.

Is a $5 VPS enough for a small multiplayer game?
Often yes, for a handful of concurrent matches of a non-physics game, and it is where a lot of shipped indie multiplayer actually runs. Watch RAM per instance first and included transfer second. You are trading money for your own ops time.

My game is turn-based. Do I need a server?
Not a running one. You need durable storage for match state, a way to tell the other player it is their turn, and validation so a client cannot submit an illegal move. That is an API, not a box, and it is dramatically cheaper.

How do I avoid paying for empty servers?
Allocate per match and shut down after, or freeze idle instances. Both need something that tracks which instances exist and whether anyone is on them, which is the job of a server registry with heartbeats.

Where Crux fits

Crux covers the part that is not the box: player accounts, saves, leaderboards and match state over plain HTTP, so an async or turn-based game needs no game server process at all. When you do run real servers, Crux gives you the registry side - instances register and heartbeat, players discover them, and matchmaking hands out a single-use join ticket - so you can allocate on demand and stop paying for idle worlds. It works the same whether the boxes are ours, a cheap VPS you rent, or a machine a player runs at home. For the decision itself, self-hosted versus managed lays out the tradeoffs, and co-op without netcode covers the session case.

The one-line version: work out whether you need a process or a place to keep state. Most people asking where to host a server cheaply turn out to need the second one.