Running the servers

Kacky runs a fleet of game servers. There are the permanent hunting servers, plus extra ones spun up for each event, and none of it is set up by hand. The whole fleet is described in one place and brought to life with a single command. This is the part we're proud of.

Everything is written down, nothing is clicked together

The setup lives in one Ansible repository. Ansible is a tool that reads a description of how the servers should look and then makes real servers match it. The servers, their settings, which plugins they run, how much power each one gets: all of it is text in that repo, versioned like any other code.

That's the whole trick. There's no server that someone hand-configured and now nobody dares touch. If a box dies, we don't nurse it back to health. We throw it away and rebuild an identical one from the description. Reproducible, not precious.

Templates: describe once, stamp out many

A game server needs a pile of fiddly configuration: the Trackmania 2020 settings, the map list, how the controller is wired up. We keep those as templates, blueprints with the specifics left blank. When a server comes up, the blueprint gets filled in with that server's details and turned into its real config.

On top of the templates sit profiles, a short description of a kind of server (a Kacky Reloaded hunting server: these plugins, this player limit, these settings). Want ten identical servers? You don't configure ten servers. You point the profile at ten machines and let the templates stamp out ten identical setups.

From nothing to running

Bringing servers up is one flow, start to finish:

1. Provision. Rent the machines from Hetzner, our server sponsor, and give them their names and network.
2. Configure. Drop each server's filled-in config and its controller onto the box.
3. Start. Bring the Trackmania 2020 servers and their controllers online, ready for players.

Kick it off, walk away, come back to a working fleet. Standing up ten servers from scratch takes about seven minutes: provisioning, configuring, and starting, the whole lot. The same by hand would be an afternoon of careful, error-prone clicking.

Dev and prod, kept apart

We don't test on the live servers. There's a separate dev environment, a full copy of the setup where changes get tried out first, and a prod environment, the one players actually use. A change only reaches prod once it's proven itself on dev. A small utility server runs the shared bits everything leans on, like the message bus. It's the same templates and the same playbooks throughout, just pointed at different machines.

What still needs a human

The build itself runs on its own, but a few things are left to a person on purpose:

• Setting up the secrets, once. The credentials a deploy needs (a Hetzner access token, the server passwords) are kept encrypted. Someone adds them once per environment, and after that they stay locked away in the repo.
• Unlocking them at deploy time. Because those secrets are encrypted, a deploy asks for the password that unlocks them. No password, no deploy. That's what keeps the keys out of the repo in plain text.
• Deciding to create or destroy machines. Spinning up or tearing down real, paid servers is deliberately not a one-click button. A person chooses to do it, so nobody wipes a live fleet by accident.
• Pressing go. Someone still starts the run. During an event we deploy by hand rather than automatically, so a routine update never interrupts people mid-hunt.

Terminal or browser, your call

None of this needs a terminal wizard. Every operation (deploy a fleet, stop the hunting servers before an event, start them again after, restart just the controller without kicking players off) can be run two ways: a single command for people who like a terminal, or a button in the browser for everyone else. Same actions, same result. Pick whichever you're comfortable with.

It's not perfect, but it's great

We'll be honest: there are rough edges. Some steps still need a person to kick them off, a few things are held together with a little tape, and the whole thing grew over time rather than from one grand plan. But the core is genuinely good. The platform is reproducible, a wiped server is a seven-minute problem instead of a disaster, and anyone on the team can bring the fleet up or down. Nobody has to be the one person who "knows how the servers work."