Open source tournament software

What to look for in something self-hosted

One process rather than five. A tool that needs a database server, a cache, a queue and a web server is a tool that will be down when you need it and that nobody at the club can fix.

A file-backed database, so the backup is a file you can copy.

No dependency on an external service to render or compute anything, or the offline case is not really offline.

How Whistle.day is built

The backend is PocketBase used as a Go framework rather than as a downloaded binary — the tournament logic is compiled in, so `go build` produces one server with the generators, standings and slot resolution inside it. SQLite underneath, so the data is a file.

The frontend is a static build served by the same process. There is nothing else to run: no separate database, no cache, no queue, no worker.

The generators are Go and there is exactly one implementation of them. They used to be duplicated in TypeScript so the browser could preview a draw; that is gone, and preview goes through the server with a dry-run flag. Two implementations of bracket seeding is how brackets drift.

Running it yourself

Build the binary, run the migrations, serve. The whole test suite is `go vet`, the unit tests and a smoke run that boots a real server on a temporary data directory and plays an entire tournament through the REST API — a two-pool group stage, a playoff seeded from it, then a double elimination and a Swiss out to the end.

That last part is the only way to find out whether a bracket deadlocks or a round ever fails to draw itself, which is why it is the check that matters.

Common questions