Developer Tools

A scheduler that turns our game server off when nobody is on it

Built by Wendell Obispo

Our seven-person game server was running twenty-four hours a day for about six hours of use a week, so I made it learn our habits and switch itself off.

  • Builder email verified

    Verification

Type
Personal
Category
Developer Tools
Published
Jul 26, 2026
Updated
Jul 26, 2026
Built withGoPythonDockerSQLite
TopicsEntertainmentSustainability

About this project

What I built & why

Six of us have played on the same private server since university, and I have paid for it since 2021 out of a mix of nostalgia and being the one who knows how. The bill is small and the waste annoyed me disproportionately: the machine was up all week for a few hours of Saturday. Turning it off manually is obviously the answer and obviously nobody does it, including me, and worse, someone logging in to a dead server just stops trying. So the actual problem was never the switching off; it was switching on fast enough that nobody notices it was ever off.

The problem

It is for six friends who do not want to know any of this exists. It watches the server's connection attempts and its history of when people actually play, keeps the machine off outside the windows it expects, and brings it back within about ninety seconds when someone tries to connect. A tiny always-on listener holds the connection attempt, starts the machine, and tells the person to wait a moment. It also snapshots the world before each shutdown, which was not the point of the project and has turned out to be the most valuable thing in it.

What I owned

All of it. The listener is a small Go program on the cheapest always-on machine I could find, which answers on the game port, records the attempt, and triggers the start. The prediction is not machine learning and I want to be clear about that — it is a weekly histogram of past sessions with a bit of smoothing, which pre-warms the machine before the hours we usually play so that Saturday evening has no wait at all. I also wrote the snapshot and restore, and the small page that shows whether the server is up and, if not, why.

Technical & product decisions

I chose to pre-warm on a schedule derived from history rather than only starting on demand, because the ninety-second wait is fine on a Tuesday and unacceptable at the moment six people have agreed to meet. Cheap to build, and it turned the project from clever into invisible, which is the goal. I also decided against putting any of this in the game itself through plugins, which several guides suggest — the server software updates and breaks plugins, and I wanted something that would keep working while I ignored it for a year. It has now done exactly that.

Hardest challenge

The unglamorous hard part was shutting down safely. My first version killed the machine when the last player disconnected, which corrupted the world twice, once losing about an hour of building that a friend was not gracious about. What it needed was a proper drain: stop accepting connections, ask the game to save, wait for the save to finish, snapshot, then stop — with a timeout and a refusal to proceed if the save did not confirm. That sequence is about forty lines and took me three evenings and one apology to get right.

Result & impact

The bill went from around eighteen hundred pesos a month to under four hundred, which is not the interesting number. The interesting one is that the six of us have not noticed it: nobody has complained about a wait since the pre-warming went in two years ago, and the snapshotting has restored the world twice after unrelated disasters. I have not touched it in about fourteen months. It is the most satisfying thing I have built, entirely because of how boring it is to own.

Who else worked on it

One of the six is a much better game administrator than I am and wrote the save-and-drain sequence's requirements after the second corruption, which is a polite way of saying he told me exactly what I had done wrong.