Homebutler
PassAudited by ClawScan on May 10, 2026.
Overview
Homebutler is a coherent homelab administration skill, but it documents powerful commands that can change Docker apps and remote servers.
Install only if you trust the external homebutler CLI and intend to let the agent help administer your homelab. Before using mutation commands, confirm the exact server, container, app, and scope, and be especially careful with `--all`, upgrade, deploy, purge, restore, and sudo-related operations.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run on the wrong target, these commands could stop services, restart containers, or change deployed applications.
The skill exposes commands that can modify running services and installed applications. This is aligned with homelab operations, but it is high-impact operational authority.
homebutler docker restart <name> # Restart a container; homebutler docker stop <name> # Stop a container; homebutler install <app> # Install an app (docker compose)
Require explicit confirmation for stop, restart, install, uninstall, purge, backup/restore, deploy, and upgrade actions; prefer status/log commands before making changes.
An agent using this skill may act with the same access as the configured SSH account and could alter remote server binaries or configuration.
Remote SSH and sudo-capable install paths imply use of privileged server access. This is expected for remote server administration, but users should treat it as sensitive.
For remote servers, uses SSH to upgrade. ... Install path priority: `/usr/local/bin` → `sudo /usr/local/bin` → `~/.local/bin`
Use dedicated least-privilege SSH credentials where possible, verify host keys before trusting or resetting them, and approve any sudo or remote deployment action.
A future upstream release could change behavior or introduce vulnerabilities, especially if upgrade or deploy is run across multiple servers.
The setup and upgrade flow can fetch the latest external release rather than a pinned version. This is disclosed and user-directed, but the downloaded binary is not reviewed in these artifacts.
go install github.com/Higangssh/homebutler@latest ... Downloads latest release from GitHub and installs it.
Install from trusted release channels, consider pinning a reviewed version, and avoid automatic upgrades unless you trust the upstream project and release process.
A mistaken command or bad update could affect several servers at once instead of one machine.
The skill documents fleet-wide commands that can operate on all configured servers. This is coherent for homelab management but increases blast radius.
homebutler status --all # All servers in parallel; homebutler upgrade # Upgrade local + all remote servers; homebutler deploy --all # Deploy to all remote servers
Run actions on one named server first, review the result, and use `--all` only when a fleet-wide change is intentional.
Saved snapshots may reveal internal topology, service names, and open ports to anyone with access to the report files.
Reports can persist operational snapshots containing system, container, and port information. This retention is disclosed and purpose-aligned.
homebutler report --keep 7 # Retain latest 7 snapshots ... It snapshots current system/container/port state and compares it with the previous run.
Use `--no-save` for sensitive one-off checks and keep snapshot retention limited to what you actually need.