Open-Source Dashboard Valet Lets Local LLMs Manage Your Homelab, With Approval Gates

TL;DR

Valet is a new open-source homepage for your homelab, with an optional assistant that can run on a local model through Ollama, read 185 integrations, and act on them once you approve. The permission model is the interesting part: read tools by default, write and control granted per integration, and no change runs until a human presses the button. The docs also publish the maker's token-budget tests, including a lazy tool-loading scheme that cut prompts by a third to a half on big setups at the same pass rate. Copy those parts even if you never install the dashboard.

What shipped

The repository appeared on October 29 and the launch posts went up November 7 on r/LocalLLaMA and r/selfhosted. It is MIT-licensed TypeScript: one Node process, about 45 MB of RAM on a fresh install, a 165 MB container image, and a single YAML file for configuration. The quick start is one Docker command pulling ghcr.io/askvalet/valet:latest on port 7575, and there is a live demo that runs in the browser.

The page itself is a status homepage in the lineage of Homepage or Homarr: services with status dots, live cards, a wall-display mode for a spare tablet, and a 3D floor plan that can drive lights and the vacuum through Home Assistant. The AI is optional. Leave the assistant block out of the YAML and Valet is just a pretty dashboard, a decision more products labeled AI-native should copy.

The model side is provider-agnostic: the default OpenAI-compatible provider covers llama.cpp and vLLM servers, LM Studio, OpenRouter and OpenAI, and Anthropic is a second built-in provider. The documented example config is qwen3:8b over Ollama. Tool calling is required; without it the assistant cannot read anything.

The valet key

The permission model is named for the valet key some cars ship with, which starts the engine but will not open the trunk. Every tool the assistant can call carries one of three access levels: read looks, write adds, control changes or removes. You grant them per integration in assistant.access, and the default is read for everything: a fresh install can look at the whole homelab and touch none of it.

Anything above read produces an approval card, and the model cannot press its own button. Approved or not, every non-read action lands in an activity log with who asked and whether it worked. The model never holds your API keys: Valet's server makes the requests, and tool results pass through a redactor before the model sees them. Without sign-in enabled, the assistant gets read tools and nothing else, whatever the config says.

The docs are candid about the limit: this guards what the model can do, not whether it is right. A wrong answer is still on the menu; a wrecked Pi-hole config is not.

The token math, published

The models page includes numbers most projects keep in a private notebook. On a busy homelab with about 90 tools connected, the first step of a chat costs about 16,000 tokens, and roughly 90% of that is tool definitions. A small local model reads all of it before it starts, so the first answer is slow no matter which small model you picked.

The fix is tools: lazy: the assistant starts with Valet's own tools plus one line per connected integration, and loads a service's full tools when a question actually needs them. A card catalog instead of the whole library. In the maker's tests against a local model, this cut prompt tokens per answer by about a third on the ~90-tool setup and nearly half on a ~120-tool setup, with the same pass rate, for one extra step and about two seconds on a fast GPU. An auto mode switches to lazy once tool definitions reach about 6k tokens.

The rest of the page reads the same way. Dropping maxSteps to 4 or the context window to 32k made answers worse, so the defaults stay. Turning reasoning off made the model two to three times faster, and it began answering follow-up questions without checking and invented values. The trade is documented next to the switch.

Rules that run without the model

Recurring automation does not need the model at runtime. Rules ("when this happens, do that") and watch reminders ("tell me when this download finishes") are approved once, then checked by plain code with no model involved. Setup goes through the assistant and counts as control; execution is a cron-shaped loop that would keep working with the GPU unplugged.

Background model use is budgeted like a resource. The watch, brief, and suggest calls get no tools, so they can only talk. They run one at a time so a single GPU is never asked to do two things at once, and they stop at a daily cap, 100 calls by default. When two or more services break together, one background call asks whether a single cause explains them.

It reads its own manual

The assistant's toolset includes docs_search and docs_read, so it answers questions about Valet from Valet's own documentation, including how to configure Valet. With config access granted, it can help edit the YAML it runs from, proposed through the same approval card as any other change. There is also report_issue, which drafts a filled-in GitHub issue for you to submit and sends nothing, which is more restraint than most software shows.

What to steal

• Default to read. A fresh install with an assistant should be able to look and nothing else, with write and control granted per integration, per tool, by a human.
• Keep the keys away from the model. Valet's server holds credentials, calls the services, and redacts results before the model reads them. That boundary works in any agent design.
• Load tools lazily and publish the numbers. One line per integration plus fetch-on-demand cut prompts by a third to a half at the same pass rate. If your agent talks to dozens of integrations, this is the pattern.
• Compile recurring automation out of the model. Approve once, run modelless rules; the GPU bill and the failure modes both shrink.
• Budget background calls. No tools, one at a time, a daily cap. Unbounded background agents are how a homelab quietly grows a cloud bill.
• Publish the negative results. The docs say which fast settings made answers worse, and that section will save someone an afternoon.

Caveats

• The token and pass-rate numbers are the maker's own tests, with no published methodology or prompts. Treat them as directions, not benchmarks.
• The project is days old and, by the launch posts, reflects one person's design decisions tested on one homelab. Expect rough edges and a single-maintainer bus factor.
• Approval gates bound what the model can change, not what it says. The docs say so themselves.
• A hosted provider sees your tool results, minus the values redacted from config variables. The local path is the point; a hosted model is the convenience option.
• Tool calling is required, so very small local models cannot drive the assistant at all.

Key Takeaways

• Valet is an MIT-licensed, self-hosted homelab homepage (TypeScript, one Node process, about 45 MB RAM) whose optional assistant runs on local models through Ollama, any OpenAI-compatible server, or Anthropic.
• Permissions follow a valet-key model: read by default, write and control granted per integration, every non-read action behind an approval card and in an activity log. With no sign-in, the assistant is read-only whatever the config says.
• API keys never reach the model; the server makes requests and redacts tool results first.
• With about 90 tools connected, a chat's first step is about 16,000 tokens, roughly 90% of it tool definitions. Lazy tool loading cut per-answer prompts by about a third on 90 tools and nearly half on 120, at the same pass rate, for one extra step of about two seconds.
• Rules and watches are approved once and then run without the model; background calls carry no tools, run one at a time, and cap at 100 a day by default.
• The assistant can search its own docs, help edit its own config through the approval flow, and draft GitHub issues without sending them.

Sources: Valet on GitHub, Valet assistant docs, Valet models docs, Valet security docs, launch thread on r/LocalLLaMA, live demo