Releases
Last updated: 2026-08-03
Relayium ships in three rhythms, and this page is honest about all three: the web app is deployed continuously, the command-line tools are numbered and tagged, and the native apps are engineering builds that have not been released publicly.
Every version below was tagged automatically from the main branch, and only after the checks on that exact commit passed. A version's complete notes — every commit it contains — are one click away on GitHub.
Every published version
Newest first. Each version links to its full notes and downloads on GitHub.
- v0.15.02026-08-03
- v0.14.02026-08-02
- v0.13.02026-08-01
- v0.12.02026-07-30
- v0.11.12026-07-28
- v0.11.02026-07-28
- v0.10.22026-07-23
- v0.10.12026-07-23
- v0.10.02026-07-23
- v0.9.02026-07-22
- v0.8.12026-07-22
- v0.8.02026-07-22
- v0.7.02026-07-13
- v0.6.02026-07-13
- v0.5.02026-07-13
- v0.4.02026-07-13
- v0.3.12026-07-13
- v0.3.02026-07-13
- v0.2.02026-07-08
- v0.1.22026-07-08
- v0.1.12026-07-08
- v0.1.02026-07-08
What a version number covers
A version tag publishes two programs: the relayium command-line tool, and relayium-node, the relay and storage node that self-hosters run. Both are built from the same source tree, so a version exists only when that tree changed.
- The web app has no version number. It is deployed from the main branch as soon as its checks pass, so what you use in a browser is usually newer than the newest version listed here.
- The macOS and iOS apps are engineering builds, not public releases. No version below ships them.
- A node does not follow this list by itself: it asks the server it belongs to which version to run, so a new version changes nothing until someone starts a rollout. The command-line tool updates with relayium update.
How a release is cut
Releases run on a schedule rather than on someone remembering. Once a week a workflow looks at what has landed since the last version, and stops without tagging in two cases: when the code that actually gets published has not changed, and when the checks on that commit are not green.
- Both stops are deliberate. Relying on memory once left a finished feature unreleased for months, and tagging an unverified commit would ship exactly the breakage a schedule is meant to prevent.
- Weeks that change only documentation or the apps produce no version, because the published programs would be byte-for-byte the previous ones.
Checking what you downloaded
Every release publishes a checksum file next to the archives, and a signature over that file. The updater verifies both before it installs anything, against a public key compiled into the program — so a tampered archive fails on your machine, rather than depending on whether we noticed on ours.
- For networks that cannot reach GitHub, Relayium also mirrors its own release files. Where the bytes come from is a question of reachability, not of trust: the verification is identical either way.
- The source is public. The server, the node and the web app are AGPL-3.0, the native apps Apache-2.0, and the documentation CC BY 4.0.