commit-confirm — the rollback safety net for remote changes

A commit-confirm is a commit with a self-destruct timer. If the operator does not confirm before the timer expires, the box reverts to the configuration it had before. The pattern is the single most important safety net for remote changes — every change to a router that the operator is connected to over the very link being changed should use commit-confirm.

How commit-confirm works

sequenceDiagram
  participant Op as Operator
  participant VyOS as VyOS box
  participant Net as Network

  Op->>VyOS: commit-confirm 5
  VyOS->>VyOS: Apply candidate, arm revert timer
  VyOS-->>Op: will be automatically reboot in 5 minutes unless confirmed
  VyOS->>Net: New configuration live
  Op->>Net: Test the change
  Net-->>Op: Tests pass
  Op->>VyOS: confirm
  VyOS->>VyOS: Disarm timer, keep running config
  Op->>VyOS: save
  Note over VyOS,Net: -- OR --
  Op->>VyOS: no confirm within 5 min
  VyOS->>VyOS: Revert action fires (default: reboot)
  VyOS->>Net: Box boots on /config/config.boot

The basic usage

[edit]
vyos@router# set interfaces ethernet eth0 address '192.0.2.10/24'
[edit]
vyos@router# commit-confirm 5
commit confirm will be automatically reboot in 5 minutes unless confirmed
Proceed? [confirm]y
[edit]
vyos@router# confirm
[edit]

commit-confirm 5 schedules the revert five minutes out. Run commit-confirm with no argument and you get the default of 10 minutes. The prompt is a real prompt: the box waits for you to acknowledge before it commits anything.

Confirming

[edit]
vyos@router# confirm
[edit]

confirm disarms the revert and keeps the change. It is silent on success — the only feedback is the [edit] prompt coming back. After confirm, the change is in the running configuration and will stay there until something supersedes it.

The remote change pattern

[edit]
vyos@router# set protocols bgp neighbor 192.0.2.2 remote-as '64512'
[edit]
vyos@router# commit-confirm 10
commit confirm will be automatically reboot in 10 minutes unless confirmed
Proceed? [confirm]y
[edit]
vyos@router# exit
exit
vyos@router:~$ show bgp summary
vyos@router:~$ ping 192.0.2.2

If the tests pass, go back in and make it permanent:

vyos@router:~$ configure
[edit]
vyos@router# confirm
[edit]
vyos@router# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@router# exit

If something is wrong, do nothing. The box reverts on its own.

The standard pattern is: edit, commit-confirm with a sensible timeout, leave configure mode, test the change from operational mode, confirm and save if it works, do nothing if it does not.

The on-prem change pattern (no commit-confirm)

Changes that the operator has console access for do not need commit-confirm. The operator can always reach the box via console if the change goes wrong — and a plain commit does not put a reboot on the table.

[edit]
vyos@router# set system host-name 'router-core-02'
[edit]
vyos@router# commit
[edit]
vyos@router# save

The change is permanent. If the change is wrong, the operator fixes it from the console.

How the result is validated

show system commit
compare saved

show system commit lists the local revisions, newest first, with who made each and how:

$ show system commit

0   2026-08-19 14:31:02 by vyos via cli
1   2026-08-19 14:22:47 by vyos via cli
2   2026-08-18 09:04:11 by ansible via http-api

Revision 0 is the current running configuration. If your change is at revision 0 and compare saved prints nothing, the change is committed and saved and the reboot risk is gone. If compare saved prints a diff, you have confirmed but not saved — finish the job.

How it fails

The production failure modes the engineer must recognise:

• Timer fires while the operator is still testing. A 5-minute timeout is too short for some changes (large BGP convergence, IPsec re-keying). The operator returns to find the box has rebooted. Use a longer timeout for slow changes.
• Operator forgets to confirm. A common error: the operator tests the change, tells the team it worked, but never types confirm. The timer fires and, on the default action, the router reboots — a service outage caused by a change that was working.
• Operator confirms but never saves. The running configuration has the change and /config/config.boot does not. The next reboot — for any reason at all — reverts it.
• A second unsaved change caught in the blast radius. The operator commits change A, does not save, then commit-confirms change B. B’s timer fires, the box reboots on config.boot, and A is gone too. Save between changes, or batch them into one commit-confirm.
• commit-confirm used to test a change that survives a reboot anyway. Reverting a hardware or image-level problem by rebooting into the saved config does not help if the saved config is what is broken. commit-confirm protects you from your change, not from the box.
• Assuming the revert is in-place. An operator who has read about action reload but never set it plans a maintenance around a session that survives — and loses the session to a reboot. Check show configuration commands | match commit-confirm before you rely on it.

Rollback

The rollback path is built into commit-confirm itself:

• Timer fires: the box reverts using the configured action — reboot onto /config/config.boot by default, or an in-place reload if you have set action reload.
• Operator confirms in time: nothing reverts. save to make it survive the next reboot.
• Operator changes their mind mid-window: commit-confirm again with the corrected candidate, which replaces the pending revert.

For a change that was confirmed and later turns out to be wrong, commit-confirm is no longer involved and the ordinary revision path applies: find the good revision with show system commit, check it with compare, then rollback to it — which itself reboots the box.

Production discipline

Cross-course references

The Linux course’s V-Linux-NetConfig covers the underlying configuration model. The Ansible course’s XLII-Ansible-BeyondLinux covers how to drive commit-confirm from an Ansible playbook. The Observability course’s XII-Observability-HostAgents covers how to alert on commit events and on unexpected router reboots.

Quiz