BryanNet

Product updates, compatibility and rollback

Prerequisites and authority

Assign an operator and an authorized technical owner. Data-replacing recovery and updates require a maintenance window, preserved recovery point and known target.

Approve, apply and verify updates

Use manual approval by default. Silent updates require explicit eligibility in release policy and installation configuration. Check migration type/risk, compatibility and customer action requirements before approving.

  1. Record installed and target versions.
  2. Read the release notes and confirm the correct OS/package route.
  3. Verify package integrity and immutable image references where supplied.
  4. Create/verify the pre-update backup and preserve the old configuration.
  5. Announce the maintenance window and restrict normal writes.
  6. Apply through the supported installer/control route.
  7. Review migration and health verification outcomes.
  8. Run operational acceptance before reopening normal use.

Both Windows and Linux agents start rollback-safe verification services before reopening ordinary application traffic. Health checks remain available during this phase. Successful container startup alone does not prove a compatible migration. After traffic reopens, a failure requires recovery; the agents do not automatically restore the pre-update database over possible new writes.

For an offline Windows update, choose Install from File in Control and select the Windows Update package. Control checks the bundled deployment ZIP before staging and launching that release's updater. On Linux, invoke the installed agent with the local Linux Update package and explicit approval:

sudo env BRYANNET_LOCAL_UPDATE_PACKAGE=/absolute/path/BryanNet-VERSION-Linux-Update.zip \
  BRYANNET_CUSTOMER_APPROVED_UPDATE=true BRYANNET_TARGET_VERSION=VERSION \
  bash /opt/bryannet/control/linux/bryannet-update-agent

Replace both VERSION values with the selected release version and use the actual package path. Linux checks the package, release channel and test authority before staging its target agent; the target acquires the deployment lock and validates the update again. Online updates on either platform use the installed agent. A checksum verifies consistency with the manifest, not the provenance of an untrusted download: obtain packages from the approved distribution source.

The agents do not apply the same version or an older version. In particular, a 2.0.5-test.* installation cannot use this route to downgrade to 1.0.0. A test reset or a compatible recovery plan is a separate, explicitly authorized operation; deleting data is not part of a normal update.

Verify admin/customer login, worker runs, subscriptions, router access and provider callbacks. Keep the transition record and backup reference.

If rollback is needed

Preserve failed-update evidence. Use the supported rollback path with the documented recovery point. A rollback that restores a pre-update database after new writes were accepted can lose those writes. Bound the maintenance window and reconcile external transactions before reopening.

If automatic rollback reports failure, stop repeated update attempts. Inspect which release/configuration/database is now running and follow Update, license validation or service reachability issue/Restore BryanNet safely. Never declare success from an older dashboard page that remained cached.

Related guides

Related guides: Health checks, background services and workers, Back up BryanNet and validate backups, Restore BryanNet safely, Daily weekly and monthly operator checklists.