Revisions and rollback#
Every change applied to the router is archived. The archive is numbered, newest first: revision 0 is the configuration that is running, revision 1 is the one before it, revision 2 the one before that. The History tab of the System page lists them, says what each one changed, and restores any of them.
The list#
System → History holds the Configuration history table:
| Column | What it shows |
|---|---|
| Revision | The number, 0 for the running configuration. |
| Applied | When the router applied it. |
| By | The account the router saw. |
| Through | How the change reached the router: Web interface or API, Console, or Start-up. |
The list is the router's own record of its commits, read as it prints it.
What a revision changed#
Selecting a revision opens it. What this change did lists the change that produced that revision, in the same sentences the Commit Bar uses for pending changes:
- Add VLAN 20 on eth0 — Address 10.20.0.1/24, description “IoT”
- Change the host name to edge-1
- Remove time server time2.example.net
The sentences are read from the router's own comparison of that revision with the one before it, so they cover changes made at the console as well as through Wheelhouse. A revision whose comparison is empty says This revision changed nothing.
With Advanced mode on, the panel also shows the comparison itself, under Difference: lines marked + were added by the change and lines marked − were removed.
A revision's comparison can contain a pre-shared key or a private key, so it is redacted below the admin role. The sentences never contain a secret for anyone.
Restoring a revision#
A revision's panel ends with Restore revision 3. It asks once more, as Restore revision 3?, and then applies that revision's configuration at once, without auto-revert. The page then says Restored revision 3. The configuration it replaced is now revision 1. and offers Review revision 1, which opens the configuration the restore replaced, so that it can be restored in turn if the restore was a mistake.
Four things follow from "load and apply":
- A restore is an applied change. It appears in the history as the new revision 0, and in the audit log, where it is recorded with the archived file it loaded.
- It does not rewind history. Nothing is deleted; the configuration you restored away from is still in the archive, now as revision 1.
- It needs the router to be reachable. If the change you regret is the one that cut you off, a restore cannot help. That is what Apply with auto-revert is for, and it has to be chosen before the change is applied, not after.
- It is not saved. Like any applied change, a restored configuration is what the router starts with after a restart only once Save configuration has been pressed.
Restoring needs the approver, operator or admin role and a usable licence. If the revision's archived file is missing, the restore fails with the router's reason and nothing changes.
Neighbouring actions#
| Action | Where | What it does |
|---|---|---|
| Save configuration | System page header | Writes the running configuration to the boot configuration, so the router starts with it. Applying a change does not do this. |
| Download configuration | System page header, admin only | Saves the whole configuration in the router's native format, unredacted, because it contains every secret. |
| Load a configuration file | API only (POST /api/config/load) | Loads a configuration file that already exists on the router and applies it: the same mechanism a restore uses, with a file you name. |
The git export#
System → History → Git export pushes every applied revision to a git remote over SSH: one git commit per export, authored as whoever made the change and committed by the agent, carrying one file, the running configuration. The router generates its own ed25519 key and shows the public half, to install as a deploy key with write access; the remote's host key must be entered, and there is no trust-on-first-use.
Two things it is not:
- It is not a backup you can restore from. Secrets are redacted before the file is committed, by the same rule the API applies below admin, so the repository is a history of what changed and when, not a file you can push back onto a router.
- An unchanged export makes no commit. Because redaction is unconditional, a change confined to a secret value produces an identical file and is reported as skipped. The revision it covered is named by the next real push rather than lost.
It has pushed to a real SSH server: the demonstration router, to a bare repository on
another host, on 2026-09-04. The git half runs against a real git receive-pack in the
test suite, and the SSH leg has been proven through the handshake against an in-process
server. Treat the first export to your own remote as the proof.
There is no way to name a revision or attach a note to one. The revision list carries the router's four fields and nothing more.
For automation#
R=https://<router>:8443
T=wh_... # an API token with the viewer role
curl -sk -H "Authorization: Bearer $T" "$R/api/history"
curl -sk -H "Authorization: Bearer $T" "$R/api/history/diff?rev=1"
curl -sk -X POST "$R/api/rollback" -H "Authorization: Bearer $T" -d '{"revision":1}'/api/history answers with the parsed revisions and the router's unparsed text in raw,
so nothing the router printed is lost if a line does not match. /api/history/diff
answers with the router's comparison for that revision, verbatim, in a diff field; rev
must be a non-negative integer. /api/rollback takes the revision to restore, 1 by
default, and needs a token with the approver role or above.
See also#
- The Commit Bar: how a revision gets made.
- Apply with auto-revert: the undo you choose beforehand.
- The audit log: who, from where, with which changes.
- System — history: the screen.
- Rolling back a change: the task guide.
- Taking a backup and restoring one.