What Zacsync does.

When a job includes any command that changes configuration, each targeted device takes a backup and sets a revert timer before the commands run. When they finish, Zacsync opens a new connection to check the device is still reachable, then cancels the timer.

If it can't confirm within the revert window (20 minutes by default, adjustable per site), the router restores the backup and reboots on its own. The rollback doesn't depend on the manager or the link.

Zacsync treats a command as read-only only if it uses one of these verbs: print, get, export, monitor, monitor-traffic and find. Any other command is treated as a change and guarded. An extra backup takes seconds; a lockout can mean a site visit.

Configurations are exported over SSH, including sensitive values, and stored in a git repository with one file per device. A new backup is saved only when the configuration has changed: the export's date header is removed first, so an unchanged router creates no new commit. Incomplete exports are rejected.

Scheduled backups are off unless you turn them on. Backups triggered by a configuration change or a reboot are on unless you turn them off. Fleet health shows each device as ok, never, overdue or unscheduled, so devices without a schedule are easy to spot.

Retention cleanup removes old entries from the index but never from the git history. Each device always keeps its latest entry, and older configurations can still be recovered with git log.

To add a router, paste a generated script into its terminal. The script creates the WireGuard interface, a management user and a firewall rule limited to the manager's address, then contacts the manager. The tunnel stays down until you approve the device.

The device appears as pending, showing the serial number, board and identity it reported. None of it is trusted until you approve the device and it is polled. Approving is the only step that grants access. Rejecting deletes the request.

This also works for a router that is already at sea: email the script to someone on board. They don't need any VPN knowledge.

Two routers share a virtual IP using VRRP. One action sets up the pair step by step, with Change Guard protecting each change. Configuration is copied from the master to the standby, following whichever router is currently master, and checked every hour. Failover is based on the master's WAN health, and you can run a failover test or fail back at any time.

If both routers become master, a split-brain resolver fixes it or reports why it couldn't. A boot port fix repairs bridge ports that stop working after a reboot, without needing the hub. Uplink watch alerts when an uplink is up but passing no traffic. Crew hotspot logins move to the new master, and sessions on the old master are ended.

Alerts are sent by Telegram and email, with the most important types on by default and retries for up to 24 hours. Interface traffic is graphed from samples kept for 90 days, and a usage report covers WAN uplinks and crew usage, with CSV export. Operators can open WebFig through the tunnel, with session time limits and every session logged. Winbox access is not built yet.

Zacsync can act as the RADIUS server for your captive portals. Accounts are stored centrally, so a voucher bought on one vessel works on all of them. The feature is off by default, and the RADIUS listener doesn't run when it is disabled.

RADIUS requests only come through the tunnel, never the open internet, so each router is identified by the tunnel address Zacsync assigned it, not by the name it reports. Each device has its own secret, so a stolen router can't be used to access the rest of the fleet.

The router enforces the quota. The remaining quota is sent to the router when a user logs in, so the router ends the session correctly even if the link to shore is down.