Protect change windows
Prove a small first group and stop before a local exception becomes a fleet event.
Closed-Loop Network Operations
Ship network change without turning exceptions into outages.
Rezonance gives multi-vendor network teams one operating loop for complex change: understand live state, plan the rollout, prove the first devices, verify every stage, and isolate failures before they spread.
Netcode executes the change. Rez Diagnostics explains the exceptions. Engineers approve every production write.
Vendor-neutral operations
Human-approved writes
Read-only RCA
Credentials stay local
CHG-4271 · Region 3
Routing, security and WAN policy convergence
2,480targets
2,117verified
11held for review
0promoted without proof
Campaign progression85% verified
ScopePlanFirst devicesVerified groupsClose
Route-policy standardizationVerified
Firewall egress and NAT alignmentVerified
SD-WAN and QoS policy migrationIn progress
Telemetry and compliance closeoutQueued
Exception isolated before wider rollout
Branch-EDGE-03 passed routing checks but outbound NAT evidence is missing for the scoped flow.
Rez opened a read-only investigation. The next device group remains paused.
Next actionReview scoped fix
Cut exception time
Move from console hopping to scoped, read-only diagnosis tied to the exact failed check.
Increase team capacity
Standardize repeatable work while engineers retain the decision to change production.
Keep what already works
Reuse SSH, APIs, Ansible, Git and service-management processes instead of replacing them.
The Operational Problem
The expensive part is not generating commands. It is controlling what happens next.
Large network changes stall because inventory is fragmented, pre-checks are inconsistent, failures arrive without context, and rollback depends on the engineer who built the script. Rezonance turns that fragmented work into one governed operating cycle.
Without a shared loop
- Scripts, spreadsheets and terminals disagree
- Failures surface after the blast radius expands
- Engineers rebuild context under pressure
- Rollback knowledge lives with one person
With Rezonance
- Live state and intended outcome share one workspace
- Each device group must prove health before promotion
- Rez investigates only the failed dependency and flow
- The approved change and rollback remain attached
The Rezonance Difference
The change does not end when the commands run.
Other automation tools can push configuration. Rezonance keeps operating through verification, failure isolation, remediation planning and approved recovery.
Understand
Discover live devices, topology, policy and dependencies.
Plan
Calculate exact scope, risk, commands and rollback.
Prove small
Run the first devices and verify the expected outcome.
Diagnose
If a check fails, Rez isolates the cause read-only.
Continue or recover
Approve the next group, a scoped fix, or rollback.
The machine closes the loop of work.The engineer closes the loop of decision. No production write bypasses human approval.
Enterprise Change Programs
Built for the network work that carries real business risk.
Start with a program that is already consuming change windows, senior engineers and operational trust. Rezonance turns it into a repeatable operating model.
Regional edge transformation
Coordinate routing policy, SD-WAN, QoS, security and telemetry changes across sites without treating the network as one undifferentiated batch.
Outcome: faster modernization with contained blast radius.Firewall and SD-WAN policy harmonization
Align path intent, egress policy, NAT behavior and application reachability across Fortinet, Palo Alto and routed WAN domains.
Outcome: fewer policy exceptions and cleaner cutovers.Multi-vendor software lifecycle
Group mixed hardware by readiness, stage safely, verify routing and services after reboot, then stop or recover only affected cohorts.
Outcome: more fleet progress per maintenance window.M&A and data-center migration
Model overlapping networks, policy differences, route redistribution and phased cutovers before moving traffic between operating domains.
Outcome: migration decisions backed by live dependencies.Continuous compliance and drift recovery
Compare approved intent to live state, isolate meaningful deviations and create scoped remediation without normalizing a failed scan as truth.
Outcome: less audit toil and fewer silent configuration gaps.Incident-to-remediation operations
Start from an outage, let Rez identify the in-scope failed condition, then turn the confirmed finding into a reviewed Netcode change.
Outcome: shorter handoffs from diagnosis to safe action.See The Loop Close
A rollout exception becomes a diagnosis, not a war room.
Watch Digital Twin context, Rez read-only diagnosis, a scoped remediation proposal, verified progression and ready rollback in one 82-second story.
Bring us your change scenarioOne Operations Platform
Automation, diagnostics and the engineer's terminal share the same network context.
Discover once. Use the same inventory, topology and device identity across planned changes, live investigations, drift checks and human operations.
NControlled change
Netcode Automation
Plans exact change scope, tests the first devices, verifies live outcomes and pauses before risk spreads.
- Fleet campaigns and device groups
- Human approval and two-person control
- Recorded rollback and change history
RRead-only diagnosis
Rez Diagnostics
Investigates the exact site, dependency and flow that failed, then returns a typed remediation draft without writing configuration.
- Live SSH and API evidence
- Topology and operational baseline
- Scoped handoff into Netcode
>_Human operations
Netcode Shell
A full network terminal through the local runner, with saved sessions and a path from one-off work into repeatable automation.
- Interactive multi-vendor SSH
- Searchable session history
- Transcript-to-workflow handoff
Under the Hood / How Network Automation Works
The automation logic is simple: compare intended state to live state, then apply only what is proven safe.
Netcode does not blindly push templates. It follows a deterministic automation loop: read live state, model intended state, calculate the delta, validate policy, dry-run or canary, apply through gates, verify actual state, and keep rollback tied to Git.
Netcode automation is not template push. It is intent - plan - validation - controlled execution - verification - drift control.
Live State
Interfaces, VLANs, BGP neighbors, routes, ACLs, NTP, SNMP, firmware, interface state.
Intended State
Approved NTP servers, VLAN standards, interface roles, routing peers, ACL rules.
Delta Plan
Devices affected, commands to add, commands to remove, rollback commands, risk summary.
Git Branch + Policy Gate
Each change is isolated, reviewed, checked, and blocked before execution if unsafe.
Dry-run / Canary
Candidate config, device syntax check, first-batch canary, and no-commit validation where supported.
Verify Actual State
NTP peers active, VLAN present, BGP session established, route installed, ACL ordered correctly.
Git Rollback + Drift Watch
Rollback to previous approved intent, validate reverse plan, apply through the same gates, and monitor drift.
Product Modules
Everything needed to move from scripts to governed NetDevOps.
Change Workspace
One guided workspace for intent, plan, validation, dry-run, apply, verify, rollback, and drift.
Bulk Change Planner
Select device groups by site, role, vendor, tag, or source-of-truth query. Plan one change across many devices.
Command Preview
Show exact generated commands and rollback commands before anything touches a device.
Git Workflow
Create review branches, commit generated artifacts, review diffs, merge approved intent, and roll back by reverting Git state.
Policy Gates
Block unsafe changes before apply using device groups, command patterns, maintenance windows, approvals, and rollback requirements.
Canary and Batch Apply
Apply to a small canary first, verify, then promote in controlled batches with automatic stop conditions.
Drift Watch
Continuously compare intended state to live state and create remediation plans when drift appears.
Netcode Shell
Open full live SSH sessions through the local runner with transcripts, before/after evidence, optional ticket attachment, and runner-side credentials.
Workflow Packs
Start with guided OS upgrade campaigns, then add golden baseline, VLAN rollout, interface standards, BGP neighbor updates, ACL cleanup, and drift checks.
Netcode Shell
A real network CLI, connected to the automation loop.
Network engineers still need a full shell. Netcode Shell gives them one: live SSH through the customer-side runner, credentials kept local, every command recorded, and a clean path from an ad-hoc fix into governed automation when the work should be repeated.
Credentials stay local
Device credentials resolve on the customer-side runner, not in the browser and not in the control plane.
Full live CLI
Engineers can troubleshoot and configure from the shell. The human at the keyboard is the approval for this interactive path.
Every session is useful later
Transcripts and before/after diffs can attach to a ticket, change, RCA, drift investigation, rollback, or approval record.
Session recording · optional ticket CHG-2048
Core-RTR-02 · Region 3
Runner customer-side
Mode full live SSH
Transcript recording
Evidence before/after diff
Core-RTR-02# show bgp ipv4 unicast 10.204.210.0/24
BGP routing table entry for 10.204.210.0/24
Paths: 2 available, best #1
Community: region3-app-segment
Core-RTR-02# configure terminal
[live] config mode entered · transcript recording
Core-RTR-02(config)# route-map REGION3-EDGE permit 20
Core-RTR-02(config-route-map)# set local-preference 180
Core-RTR-02(config-route-map)# end
Core-RTR-02# show archive config differences
[diff] route-map REGION3-EDGE permit 20 addedNetDevOps Governance
Every change has a branch. Every rollback has a known previous state.
Netcode uses Git as the system of record for network intent and generated artifacts. Engineers can review plans before apply, promote approved changes, and roll back by reverting to the last known good intent.
- A change branch isolates every network change.
- The plan shows exact intended delta.
- Policy checks run before apply.
- Canary result is committed back to the branch.
- Merge means approved intent.
- Drift watch compares live state to approved intent.
main
change/region3-app-segmentation-2048
intent.yaml
plan.md
commands.txt
rollback.txt
validation.md
canary-result.md
verify.md
Git Rollback Panel
Rollback CHG-2048
- Previous approved state
- main@8f31a2
- Current branch
- change/region3-app-segmentation-2048
- Rollback action
- revert app segment, route policy, and firewall object references
- Rollback commands
- 384 generated
- Validation
- Passed
- Status
- ready for rollback canary
Rez Diagnostics
Healthy adjacencies. Wrong traffic path. Rez finds the signal in the noise.
A remote site advertises a more-specific route that silently pulls half of a data-center subnet toward the wrong edge. BGP remains established, interfaces stay up and generic health dashboards look green.
QuestionWhy can Store 204 reach 10.20.0.200 but not 10.20.0.10?
Scoped finding10.20.0.0/25 from Store-01 overrides the intended DC /24 for the failed destination.
Next safe actionDraft a route-policy change for review. Do not touch healthy adjacencies.
SStore-204source
WWAN coreBGP healthy
DDC fabric10.20.0.0/24
!Store-01leaked /25
10.20.0.200 intended /24
10.20.0.10 shadowed by /25
Root cause isolatedMore-specific route shadow, not a BGP outageLive route evidence + expected origin + destination-specific path
Vendor-Neutral By Design
Build one operating model across the network you actually own.
Rezonance normalizes multi-vendor inventory and live state while preserving vendor-specific commands, APIs and operational evidence. Existing Ansible playbooks and scripts can remain part of the workflow.
Adapter depth and write support vary by platform and workflow. Pilot scope is agreed and validated before production use.
CiscoAristaFortinetPalo AltoJuniperArubaNokiaHuawei
SSHREST APIsAnsibleGitServiceNow
Enterprise Trust Boundary
Autonomy where it is safe. Human control where it matters.
Credentials remain inside your network
The Windows or Linux runner initiates outbound connectivity to the service. Device credentials are resolved locally.
Diagnostics cannot apply configuration
Rez uses a separate read action family and returns findings or draft remediation, never a direct write.
Every production change stops at a person
Policy, first-device proof and requester-not-approver controls sit in front of fleet execution.
Change and rollback travel together
Commands, verification, approvals and reverse actions remain attached to the same governed record.
Start Where You Are
Explore locally, automate one workflow, or prove a high-value program.
Learn the operating model
Free
Local examples, Netcode Shell and sample workflows for engineers evaluating the platform.
Request Community accessAutomate one real workflow
$99/month
One workspace, up to 25 devices, guided planning, verification and limited Rez Diagnostics.
Request Starter accessProve the hardest change window
Scoped
We model your program, connect the local runner, execute a controlled proof and measure the operational result.
Design the pilotDesign Partner Program
Bring us the change window your team dreads.
Give us one complex, multi-device program and a safe environment. We will model the blast radius, prove the first devices, show how failures are isolated, and leave every production decision with your engineers.
1 difficult change program1 customer-side runner1 measurable operating result