OTA Deploy

OTA Logic Deploy

NexusEdge Hailo Edition supports over-the-air deployment of control logic to field controllers. The pipeline ensures safety through sandboxing, cryptographic signing, automatic backup, and rollback.

Pipeline Overview

Sandbox Editor ──► Verify ──► Sign (ed25519) ──► Push ──► Hot-Reload ──► Verify ──► Done
                                                   │                        │
                                                   ▼                        ▼
                                              Backup created           Rollback if failed

Stages

1. Sandbox Editor

The Console OTA Deploy page provides a sandbox editor where you can:

• Write or modify control logic (algorithm parameters, equipment mappings, schedules)
• Preview the diff against the currently running configuration
• Validate syntax and parameter ranges before deployment

The sandbox runs in isolation -- changes are not applied to the live controller until explicitly pushed.

2. Verify (Pre-Push)

Before signing, the system validates:

• All referenced equipment IDs exist in the site configuration
• Algorithm parameters are within documented ranges
• I/O mappings reference valid board stacks and channels
• No circular dependencies in cascade/lead-lag chains

3. Sign (ed25519)

Every deployment package is signed with an ed25519 key:

• The AN server holds the signing key
• The controller holds the corresponding verification key
• Unsigned or tampered packages are rejected at the controller

4. Push

The signed package is transmitted to the target controller(s) over the existing Cloudflare tunnel or Tailscale connection. The push is:

• Atomic: the controller receives the full package before applying
• Resumable: interrupted transfers restart from the last checkpoint
• Targeted: push to a single controller or a group (by site, by tag)

5. Backup Before Overwrite

Before applying the new configuration, the controller automatically:

• Snapshots the current running configuration to /var/lib/nexusedge/backups/
• Records the backup timestamp and hash in the local AegisDB audit trail
• Retains the last 5 backups (configurable)

6. Hot-Reload

The Talos engine applies the new configuration without restarting the service:

• Active control loops transition smoothly (bumpless transfer)
• No I/O interruption -- sensors continue reading, actuators hold position during reload
• The reload completes in under 2 seconds

7. Verify (Post-Push)

After hot-reload, the system runs a post-deployment health check:

• Confirms all equipment blocks are running
• Verifies sensor readings are within expected ranges
• Checks that algorithm outputs are producing valid control signals
• Reports status back to the Console

8. Rollback

If the post-push verification fails, the controller automatically:

• Restores the most recent backup
• Hot-reloads the previous configuration
• Reports the rollback event to the Console audit trail
• Marks the deployment as "rolled back" with the failure reason

Manual rollback is also available from the Console OTA Deploy page at any time.

Dual Audit Trail

Every OTA deployment is recorded in both:

1. Local AegisDB on the controller -- survives network outages
2. Cloud AegisDB on the AN server -- centralized fleet-wide view

Each audit record includes: timestamp, user, source config hash, target config hash, signature, push result, verify result, and rollback status (if any).

Access Control

OTA Deploy requires at minimum the SiteAdmin role. OrgAdmin and SuperAdmin roles inherit this permission. SiteOperator and SiteViewer cannot initiate deployments.

Tier requirement: Pro or higher. Community tier controllers do not support OTA Deploy.