Release history#
One version number covers the whole product: the agent, the web UI, the installer, the
packaging and the OS image are built and released together from one tag. Thirteen versions
have been tagged, from 0.3.0 on 2026-09-01 to 0.5.1 on 2026-09-02. The authoritative record
of what each one changed is CHANGELOG.md in the repository, which
follows Keep a Changelog and Semantic Versioning; this page is the index to it, plus the
mechanics of where a release lands and how to check what you downloaded.
Where a release lives#
| A tag's files | /v<version>/ on the download host |
| The newest release | /latest/, a symlink that only ever moves forward — re-running the pipeline for an older tag does not hand customers last month's image |
| Checksums | SHA256SUMS, one file covering every artefact published for that tag |
| Signature | SHA256SUMS.asc, when a release key is configured |
| The channel index | stable.json, or beta.json for a pre-release tag |
Both release jobs — the one that builds the packages and the one that builds the image —
publish through the same script, which rescans the whole tag directory each time. Whichever
job finishes last leaves a complete and consistent set rather than two half-indexes —
.forgejo/workflows/publish.sh.
The channel index#
A small JSON document, rewritten on every publish, naming the newest version in that
channel and everything published for it —
.forgejo/workflows/release-index.py:
| Field | What it holds |
|---|---|
channel | stable for a plain vX.Y.Z tag, beta for a tag with a pre-release suffix |
version, tag, released | The version, its tag, and the publish time in UTC |
base | The directory URL every artefact hangs off |
notes | The changelog file published beside the artefacts, when there is one |
checksums, signature, signed | SHA256SUMS, its detached signature, and whether one was actually written |
artifacts | Every published file with its kind (iso, deb, sources, patch, notes), its architecture, its size and its SHA-256 |
Nothing in the product reads that index. There is no in-product update notification — it exists for a person or a script to watch, which today is the only way to learn that a release exists.
Every tagged version#
Dates are the dates in the changelog. Each line is the shape of the release, not its full
contents; the section named in CHANGELOG.md is.
| Version | Date | What it was |
|---|---|---|
| 0.5.1 | 2026-09-02 | The corners found by installing a real machine from a real router's configuration and then asking it to prove it matched: the importer refuses to guess a LAN, --check-against compares words rather than text, the seed finder stops handing back two paths |
| 0.5.0 | 2026-09-02 | Install without a keyboard, and arrive from OPNsense with your configuration. The seed-driven unattended install, opnsense-import.py shipped in the package, and wheelhouse-seed.py to build the medium |
| 0.4.5 | 2026-09-02 | Two things that went wrong on real hardware: password length requirements removed everywhere, and the installer asking for a WAN and a LAN separately. Also the postinst bug that meant an upgrade kept running the old binary until the next reboot |
| 0.4.4 | 2026-09-02 | The console banner's timer must never restart the console it is running on — on a live boot that console is the installer |
| 0.4.3 | 2026-09-02 | The agent stops hammering the router. Every API call forks a shell on the router, so the agent budgets calls: one counters read per sample for all interfaces, and no timed op-mode priming. Idle load went from a two-vCPU box at load 15 to about a dozen calls a minute |
| 0.4.2 | 2026-09-02 | Booting 0.4.1 on hardware stopped at the last boot message. The installer becomes the tty1 getty through a systemd generator instead of fighting it, and dialog's screens stop being drawn into the journal |
| 0.4.1 | 2026-09-02 | Boot like an appliance: wheelhouse-install, the console banner on /etc/issue, the first-boot password file, and an ISO workflow that publishes each tag to the public download host |
| 0.4.0 | 2026-09-02 | The rest of the router. Multi-WAN, IPsec and OpenVPN pages, reboot, power and boot images, DHCP relay, router advertisements and DHCPv6, mDNS, LLDP and ARP, SNMP, remote syslog, flow export, tunnels, VRRP, ACME, dynamic DNS — and one place for high availability. The 1:1 NAT editor was switched off here, with the reason on the page |
| 0.3.4 | 2026-09-01 | First boot enables the router's REST API. Without it the API answered 404 to everything, and the agent now reports a non-2xx as a 502 naming the node to set |
| 0.3.3 | 2026-09-01 | First boot and the agent wait for VyOS to finish loading its configuration, rather than starting in the window where /config is not yet mounted |
| 0.3.2 | 2026-09-01 | The first-boot script is not set -e safe, which had left freshly built images with no API key and an agent restarting forever. Also: upstream renamed the rolling branch |
| 0.3.1 | 2026-09-01 | The OS image is built in CI and attached to the release: the vyos-build flavor, the build script, and a corresponding-source record |
| 0.3.0 | 2026-09-01 | The first tagged release — everything built before the project started tagging: the agent, the web UI, the app store, desired state, fleet, licensing, single sign-on and the packaging, with real accounts, roles, sessions, API tokens and an attributed audit log |
In the tree, not yet tagged#
Work sitting above 0.5.1 in CHANGELOG.md under Unreleased. It is listed here because
some of it is what this documentation describes, and because an unreleased change is not a
release: the customer documentation set itself, the image owning its own /etc/os-release,
its own default configuration and login banner, the vyos-build pin with the GPL
build-tooling patch published beside each image, a dependency scan in CI, the channel index
and one SHA256SUMS per tag, release notes generated from the changelog section, the
System → About page in the web UI, a default-deny firewall for both address families
whenever there is a WAN, and wheelhouse-install --answers FILE --commands printing the
set commands a set of answers produces without changing anything.
One removal in that section is worth knowing about if you script against a router:
GET /health no longer reports the agent's version — Support has the ways to
get it that do work.
Release notes per version#
This wiki does not publish a page per version. The changelog in the repository is the
record, the release on the forge carries that version's section as its notes, and the
channel index links the notes file published beside the artefacts. Whether the wiki should
also carry a page per version is an open question for the owner — <TODO: owner>.
Upgrading#
The upgrade path is VyOS' own image mechanism: add system image, with the previous image
still bootable. The procedure is in docs/upgrade.md.
What survives an upgrade is /config, which is where the agent keeps everything it
remembers: accounts, the audit log, the API key, the certificate and the licence —
Privacy.
See also#
- What is finished, and what is not — the state of the current release.
- Corresponding source — the source record published with every image.
- Roadmap — what is not in any release yet.
- Watch for releases — how to learn that one exists.
- Upgrade the image — applying one without losing the box.
Checked against#
CHANGELOG.md ·
.forgejo/workflows/publish.sh ·
.forgejo/workflows/release-index.py ·
docs/security.md ·
docs/upgrade.md ·
README.md