One folder, ten servers. Checked first, and undone in one press.

Everything a shell script would hard-code is a field you can read a year later. What goes: one folder or several, and for each whether its contents land straight in the destination, the folder itself does, or a subfolder you name — shown as a real path, so the trailing-slash mistake cannot happen. Where to: servers ticked one by one, or whole groups, and a group means whoever is in it on the day, so a server added next month is included then. Into which folder, and whether a box that lacks it should have it made. As the login, or as root. What is run before the files go in and after.

And what never leaves your computer: an ignore list, one for the whole deployment, that starts with the usual — version control, node_modules, logs, and .env, so a local secret never overwrites a server's. It is yours to empty if you mean to send everything.

Check & deploy asks every box of every route at once, as its own login, and changes nothing by asking. Can this login write that folder, and if not, who owns it. Is the folder there, and if not, will it be made. Is there room for the new files and for what they replace. Are the programs your commands call really on that box — looked for in the same shell the commands will run in, which is where a program installed under a version manager lives and a bare SSH command never finds it. Would a sudo in the commands stop and wait for a password nobody can type.

The answer is one list, what needs fixing first, with the fix beside each line. These screens are from a real run. Six of sixteen servers were consoles, and a route that runs as root is refused on a console by name — so the button reads "Deploy to the 10 ready" and says who is left out. Then the list caught that the commands called a program none of the ten boxes had, before anything had been stopped to find that out.

One button sends to every ready box, route by route. The first server of a route goes by itself: if what you are sending is bad, one box finds out, not the fleet. When it has come through, the rest follow a few at a time — three unless you say otherwise — and the roll stops at the first failure. Servers already working finish their run, none is started after, and every server that never had its turn is said to have been skipped.

On each box the network never touches the live folder. What is new or changed is uploaded into a holding folder beside it and verified there, file by file, by hash. Only then do your commands before run, what is about to be replaced is kept, and each file is renamed into place. A link that drops halfway leaves a folder to delete and nothing else. Putting the files in place is renames on the server's own disk, not a transfer — and that, not the upload, is how long something stopped for the change stays stopped.

Vigia does not compare dates or sizes. It hashes every file on your computer and asks each server for the hashes of the same paths — only those, so what you are not sending is never read. A file with one character changed is found; a file that was only re-saved is not sent. Here one file out of 1,973 had been edited, and that is exactly what travelled.

The file it replaced was kept first, on the server, so the run can be undone there. A roll hashes a route's files once and judges every box against that one list — so a file edited in the middle of a roll fails its verification on the next box instead of landing, changed, on half the fleet.

Vigia already opens any server's files over the same login, six panes to a page. After a roll, the destination on six servers side by side is one screen: the same names, the same sizes, and the one file that changed carrying the same date on every box.