Twenty-one servers, one thing, once.

The tree is the palette and the board is the canvas. Drag one server, a whole group, or the entire map; each becomes a card. A card is coloured by the only thing that matters before you press anything: can Lens reach that box right now. Green is a live shell. Amber is a saved login being tried. Anything that will need you to log in by hand says so, and every screen that runs work says how many boxes it skipped rather than quietly leaving them out.

The cards carry what the map knows, too — the address, the group, pending updates, a restart owed — so the board doubles as a status board before it is a work board. Save it under a name and it is there tomorrow.

Type a command, or pick one of the questions an operator asks a fleet most mornings — uptime and load, disk usage, memory, the busiest processes, failed services, the OS and kernel, listening ports, recent logins, who is on, whether a restart is needed, and as root, recent errors or a package-list refresh. Picking one fills the box; it never runs on its own. What goes out is always in front of you before you press.

Answers land as they finish, one card per server, each with the exit code and how long it took. Rows that failed open by default, because those are the ones you came for. Nothing is merged into a single stream you would then have to untangle — eighteen boxes, eighteen answers, read as eighteen answers. And there is a switch for whether it runs as your login or as root, so a read stays a read.

Execute gives you text. Find out gives you an answer. Each of its questions has its own parser, so what comes back is one value per server — and then those values are grouped. Ask which CPU the fleet runs and you do not get eighteen paragraphs of lscpu: you get three groups, fifteen boxes on one processor, two on another, one on something else entirely. That is the finding. The odd one out is visible in a second instead of being scrolled past.

The catalog runs to a couple of hundred curated questions, folded into network, services, packages and OS, users and access, security posture, storage and load, hardware and host, and the ones that need root — with a search box, because nobody scrolls a list that long. Anything a question needs, a port, a package name, a threshold, is asked above the button, and the raw output is always one click away for the box you want to look at properly.

Pick the thing a server ought to have — Fail2Ban, ufw or firewalld, CrowdSec, ModSecurity, unattended upgrades, auditd, AIDE, debsums, the rootkit hunters, the AppArmor or SELinux tools, password quality, nginx, Apache, Caddy, PHP-FPM, certbot, ProFTPD, vsftpd, chrony and the rest — and Lens asks every board member whether it already has it. Two columns come back: has it, and does not.

Then one button installs on all thirteen that lack it, or you install a single row. Each one is the same root job the server's own tab would run, watched here, and the box is asked again afterwards — so the row does not say "installed" because Lens assumes it worked; it says it because the box said so.

This is the one that saves a morning. Add a user on every server, give or take sudo, add an SSH key, lock or unlock, delete, add a group, put someone in one, grant a folder, open or close a firewall port, turn the firewall on, set up Fail2Ban, harden sshd, run something as a service, turn on automatic updates, set the timezone, turn NTP on.

None of it is a second implementation. Each verb goes through the same code path the server's own screen uses, with the same refusals — the firewall never strips your SSH cover, sshd hardening is still proven by a fresh login. Twelve boxes are worked at a time, and a row per server says what happened on it, including the ones that asked for a sudo password.

The onboarding case is the whole point. One card creates the same account on eighteen machines with a shell, sudo, and a key — and if you choose "a key made here", Lens generates the pair on your computer, gives the servers the public half, and asks you where to save the private one. That file is handed to the person and Lens keeps no copy of it.

Opening a port on a fleet is where hand-rolled scripts go wrong, because the boxes do not agree: some run ufw, some firewalld, some have neither. Lens reads each box first and speaks whatever it found — and refuses, on every one of them, to write a rule that would remove your own way in. Setting up Fail2Ban across a board is the same story: one file per box, the package installed where it is missing, and each row reporting for itself.