A prediction engine, server-side and fast.

A library, not a pile of endpoints

The prediction logic lives in its own package as pure functions: a save plus parameters in, an answer out, with nothing touching a network or a device. The API depends on it at an exact tag, not a floor, because the catalogs inside are derived from one specific build and "latest" is never the right answer. 26 test modules cover the library, 7 more cover the service.

An envelope that refuses to guess

Every response carries the same wrapper: whether the input is supported, how confident the answer is, which build and catalog produced it, and any warnings. A save from an unsupported build gets a refusal rather than a plausible wrong list. The client never has to work out whether an answer can be trusted, because the answer says.

• supported · confidence · build · catalog · warnings on every response
• Version gate refuses unsupported inputs outright
• One shape for every endpoint, so clients need no special cases

The slow path cannot starve the fast one

Most endpoints cost about 49ms, almost all of it the save parse. One does an exhaustive search and blocks for seconds. Left alone it would occupy every worker and stall everything behind it, so it gets its own semaphore: two searches per worker, a third waits, and it waits against a deadline rather than forever. Four workers on two CPUs, oversubscribed on purpose to keep the fast paths responsive while the slow one runs.

• 5s budget on fast endpoints, roughly 40x measured cost
• 60s budget on the search, deliberately under Cloudflare's proxy limit
• Concurrency capped per worker, queueing bounded

A container that owns nothing

The service parses untrusted input, so it runs as a non-root user with a read-only root filesystem, every Linux capability dropped, no-new-privileges set, and a small tmpfs as the only writable space. CPU, memory and process count are all capped from measurement rather than guesswork. The build is multi-stage: git and SSH exist only in the build stage, so the runtime image carries no toolchain and no key.

Nothing stored, end to end

Saves are parsed in memory and discarded when the request ends. The server runs with access logging off, so the request itself leaves no trail either. The front-end holds no prediction logic and ships without source maps, and the site's privacy policy states exactly this behaviour, which makes it a promise the code has to keep rather than a page nobody reads.

Deployed without a public port

The container binds to loopback only and Cloudflare fronts it through a tunnel, so the origin is never directly reachable and its address stays out of DNS. GitLab CI runs the tests, then deploys on the box itself through the host's Docker daemon, with the dependency's deploy key mounted as a build secret so it never lands in an image layer.

• Origin bound to 127.0.0.1, reached only through the tunnel
• Test then deploy, same pipeline, no manual step
• Deploy key as a build secret, never baked into a layer