Teeworlds

Last reviewed Sep 13, 2026 · 755 words

Here is the entire configuration for a public Teeworlds capture-the-flag server:

sv_name "Friday CTF"
sv_port 8303
sv_map ctf5
sv_gametype ctf
sv_max_clients 16
sv_rcon_password change-this
sv_register 1

Save it as autoexec.cfg, run teeworlds_srv -f autoexec.cfg, open UDP 8303, and you have a game server that 16 people can join and that uses less memory than a browser tab. Teeworlds has been doing this since 2007, it is Zlib-licensed, and it is the easiest multiplayer server in the games category to host. The catch is not technical: the crowd that plays it moved to a fork years ago.

The server is one binary and one text file

There is no database, no web panel, and no Docker image to speak of, because none is needed. On Debian and Ubuntu, apt install teeworlds-server gives you the binary and the stock maps; the upstream release tarball from teeworlds.com does the same for any Linux, Windows, or macOS box, and building from the C++ source takes a couple of minutes. The catalogue's 128 MB floor is generous; the process itself sits at a few tens of megabytes and CPU is negligible until dozens of players are on it.

Everything is set through the same config keys, in autoexec.cfg or live over rcon. sv_gametype takes dm, tdm, or ctf; sv_scorelimit and sv_timelimit end rounds; sv_maprotation "ctf1 ctf2 ctf5" cycles maps; sv_motd sets the join message; password makes the server private. That is 90 per cent of what a host ever touches.

UDP 8303, and whether to register with the master

The game is UDP only, one port, default 8303. Forward it on the router or open it in the firewall and clients can connect by IP. sv_register 1 announces the server to the public master list so it appears in the in-game browser, which is how strangers find you; set it to 0 for a friends-only server behind a shared password. On a VPS, that is the difference between a quiet private box and a public one that needs an admin present.

Running it under systemd is the only extra step worth taking on a headless host: a unit with ExecStart=/usr/bin/teeworlds_srv -f /etc/teeworlds/autoexec.cfg, Restart=always, and a dedicated user. LinuxGSM has a Teeworlds script if you already manage other game servers with it, and it adds monitoring, updates, and backups in the same shape as its other 100-plus servers.

Maps, mods, and rcon

Custom maps are .map files dropped into the data/maps directory; the community has thousands, and the in-game editor is good enough that people make their own. Mods are a different matter: Teeworlds mods are compiled server binaries, not scripts, so running a modded gametype means building or downloading a different teeworlds_srv. Rcon is built in: press F2 in the client, enter the sv_rcon_password, and you can kick, ban, change maps, and edit any setting without touching the file. Set the password to something real, because rcon on a public server is a full admin console.

DDNet is where the players went

Vanilla Teeworlds gets a release every few years and has a small, loyal player base. DDNet started as a mod for the cooperative racing gametype, became the actively developed client and server most people play on, and now has the bigger player count, the bigger map library, the Steam listing, and a continuous release cadence. It is the bigger sibling in every sense, and it is backwards-compatible enough that vanilla players can join a DDNet server for the classic gametypes.

So the honest question for anyone hosting is which crowd you want. A vanilla server is the right pick for a LAN party, a classroom, or a group of friends who want deathmatch or CTF exactly as it was. A DDNet server is the right pick if you want strangers to show up. Xonotic and Luanti sit in the same "light, free, self-hostable" bracket if the 2D shooter format itself is the sticking point.

What I'd do

For friends, put the 7-line config above on any Linux box you already have, sv_register 0, a password, and a systemd unit; it costs nothing measurable and you will forget it is running. For a public server, host DDNet instead and use the same knowledge, because the config keys are a superset of these. Either way, keep sv_rcon_password long and the UDP port the only one open.