Use cases · Server maintenance
Patch a fleet of Linux servers by asking for it
A new OpenSSL or PHP fix lands and you have twelve servers: a few Ubuntu LTS, a couple of Debian boxes, one Rocky machine nobody wants to touch. The usual routine is to SSH in one by one, or keep an Ansible playbook alive for a job you do once a month. With Octling you say what you want and watch it happen on one server before it touches the rest.
“Which servers have pending security updates? List the packages, don’t install anything yet”
“Install only the security updates, restart services that use the old libraries, and tell me which machines still need a reboot”
What a run looks like
- Connect the servers once. Each one runs a one-line install command, or you create a deployment pack and paste the same command on all of them.
- Ask for a dry run first. The AI checks each machine with the tool that fits it (
apt list --upgradable,dnf updateinfo,zypper lp) and gives you one list per server. - Start the real run as a batch task with “Confirm on the first device, replay on the rest”. The AI patches one server, and you read exactly which commands it ran and what they printed.
- If that looks right, confirm. The other servers replay the same command sequence. Any that fail are listed separately, and you can retry just those.
Where it is honest to be careful
Mixed fleets are where replay can bite: a command sequence recorded on Ubuntu will not work on Rocky. Group servers by distribution and run one batch per group, or switch the batch to “Follow command rules”, where the AI handles each server on its own and anything that needs approval is skipped.
Octling does not take snapshots or roll anything back. Snapshot first if the server matters. Put reboot, shutdown and package removal in your approval rules so they always wait for you.
Make it a routine
Save the dry run as a scheduled batch task, for example every Monday morning, and you get a list of what is pending without anyone logging in. Inspection rules can also run any custom command on a timer, so a check like test -f /var/run/reboot-required can notify you when a server is waiting for a restart.
Questions
- Is this just an AI with root on my servers?
- No. A temporary connection runs as the user who started it. Commands matching your approval rules wait for a click, high-risk commands are blocked outright, and everything the AI runs is written to an audit log with its output. Whether it can use sudo depends on the account you connect it with.
- Does Octling roll back a bad update?
- No. Octling runs commands, it does not snapshot your disks. Take a VM or volume snapshot before patching anything you care about, the same as you would by hand. The AI can run the snapshot command for you if your provider has a CLI.
- What about reboots?
- Ask for what you want: "don't reboot, just tell me which servers need one" works, and so does "reboot one server, wait until it is back and healthy, then do the next". Add reboot and shutdown to your approval rules if you want a human to confirm every restart.
- Do my servers need an open SSH port or a VPN?
- No. The agent on each server opens an outbound connection to Octling, so nothing needs to listen for inbound traffic.
Related: clean up disks on every server · deploy software to many machines