Fleet in Check: I Now Manage Half My Homelab from Claude Code

If you run more than one Linux server, you know the drill: the Raspberry Pi in the closet, the VPS at your host, the mini PC with the Docker containers. For each one you type ssh user@…, hunt for the right port and try to remember whether it was 192.168.1.5 or .15. Three terminals, five SSH configs — and by the fourth server you have lost track.

That is exactly where I started building Fleet Manager: a plugin for Claude Code that pulls your entire server fleet into a single session. Instead of juggling connections, you say /status, /health-summary or /compose-up monitoring — and Claude knows which server you mean.

TL;DR

• What: a Claude Code plugin for multi-server SSH management
• For whom: homelabbers and admins with several Linux hosts
• Cost: none — open source under MIT
• Core idea: one inventory, one active server, clear commands instead of SSH chaos

The real problem isn't SSH — it's context

SSH works just fine. What grates is the context around it: which server was which again? Does the monitoring stack run on the Pi or the VPS? Did I already mirror the backup directory? That knowledge usually lives in your head (or in a sprawling ~/.ssh/config).

Fleet Manager writes that knowledge into an inventory: one profile per server with connection details, detected operating system, Docker status and the allowed operations. One of the servers is always the active one — the default target when you do not name a server. And so you never accidentally land on the wrong host, every command prints its target first:

→ Ziel: homeserver (pi@192.168.1.5:22)

Set up in five minutes

Setup is deliberately guided. After installing the plugin you start the onboarding assistant:

/plugin marketplace add CallMeTechie/fleet-manager
/plugin install fleet-manager@fleet-manager
/first-run

An intake agent asks for name, host, port and SSH user. Then /setup-ssh takes care of the key — Fleet Manager uses its own dedicated Ed25519 key and does not mix with your other keys. You deploy the public part with a one-liner the plugin gives you to copy:

! ssh-copy-id -p 22 -i ~/.ssh/fleet-manager_ed25519.pub pi@192.168.1.5

The leading ! matters — it opens a real terminal in Claude Code for password entry. Finally, /diag checks that everything is in place: SSH, sudo, Docker, disk space. Done.

The commands I use every day

My first move in the morning is the fleet overview:

/health-summary
  SERVER        STATUS  OS            DISK/ LOAD MEM   DOCKER
* homeserver    UP      Ubuntu 24.04  45%   0.8  62%   yes
  vps-web       UP      Debian 12     28%   1.2  71%   no
Verdict: 2/2 up

One row per server, one SSH call per host — and I see at a glance whether something is off the rails. Then I drill down:

• /status vps-web — disk, RAM, uptime and load of a single server
• /compose-list and /docker-list --all — which stacks and containers are running?
• /compose-up monitoring or /compose-update monitoring — start a stack or update its images
• /logs homeserver sshd --tail 50 — a quick look at the journal

And when I need to move a compose file or a backup, /copy and /sync handle the transfer — with the handy <server>:<path> syntax:

/copy ./docker-compose.yml homeserver:/srv/monitoring/
/sync /srv/data homeserver:/backup/data            # preview (dry run)
/sync /srv/data homeserver:/backup/data --apply    # actually transfer

Security: deliberately a little paranoid

A tool that runs commands on multiple servers over SSH has to be careful. That is why security is built into Fleet Manager's design:

• Per-server scopes: each profile only unlocks what is allowed. No /compose-down without docker_compose, no /sync without file_transfer — the command simply refuses.
• Dry run by default: /sync first shows what would happen. Deletion (--delete) additionally requires a typed confirmation token.
• Critical stacks protected: projects in critical_compose_projects can only be stopped with --confirm=<project>.
• No blind trust: Fleet Manager does not disable host-key checking. The first connection to an unknown host fails on purpose instead of accepting a potentially planted key.
• Your data stays local: hosts, users and keys never end up in Git — the real profiles are git-ignored, only templates are checked in.

To be honest about it: the confirmation tokens are a safeguard against accidental runs, not an impenetrable gate. They make intent visible on the command line — more than that, but no less either.

Conclusion

Fleet Manager doesn't do the thinking for me, but it does away with the juggling. I no longer have to memorize hosts, ports and users, I see the state of my whole fleet in one line, and I control Docker stacks without fumbling around first. For a homelab with a handful of servers, that is exactly the right mix of convenience and control — and because it is open source, it costs you nothing but five minutes of setup.

The code lives on GitHub. If you run several Linux servers and use Claude Code: give it a try and tell me what is still missing.