If you have ever wondered why one Haxball room feels crisp and the next one feels like playing underwater, the answer is almost always the host. Haxball has no central match server: one machine simulates the physics and everyone else sends inputs to it and receives the resulting world state back. That machine is the host.
Everything else in this guide follows from that one fact.
What a host actually does
When you join a Haxball room, your client is not calculating the ball. It is sending "I'm pressing left" to the host and drawing whatever the host sends back. The host owns the simulation: the ball position, collisions, goals, who touched what and when.
That has two consequences that matter more than any other setting you will ever touch:
- The host must stay running. Close the tab, sleep the laptop, lose the connection — the room is gone, not paused. There is nothing to reconnect to.
- Every player's experience is their round trip to the host. Not to each other. If the host sits in Frankfurt and your players are in São Paulo, every single touch they make crosses the Atlantic twice before they see the result.
This is why "which server?" is not a detail. A room hosted 120 ms away from its players is a different game from one hosted 20 ms away — the ball arrives late, easy passes miss, and saves that looked clean do not count. We go deeper into why in the ping guide.
The headless host, in plain terms
Normally a Haxball host is also a player: someone opens a room in their browser and plays in it. That works, but the host is then tied to a person sitting at a computer.
Haxball's answer is the headless host — an official page at haxball.com/headless that runs a room with no player, no graphics and no sound. You give it a room configuration (name, map, max players, whether it is public) and it opens the room and keeps simulating it. Because there is nothing to draw, it is dramatically lighter than a playing client, which is what makes 24/7 rooms practical at all.
The headless host is also scriptable. It exposes a room object your script can hook into — players joining and leaving, chat messages, goals, team changes — which is how every Haxball bot, league system and auto-admin you have used was built.
Tokens: the part that catches everyone out
Opening a headless room is not anonymous. Haxball requires a headless token, which you get by solving a captcha at haxball.com/headlesstoken. The token authorises the room to open.
Tokens do not last forever. This is the single most common reason a self-managed 24/7 room quietly dies: the room was opened days ago, something restarted it, and there was no valid token to hand — so it never came back. If you host it yourself, you own that problem, and it will find you at 3 am on a match night.
A word on shortcuts. There are unofficial projects that reimplement Haxball's engine or protocol rather than running the official one. Haxball's developer has not sanctioned that approach, and rooms built on it can break with any change on Haxball's side. If you are building something you want to still exist next season, stay on the official headless host.
Three ways to run one
| Route | What it costs you | Where it breaks |
|---|---|---|
| Your own PC | Nothing in cash. A browser tab you must not close. | Your upload speed and your home connection become everyone's ping. Room dies when you sleep, reboot, or the tab gets throttled in the background. Your home IP is the room's IP. |
| A VPS you manage | A monthly server bill plus your time. You install the runtime, keep the process alive, handle tokens, monitor it, patch it. | The work never ends, and it is unglamorous work: process supervision, token renewal, restarts after crashes, picking a datacentre that is actually near your players rather than one that is cheap. |
| A hosting service | A monthly fee. Someone else owns the uptime. | You are trusting their location choices and their competence — so make them prove the ping rather than describe it. |
There is no universally right answer. Testing a script tonight? Your own machine is fine. Running a league with fixtures people have arranged their evening around? Something that stays up without you does.
Public and private rooms are not the same product
A private room is link-only. It does not appear anywhere; you share the URL with your community and that is the only way in. Good for scrims, training, staff rooms and anything you do not want randoms walking into.
A public room is listed in Haxball's in-game room list, so anyone browsing can find and join it. That is how communities grow — and it is scarce. Haxball itself limits how many rooms from one IP address show up in that list; in our experience the practical ceiling is two. Private rooms are not constrained the same way, so a single server can run a lot of those.
This is the real reason public room capacity costs more than private capacity everywhere you look: the slots are genuinely limited by the game, not by the host's hardware. The full comparison is here.
Pick the location from data, not from a map
Every hosting provider has a map with dots on it. A map tells you nothing — what you need is the number your players will actually experience. Two servers described as "Europe" can be 40 ms apart for a Turkish player.
So measure. Run a real round trip from a browser to each candidate location, over the same transport the game uses, and compare medians rather than best-case pings. If a provider cannot show you that, treat their location claims as marketing.
Measure it in three seconds
Our ping test opens a real WebRTC data channel to every HaxHost location — the same connection type a Haxball match runs on — and ranks them by measured median.
Run the ping testThe checklist before you go live
- Decide public or private. If you need a listed room, secure the slot before you plan around it.
- Measure ping from where your players are, not from where you are. If your community is Brazilian and you are in Portugal, your ping is the wrong number.
- Settle the map and rules first. Custom stadium, time and score limits, team locks — changing these later means restarting the room and re-sharing the link.
- Know who can admin. Decide whether admin is automatic, manual, or handled by a script, before 30 people are in the room.
- Have a plan for restarts. Ask specifically: if the room drops at 3 am, what brings it back, and does it come back with the same name and settings?
- Write the join link down somewhere permanent. A room that moves gets a new link; your community needs one place that always has the current one.
Where to go next
- The headless host in detail — what it can and cannot do, and what the room object gives your scripts.
- Why Haxball lags — what latency does to the physics, and which of it you can actually fix.
- Public vs private rooms — the slot cap, and which one your community needs.
- Room scripts and bots — auto-admin, draft systems, stats and the rest.