A senior network engineer, leased, running on a box in your rack.
EvoEther is not a dashboard with an assistant bolted on. It is a colleague that lives on an appliance in your environment: 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.
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.
Validate → Snapshot → Apply → Verify → Record
- 01
Validate
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.
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, a signed update, changing the management address — that is a product surface, not a reason to log in as root.
Signed updates only
Evo verifies the signature and applies with its own privilege. Unsigned or tampered packages are refused.
No PuTTY, no vendor dashboard
Leaving EvoEther to get work done is treated as a defect — something was slow, missing, or unclear.
A leased appliance. Three editions.
Same change pipeline, same Evo. The edition answers a compliance question — who may see management traffic — not a feature question. The features do not fork.
Cloud
Hosted EvoConsole. The appliance dials out — no inbound ports. Local DHCP and DNS keep serving if the WAN drops.
Private
The console sits in your datacenter. Management traffic never has to leave your perimeter.
Dark
The entire stack runs on the appliance. No cloud to call. No internet, by design. Inference stays local.
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. Availability follows the lease and the edition.