EvoEther™
A senior network engineer, leased, running on a box in your environment.
EvoEther is not a dashboard with an assistant bolted on. It is a colleague that lives on an appliance in your rack: it sees the network, it says something when something matters, and it can make the change — then tell you, in seconds or minutes, whether that change actually took. You get one login. You administer your network. You do not administer the box.
One console for the whole week
The week is not DHCP fires and scope edits. It is standing up sites, fixing routing, finding single points of failure, locking ports down, watching optics fade, and making the next site look like the last one.
DHCP
Scopes, pools, bindings.
DNS
Forward and reverse.
IPAM
Who owns which prefix.
Network inventory
Devices, ports, what is actually on the wire.
Access policy
Who may attach, and where.
Switch configuration
Access, trunk, VLAN, description, up/down, rename.
Cisco IOS-XE and Juniper Junos first, on purpose. Two vendors done properly beats six done shallowly — shallow vendor support is how you get a plausible config that is wrong.
Most tools help you type the change. EvoEther is for the sixty seconds afterwards.
A real engineer on a midnight change who cannot tell whether it worked — and cannot roll it back — is the design target. Junior staff hope. Senior staff know how they will find out, and how they will undo it. EvoEther is the second one.
The differentiator is not being right the first time. It is knowing fast when it is wrong.
Verification is the product
Every change is an approved change: reviewed, applied, read back from the device, reversible. Verification is not a safety rail around the product. It is the product.
An approved change, every time
Nothing of consequence is a fire-and-forget CLI paste. A change moves through a fixed sequence.
-
01
Validate
Is this legal for this device, port, prefix, site? If Evo is not sure, it refuses — and says why.
-
02
Snapshot
Capture what is there now, so reverse is a fact, not a hope.
-
03
Apply
Write the change to the live service or the switch.
-
04
Verify
Read the device back. Documentation and runtime are not allowed to silently disagree.
-
05
Record
Who authorised it, what Evo did, what the blast radius was, whether it verified.
Partial failure is not "left half-done." Compensating actions run in reverse order — the difference between a senior engineer and junior staff hoping it went through.
In the language an engineer already has
One place to work
You sign in to EvoConsole — the only customer way in. From there you see the site: devices, ports, prefixes, DHCP, DNS, IPAM, and what is in sync versus what has drifted. Evo is present as a colleague in that same console.
The device is the source of truth
Vendor documentation is a hypothesis; the switch is the measurement. Discovery reads the live box. If someone changed a switch outside EvoEther, the next discovery shows drift — EvoEther does not silently overwrite it. Where docs and the device disagree, the device wins.
DHCP, DNS, and IPAM move together
A prefix is not three tickets in three tools. When a site takes a subnet, the intent is one approved change: the prefix is owned, DHCP can serve it, DNS can name it. Connectivity stays visible as in sync, drift, or not provisioned.
Switches: Cisco and Juniper, for real
Ports, VLANs, trunks, descriptions, admin up/down, and device rename go through the same approved-change path — not a vendor's separate GUI. Cisco IOS-XE and Juniper Junos today, both tested on real hardware.
Evo, unprompted
A colleague does not wait to be asked. Evo watches health, syslog, and drift, and speaks up when something is worth an engineer's attention — rarely enough to matter. When you ask it to look, it cites what it used and can propose the change. You still approve.
If the WAN dies
The box in the rack keeps serving DHCP and DNS. Intent that could not be delivered waits and delivers when the path returns. Cloud-assisted does not mean cloud-dependent for the forwarding plane.
The appliance stays sealed
Customers do not get root, a shell, or an admin account on the appliance. CoNetworked operates the box; you operate the network through it. Evo holds the privilege on its own host because Evo is staff.
If you would have needed a shell to do something reasonable — a compliance report, evidence against an asset, a signed update, changing the management address — that is a product surface, not a reason to log in as root. Leaving EvoEther to open PuTTY or a vendor dashboard is treated as a defect.
Signed updates only
Updates arrive as a signed package. Evo verifies the signature, offers apply-now / wait / schedule, and applies it with its own privilege. Unsigned or tampered packages are refused before anything is unpacked.
A leased appliance, three editions
Same change pipeline, same Evo — a different place the console lives. Editions answer a compliance question, not a feature question. The features do not fork.
| Edition | Console | Connectivity |
|---|---|---|
| Cloud | CoNetworked cloud | Outbound from the site; no inbound ports |
| Private | Your datacenter | Optional maintenance window |
| Dark | On the appliance | Never — air-gapped by design |
Three things EvoEther is not
Not Ansible with a nicer theme
Playbooks do not read the port back and freeze a rollback as a first-class act.
Not a single-OEM controller
Not a vendor controller you use for one OEM and abandon for the next.
Not an LLM that invents a VLAN
Inference without a device read is how midnight changes become outages.
See the change pipeline on live hardware
EvoEther is in active development. The console, the change pipeline, and the device-backed workflow are demonstrated on live Cisco and Juniper hardware. Availability follows the lease and the edition.