Policy history and rollback
Every saved change to the access policy is kept as a version. Compare any two versions and restore an earlier one when a change breaks something.
Updated · ·By Ivan Vyshniak
Nothing on this page changes with your selection.
Every time the access policy is saved with a change, Peerlify stores the new document as a numbered version. You can compare versions and restore an earlier one.
View history
Open Access → History. Each entry shows:
- the version number (
v1,v2, …), - who saved it (for REST API saves, the person who created the token; Peerlify if that person's account no longer exists),
- when it was saved,
- a note, if there is one. Restores add the note
Restored v<n>, and changes made through the REST API addvia API. Saves from the editor have no note.
A save that doesn't change the document creates no version.
Anyone who can open the Access page can view the history. The first version of a new network's default policy isn't stored; comparisons against "version 0" use a built-in copy of the default policy.
Compare two versions
The two newest versions are selected when the tab opens, marked NEW and OLD, and the diff beside the list shows what changed between them.
To compare other versions, click entries in the list:
- Clicking a selected entry clears it.
- If NEW is empty, the entry you click becomes NEW. Otherwise, if OLD is empty, it becomes OLD.
- If both are set, the entry you click becomes NEW and the previous NEW becomes OLD.
The diff compares the two documents line by line. Documents are stored in a fixed key order, so unrelated parts stay quiet. Moving a rule shows as a deletion plus an addition. To keep reviews readable, reorder rules in a separate save from other changes.
Restore a version
- Arrange the comparison so the version you want back is OLD.
- Click Restore v<n> above the diff.
- Read the dialog and click Restore v<n> again.
Restoring saves the older document as a new version on top of the history. Nothing is erased or renumbered, and you can restore again if it was the wrong choice. Restoring requires the Owner, Admin or Network admin role.
A restore is checked like any other save. It is refused if:
- one of the restored document's own tests fails. You'll land on the Tests tab with the failure.
- its groups are invalid, or it has more groups than your plan allows.
- it newly refers to a tag you don't manage.
Restoring doesn't close open connections
The restored policy reaches devices within about 10 seconds and applies to new connections. TCP connections opened under the bad policy stay open. To cut a specific device off immediately, remove it from the network.
To restore only part of an old version, open the diff, copy the parts you need into the Advanced tab, and save. That is also recorded as a new version.
Recover from a lockout
If a policy change cut off the device you work from:
- The console is never blocked by the policy. Sign in to
web.peerlify.comfrom any browser, open Access → History, and restore the last working version. - On the affected device,
peerlify statusshows whether the device has received a policy, andpeerlify aclsshows the rules it holds. - As a stopgap, a device you are signed in on can move to another network you belong to with
peerlify network swap <networkId>. Tagged (shared) devices can't switch; enroll them in the other network with an auth key from that network instead.
What is recorded elsewhere
Each save, including a restore, also writes an Updated access controls entry (acl.update) to the audit log and sends a policy.updated webhook. The audit entry expands to the same diff.