Supported platforms and minimum versions
All six release targets, the OS floor and key storage for each, and what the declared-not-certified distinction actually commits to.
Written By Dustin
Last updated 29 minutes ago
TOVIO declares support for six OS and architecture targets. Each one has a stated minimum, a keychain backend, and a set of package formats.
The six targets
Windows on ARM has a higher floor than Windows on x86_64 — it starts at Windows 11, not Windows 10. Building from source on Windows additionally requires the MSVC toolchain, which the published packages do not.
What "declared, not certified" means
Every one of those six rows is currently marked certified: false. These are the declared floors: the minimum each target is expected to work on, and the level of support being committed to.
Certified is a stricter, mechanical claim. A target flips to certified only when the project's certification script has been run on a clean host at that exact floor and its record is filed in the release evidence manifest. None have been, yet.
In practice: recent versions of all six are well exercised by CI and daily use, and the floor is a promise about what will be supported rather than a claim that the floor itself has been proven. If you hit a problem specifically on an old-but-declared version, that is worth reporting — it is exactly the gap this distinction is honest about.
Changing a floor is a breaking change
Dropping a target or raising a minimum is governed by the compatibility and deprecation policy as a breaking change, announced in the release notes. It will not happen quietly between patch releases.
The keychain column assumes a desktop session
Those backends store one thing: the 32-byte wrapping key that unseals the repository's identity secret. The secret itself stays sealed on disk in the repository, so both halves matter.
On a host with no keychain daemon — a headless server, a container, a CI runner — TOVIO does not silently substitute an on-disk store. There is no such fallback backend. Key operations simply fail, on purpose, because quietly downgrading key storage on a build runner would be a security surprise. You either supply an injected wrapping key through an environment variable, or you use a Simple-tier repository, which needs no keychain at all. The headless-host article covers both.