outboundctl backup

outboundctl backup writes rules and settings to one file you can archive or move to another Mac. outboundctl backup restore puts them back. Both commands work on the store files directly. Only restore is subject to the edit policy.

Making a backup

outboundctl backup <path>

Writes a JSON document containing the rule store and the settings file, then prints how many rules it backed up. The backup does not include app preferences or the analytics database; connection rollups can be rebuilt from history still on the Mac, but byte totals cannot.

Backup files carry a format version, the creation date and an appVersion field. A CLI backup writes the tool’s version, 1.0, in that field. Blocklist entries are left out of the file: a restore rebuilds them from the subscriptions the settings keep. Managed rules and trusted-group rules are included.

Choose a destination outside the store itself: a path that is one of the live store files (or their .bak or .lock companions) is refused with a usage error, exit 64.

Restoring

outboundctl backup restore <file>

Validates the file first, then replaces rules and settings together. The validation is strict: the file must be JSON, of a format version this build understands (a newer backup tells you to update Outbound first), and its settings must include policy, blocklists, profiles, trustedGroups, knownNetworks and onboarding. Other settings fields can use compatibility defaults. A file that fails validation exits 65 and changes nothing.

The restore holds both stores’ write locks, writes both files, and keeps an exact snapshot of each before writing. If a write fails, the restore attempts to put back both files and the rules backup from those snapshots. Rollback can itself fail. The error says which happened: restore failed and was rolled back: … when the rollback succeeded, restore failed; rollback is incomplete: … when it did not.

On success it prints Restored rules and settings from <path>.

What a restore keeps and drops

The restored rule set is built like this:

• Managed rules currently in the store stay; they belong to the organisation’s rule feed, not to your backup.
• Your own rules and the rules of trusted groups enabled in the backup’s settings come back.
• Blocklist rules already downloaded for a subscription the backup keeps stay until that list’s next refresh, so a failed download after a restore cannot leave the Mac without the list’s protection. Entries for subscriptions the backup does not know are dropped.
• The backup’s blocklist subscriptions come back with their fetch bookkeeping cleared, so each list is downloaded fresh instead of being skipped as unchanged.

Refusals

A restore that would loosen protection is refused, even for root:

This restore would loosen protection. Approve it in the Outbound app.

That is the same gate preferences go through: the command line cannot ask for the approval a loosening change needs. On top of that, the normal edit policy applies to a restore as a whole (rules and settings and profiles together), so an organisation that has disabled outboundctl changes, or locked the relevant areas, blocks it with exit 77.

The destination Mac keeps its current onboarding state. CLI restore does not apply app preferences from a backup made in the app.

For example, outboundctl backup ~/Desktop/outbound-backup.json writes a backup. Success exits 0. Read, write, rollback and protection-loosening failures exit 1; invalid backup contents exit 65; syntax and protected destination errors exit 64; edit-policy refusals exit 77.