How to host your own agar.io server

What you're signing up for

Self-hosting means running open-source server code that has not been actively developed for a few years, on a machine that stays online for as long as anyone wants to play. You will pin a Node.js version, edit a config file or two, and keep an eye on it yourself. None of that is hard, but it is real work that the hosted route skips. The rest of this guide is the honest version of what that work looks like.

Pick a server implementation

They are all Node.js projects that descend from the original Ogar. Three are worth knowing about, and the gap between them is mostly about how painful the install is.

There is also a small wave of newer rewrites in Go and Rust (for example 8h9x/CellKitServer, a Go server created in late 2025 and still being pushed in 2026). They are genuinely new but have near-zero adoption, so treat them as a space to watch rather than a safe default.

Install and first run

Both are the same shape: clone the repo, install dependencies, and run the entry file. Get it running locally first, before you think about a server.

OgarII

git clone https://github.com/Luka967/OgarII
cd OgarII
npm install
cd cli
node index.js

On first run OgarII writes settings.json and log-settings.json into the cli/ folder. Edit cli/settings.json to change the port and the rules. First read the next section though, because on a modern Node this step crashes.

MultiOgarII

git clone https://github.com/m-byte918/MultiOgarII
cd MultiOgarII
npm install
cd src
node index.js

Config lives in src/settings.json. Unlike OgarII, this one starts on current Node with no native build.

The Node version wall (and why the error message lies)

OgarII's only dependency is the old native µWebSockets binding, [email protected]. On a modern Node, npm install appears to succeed (you get a deprecation warning and nothing else), and then the server crashes the moment you start it.

Booting OgarII on Node 24:

Error: Compilation of µWebSockets has failed and there is no pre-compiled binary available for your system. Please install a supported C++11 compiler and reinstall the module 'uws'.
    at .../node_modules/uws/uws.js:40:19
    at Object.<anonymous> (.../src/sockets/Listener.js:1:19)
Node.js v24.16.0

Here is the part no other guide tells you: that message is misleading. uws does not compile anything at all. It picks a prebuilt binary by your Node ABI version, and it ships binaries only for ABI 57, 59 and 64, which are Node 8, 9 and 10. There is no source in the package to build. So when the loader finds no binary for your Node, it prints the "install a C++11 compiler" line as a fallback. Installing a compiler changes nothing: this error was reproduced on a machine with gcc 13 already installed.

This also means the usual advice to "pin Node 16" does not work either. Node 16 is ABI 93, which is not in the bundle, so it fails the exact same way. Only Node 8, 9 or 10 will run stock OgarII.

The fix that actually works for OgarII:

nvm install 10
cd cli
node index.js

On Node 10 it boots (you will see OgarII 1.3.6 and the FFA gamemode start), and the only thing left is an EACCES error on port 443, because the default port is privileged. Set listeningPort to something like 8080 in cli/settings.json and it runs. The catch: Node 10 has been end-of-life since April 2021, so exposing it to the internet is a real security liability.

MultiOgarII on the same Node 24 machine:

Running MultiOgarII 1.6.3, a FOSS agar.io server implementation.
Game server started, on port 8080
Current game mode is Free For All

Because MultiOgarII uses pure-JavaScript ws, npm install adds a single package and it boots on current Node in under a second. Same machine, same Node: OgarII crashes on its native dependency, MultiOgarII just runs. If you want a public server without pinning an end-of-life Node, start with MultiOgarII.

You also need a client

The live agar.io site will not reliably connect to your own server, so you run a small open-source client that speaks the same protocol as your server. These are static web pages you host yourself.

The one rule that matters: client and server must agree on a protocol version. MultiOgar and MultiOgarII speak protocol 6, so use a protocol 6 client like Cigar3. OgarII speaks every version, so a protocol 6 client works, or you can use the modern branch of Luka967/Cigar for its native protocol. A mismatch simply will not connect.

OgarII's readme documents a console command, core.disableIntegrityChecks(true), to aim the official client at a private server. It historically worked, but the live agar.io client is rebuilt often and that hook may be gone, so do not build your setup around it. Ship a dedicated client instead.

Where to run it

Oracle Cloud Always Free is the popular choice. The Ampere ARM shape (VM.Standard.A1.Flex) gives an always-free 2 OCPU and 12 GB of memory per tenancy as of 2026, halved from the old 4 OCPU / 24 GB. Two caveats: "Out of host capacity" errors are common when launching this shape, and your home region is fixed at signup. ARM also makes native compiles harder, but that only bites OgarII (the uws build); MultiOgarII is pure JavaScript, so pairing MultiOgarII with the ARM free tier is painless.

The other always-free option is VM.Standard.E2.1.Micro: an AMD x86 box with 1 GB of RAM, up to two of them. Native builds are easier on x86, and it is fine for a few dozen players.

A Raspberry Pi at home costs nothing extra and gives low latency to local players. The limits are networking, not compute: many home connections use CGNAT (so you cannot forward a port inbound) and hand out a changing IP. A Cloudflare Tunnel solves both at once. Use the 64-bit Raspberry Pi OS.

Skip the serverless and PaaS free tiers for a live game loop. Render free spins the service down after 15 minutes idle and cold-starts in about a minute, which drops every connection. Railway has no permanent free tier in 2026 (a one-time credit, and a card is required). Netlify cannot hold a persistent WebSocket at all. Vercel now accepts WebSocket upgrades, but it cannot run a single long-lived, in-memory game process: connections die at the function time limit and reconnects land on different instances. An agar.io tick loop needs one process holding all player state, which none of these provide.

Making it reachable (wss)

If the client page is served over HTTPS, the browser will only open a wss:// (secure) socket, so your server needs TLS in front of it. Two clean ways to do that.

nginx reverse proxy (the load-bearing lines):

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

The Upgrade and Connection headers are what let the WebSocket handshake through; the raised proxy_read_timeout keeps idle sockets from being cut at 60 seconds. Pair it with certbot for the certificate. On nginx 1.29.7 and later, HTTP/1.1 to the upstream is the default; on older nginx add proxy_http_version 1.1; as well.

Simpler still: a Cloudflare Tunnel. It has full WebSocket support, the cloudflared daemon dials out (so there is no port to forward and it works behind NAT or CGNAT), and Cloudflare terminates TLS at its edge. For a home box this is usually the least-effort path to a working wss endpoint.

What this costs you over time

The honest ledger: uptime is now yours to keep, you patch the OS and Node yourself, and you deal with protocol drift as agar.io keeps changing. Nobody upstream is fixing these servers, so any bug you hit is yours to work around. For a small server among friends that is a fun weekend and a cheap box. For something you want to be reliably up for strangers, that ongoing maintenance is the real price.