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 add via 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

  1. Arrange the comparison so the version you want back is OLD.
  2. Click Restore v<n> above the diff.
  3. 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.com from any browser, open Access → History, and restore the last working version.
  • On the affected device, peerlify status shows whether the device has received a policy, and peerlify acls shows 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.

Next steps

Was this page helpful?