Watch
ECOP explained in five short videos
Start with the overview, or jump to the part you care about. Each one is under two minutes, narrated, with captions and a transcript.
1 of 5 · 1:43
ECOP explained: one control plane for every server you run
Forty servers, patched by hand, every month. ECOP is the control plane for every server you run: one small agent per server, the whole fleet on one screen, patching in safe waves, compliance you can prove, and an AI operator that asks before it acts.
Chapters
Read the transcript
0:00 · Forty servers, patched by hand
Forty servers, patched by hand, every month. Someone logs in to each one, runs the updates, and hopes nothing breaks. ECOP is the control plane for every server you run. Here's how it works.
0:13 · One agent per server, one screen for the fleet
Every server gets one small agent. One command installs it. It checks in about every thirty seconds, over an encrypted link that both sides verify. Packages, ports, services and health. So ECOP always knows what you really have. Here's our demo fleet: thirty simulated servers and two real virtual machines. Health, jobs, vulnerabilities and risk, on one screen.
0:39 · Patch in safe waves
Patching runs in waves. A small canary wave goes first. Later waves can wait for a person to approve them. If more servers fail than the limit you set, the campaign pauses itself.
0:51 · Prove it's compliant
ECOP scans each server against CIS benchmarks with OpenSCAP. It can apply the fix, then scan again. The second scan is the proof. And every vulnerability gets a deadline, set by its severity.
1:04 · An AI operator that asks first
The AI operator reads the fleet, plans the change, and does the typing. But first, it shows you the exact request it wants to send. Your approval covers that one request, once, for ten minutes. And AI changes stay off until an admin turns them on.
1:20 · New servers arrive enrolled, and where to see it live
Need a new server? Deploy it from a Proxmox template, and it enrolls itself on first boot. Every change, by a person or the AI, lands in the audit trail. To see it live, talk to Rowan, our AI host, at 404ops.com/demo/ecop.
2 of 5 · 1:17
Patch a server fleet in safe waves: canary, approvals, auto-pause
Patching every server at once is fast, until one bad update breaks all of them. ECOP patches in waves instead: a canary first, later waves that can wait for an approver, and a campaign that pauses itself when more servers fail than the limit you set.
Chapters
Read the transcript
0:00 · Why waves
Patching forty servers at once is fast. Until one update breaks something, on every server, at the same time. ECOP patches in waves instead, the way a kitchen tries a new dish on one table before it goes on the menu. The first wave is the canary: one server, or a small slice of the fleet. Later waves can wait for an approver. And by default, the person who asked can't approve their own wave.
0:26 · A failure limit you set
You choose a failure limit. If more servers fail than that, the campaign pauses itself. Pausing stops new waves. Anything already running finishes, and you can retry just the servers that failed.
0:38 · Some packages stay put
Got a package that must not change? Accept it as an exception, with a reason, an owner and an expiry. ECOP holds that package on the server for the run, and keeps any holds that were already there.
0:52 · Schedules and a real run
Patch cycles run all of this on a schedule, monthly or weekly, and skip or shift around a freeze. Here's a real campaign on our demo fleet: a canary on the Debian server, then the Rocky server, set to pause above fifty percent failures. See it live at 404ops.com/demo/ecop.
3 of 5 · 1:15
Prove your servers are compliant: CIS scans, fixes and evidence
ECOP runs OpenSCAP on each server against CIS benchmarks, fixes failures once a person approves, then scans again, because the second scan is the proof. It also puts a deadline on every CVE and keeps exceptions in the open.
Chapters
Read the transcript
0:00 · Scanned on the server
Ask a team if their servers are hardened, and they'll say yes. Ask them to prove it, and it goes quiet. On each server, ECOP runs OpenSCAP against CIS benchmarks, level one or level two. Every failed rule shows up by name, with the server it failed on and when it was first seen.
0:19 · Fix, then check again
Choose remediate, and once a person approves it, the agent applies the fix for that profile. Then it scans again. A clean script isn't proof. The second scan is.
0:31 · Drift gets caught
Every five minutes, ECOP checks each server against your policies, and raises an alert when one drifts. And a server that has never been scanned never counts as compliant.
0:41 · A deadline for every CVE
Vulnerabilities get deadlines too: by default, seven days to fix a critical, and thirty for a high. Known exploited ones are flagged, so they go to the top.
0:52 · Exceptions, in the open
Can't fix something yet? Accept it, with a reason, an owner and an expiry. It stays visible, and when it expires, the finding comes back.
1:02 · Evidence, on schedule
Scheduled reports send the evidence, with a grade, to whoever needs it. See it live at 404ops.com/demo/ecop.
4 of 5 · 1:22
An AI operator that asks before it acts
ECOP's assistant reads your fleet and does the typing. Before anything changes, it shows you the exact request it wants to send, and your approval covers that one request, once, for ten minutes.
Chapters
Read the transcript
0:00 · It does the typing
Would you hand an AI the keys to your servers? Most teams wouldn't. ECOP doesn't ask you to. ECOP's assistant reads your fleet: health, jobs, vulnerabilities and compliance. Ask it to patch three web servers, and it plans the campaign for you.
0:16 · Then it stops and asks
Before anything changes, it shows you the exact request: the method, the route, and every value it will send. Its reasoning sits in a separate box, marked as written by the model. The request is what counts.
0:30 · One approval, one request
Approve it, and that approval covers that one request, once, within ten minutes. Change a single byte, replay it, or wait too long, and it won't run.
0:41 · Your rules, and what it can never do
Normal permissions still apply. And if the campaign itself needs a human sign-off, it still waits for one. AI changes stay off until an admin turns them on. And some things it can never do: approve, change your policy, or accept an exception.
0:58 · An AI company, on a leash
You can also hire AI agents, like a patch manager or a compliance officer. They file change requests. Your autonomy settings decide which ones wait for a person. Everything lands in the audit trail, and one button pauses them all. Ask Rowan about it at 404ops.com/demo/ecop.
5 of 5 · 1:16
Deploy a server on Proxmox, enrolled on first boot
In ECOP a new server is four steps. ECOP clones your Proxmox template, and cloud-init installs the agent on first boot with a single-use key, so the server joins the fleet as active.
Chapters
Read the transcript
0:00 · Four steps to a new server
A new server usually means: clone a template, set it up, install the agent, and remember to add it to monitoring. In ECOP, deploying a server is four steps: pick a pool, choose the size and name, set enrollment, and review. Need more than one? Deploy up to fifty in one go.
0:19 · Cloned on Proxmox, enrolled on first boot
On Proxmox, ECOP clones your template, grows the disk to the size you asked for, and boots it with cloud-init. On first boot, cloud-init installs the agent with a single-use key that expires in a day. Nothing to copy and paste. The server joins the fleet as active, and reports its packages within seconds.
0:40 · Then manage it
From then on, you can power it, snapshot it, resize it, or schedule it for deletion, from one page. Built one just right? Capture it as a golden image, and deploy the next ones from it.
0:53 · More than Proxmox, and two real VMs
ECOP also has providers for VMware vSphere, Amazon Web Services and DigitalOcean. The two real servers in our demo fleet, Debian 13 and Rocky 9, were deployed this way. See them live at 404ops.com/demo/ecop.