HomeLab Monitor 0.38 adds an AI agent with constrained permissions

The hard part is not asking questions

Natural-language queries are useful in a homelab, but the sensitive part begins when an assistant can change machines. Restarting a container, cleaning images, or trimming logs are ordinary jobs, yet they can still break a service when automation lacks context. What stands out to me in HomeLab Monitor 0.38 is not simply the addition of AI, but the attempt to put technical boundaries in place before the agent is allowed to act. (github.com)

This release adds an optional agent inside the HomeLab Monitor dashboard. It answers questions about the infrastructure through the same read tools exposed by the project’s MCP server, rather than relying on a generic description of the environment. It can work with local model servers discovered on the network, including Ollama, vLLM, and llama.cpp, alongside other compatible options. (sikamikanikobg.github.io)

An agent without unrestricted shell access

The key design choice is that the agent does not receive an open shell. Its available operations come from a fixed catalog, covering tasks such as starting or restarting containers, removing dangling images, clearing build cache, shrinking the journal, unloading models, or checking disk use. That does not remove all risk, but it prevents a natural-language request from becoming an arbitrary SSH command. (sikamikanikobg.github.io)

Each host can be set to Off, Passive, or Active. New hosts start in Passive mode, which allows read-only access, while Active permits changes within the configured policy. Every action is also decided per host with Deny, Ask, or Allow, and the default is Deny. (sikamikanikobg.github.io)

Policy enforcement does not depend on trusting the model. The server checks the policy when the agent proposes an operation and checks it again immediately before execution, including after a manual approval. Protected targets include the monitor container itself and the service running the selected model, which is a sensible way to keep the agent from taking down its own control path. (sikamikanikobg.github.io)

Starting with less access is the right default

I would keep the agent disabled while reviewing hosts, SSH access, and alerting. The documentation says that AGENT_ENABLED=0 hides the agent and makes /api/agent/* routes unavailable, while ENABLE_HOST_RUN=0 keeps the legacy arbitrary-command endpoint disabled. The agent does not use that free-form execution route, but it is still worth making sure it remains closed. (sikamikanikobg.github.io)

environment:
  AGENT_ENABLED: "0"
  ENABLE_HOST_RUN: "0"

When it is time to enable the feature, HomeLab Monitor requires a dashboard password and a completed setup flow. The system tests whether a model can make tool calls, because a model that only produces text cannot reliably inspect the real state of the homelab. For scheduled work, it also checks whether the model can follow a tool result with another informed step. (sikamikanikobg.github.io)

Automation without dropping human review

Automations can start from templates for Docker cleanup, disk-space monitoring, container health, system maintenance, or backup freshness. They can run on a schedule in three modes: report only, propose changes for approval, or act within policy. That split matters because it lets me observe a routine in reporting mode before allowing it to modify anything. (sikamikanikobg.github.io)

Unattended changes are more constrained than manually approved ones. Allowed low-risk tasks can run on their own, but there are per-target limits, while medium-risk, high-risk, and privileged actions wait for approval except where explicit rules say otherwise. Restarting privileged services and shrinking the system journal, for example, are not unattended operations. (sikamikanikobg.github.io)

There is an audit trail as well. The activity view records tool calls, policy decisions, approvals, and outcomes for each run, with JSON and CSV export. Actions are also written to the container output, which is useful when I want an audit copy outside the application database. (sikamikanikobg.github.io)

The limitations matter more than the chat

This is not a universal infrastructure administrator, and that is a good thing. The documented scope excludes rebooting machines, removing volumes, and deleting files, while a permissive policy is no substitute for verified backups. If a job needs a complex sequence, depends on application-specific knowledge, or involves an ambiguous production state, established procedures and human review are still the better option. (sikamikanikobg.github.io)

Using a local model keeps more information inside the network, but it does not make an insecure homelab secure by itself. When a cloud provider is selected, it receives the question and the tool results read by the agent, potentially including host names, container names, metrics, and log excerpts. Before enabling that option, I would check both the data the agent can collect and the provider that will receive it. (sikamikanikobg.github.io)

I would not assume that a small model will handle multi-step maintenance well either. HomeLab Monitor tests tool calling and distinguishes between models that can be used by the agent and those that cannot, but decision quality still depends on the model and on the information available. My approach would be to use it first for inspection and reporting, then enable only repetitive actions whose consequences I already understand. (sikamikanikobg.github.io)

HomeLab Monitor 0.38 is not trying to sell a fully autonomous operator. It offers a way to introduce automation with brakes: host-level permissions, restricted actions, confirmations, budgets, and activity records. In a homelab full of personal services and years of accumulated configuration, I would take that over an agent with unlimited access by default. (github.com)

Source: v0.38.0 release notes. Official documentation: HomeLab Monitor AI agent.