HomeRail: A Voice-First DAG Runtime for Homelab Agent Workflows
Voice-first local agent orchestration runtime for auditable DAG workflows.
At a glance
- What is it?
- HomeRail is a TypeScript runtime that turns one-off agent chats into auditable, reusable DAG workflows, designed for homelab and NAS environments. It combines a voice interface, a generative UI, and a Docker-based worker model, but it is still early beta with notable platform constraints.
- Who is it for?
- HomeRail is for homelab and NAS owners who want to move from unstructured agent chats to replayable, auditable workflows, and who are comfortable with a CLI-first, beta-stage tool. It is not for those who need a polished GUI, Windows-native shell support, or a stable API, as the generative UI is still exploratory and Windows requires Git Bash.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
From Black-Box Chats to Inspectable DAGs
HomeRail is built around an inverted funnel: narrow at the human end (voice or text input) and wide at the machine end (a DAG of agents). The voice surface is the preferred input because it asks the least of you. Text remains available for quiet settings or precision. The system collects intent across turns before acting, narrowing ambiguity before execution. Behind that, the DAG engine handles multi-agent orchestration with explicit handoffs, workspace isolation per run, replay, scorecards, and run evaluation. A chat session is ephemeral and opaque; a DAG is a graph you can inspect, replay, and improve. HomeRail sits between the two, making the workflow auditable without forcing you to read logs or JSON.
The Architecture: Manager, Node, and Docker Workers
The CLI `hr` is the primary way to operate HomeRail. It exposes commands like `start`, `config`, `doctor`, `run`, `smoke`, `dag supervise`, `scorecard`, `eval-run`, and `replay`. The README is written to double as an agent-readable runbook: you can hand the whole file to an agent like Claude Code or Codex and ask it to install, configure, and verify HomeRail. This is a distinctive design choice: the tool is meant to be operated by agents as much as by people. The commands are self-describing, and each step in the README says what to expect. This lowers the barrier for automation but also means that human users must be comfortable with a CLI and with delegating setup to an AI agent.
Getting Started: Commands and Configuration
The CLI also supports a browser Agent UI via `hr start --ui`, with defaults at Manager `http://localhost:19191`, Agent UI `https://localhost:19192`, and HTTP fallback `http://localhost:19193`. The UI is described as "generative" and "in exploration": instead of dumping logs or JSON, the agent produces structured, generated views meant to be read at a glance. The contract and widget set will keep changing. This means the UI is not stable, and the README explicitly says its shape is still being designed through real use cases. For a tool that claims to ask little of your attention, a changing UI is a potential source of friction.
Limitations and Failure Modes
HomeRail has several genuine limitations. First, Windows support is partial: the CLI must run from Git Bash or another POSIX-compatible shell because some scripts assume a Unix-like shell and will not run correctly under `cmd.exe` or PowerShell. Second, Linux networking may need extra setup: the README notes that Worker-to-Manager networking may require configuration of Worker callback URLs. This is a common Docker-on-Linux issue with host networking, and it could block live agent runs. Third, the generative UI is explicitly in exploration, so its shape is not stable. If you depend on a consistent UI, this is a risk. Fourth, the project is in early beta (v0.1.0-beta.1), with alpha releases just days before. The README does not mention any production use, so you should expect bugs and breaking changes. Fifth, the system requires a Claude Agent SDK-compatible model endpoint for live runs; if you do not have one, you can only use the offline deterministic profile, which limits you to template-based, non-model workflows. Finally, the README mentions multi-round DAGs for workflows that pause at durable command boundaries, but the documentation is truncated, so the exact mechanics are not fully described. This is a gap you should verify before relying on that feature.
Alternatives: n8n and Windmill
The closest alternatives to HomeRail are self-hosted workflow automation platforms like n8n and Windmill. n8n is a node-based visual workflow tool that supports hundreds of integrations, has a mature UI, and runs on Docker. Its approach is fundamentally different: you build workflows visually by dragging and connecting nodes, and it is not voice-first. Windmill is another self-hostable workflow engine that uses scripts and flows, with a focus on developer productivity and a web UI. Both n8n and Windmill have larger communities, more stable APIs, and broader integration ecosystems than HomeRail. However, neither is voice-first, and neither generates a UI from agent output. HomeRail's differentiator is the voice surface and the auditable DAG runtime designed specifically for agent orchestration. If you need a general-purpose automation tool with a stable GUI, n8n or Windmill are safer bets. If you want voice-driven, agent-centric workflows with replay and scorecards, HomeRail is the only one in this comparison that offers that out of the box.
Maintenance and Upgrade Cost
The repository is actively developed, with releases v0.1.0-alpha.2.2, v0.1.0-alpha.3, and v0.1.0-beta.1 all within a few days in late July and early August 2026. This indicates a fast iteration pace, which is good for feature velocity but bad for stability. The README does not mention a migration path or upgrade guide, so you should expect breaking changes between beta releases. The CLI commands are self-describing, which helps with discoverability, but the underlying configuration format (WorkflowSpec v1) is versioned, and the README warns that changing `workflow_id` creates a new identity. This suggests that upgrading may require re-syncing workflows and profiles. The license is MIT, which is permissive and imposes no copyleft obligations, but it also means there is no commercial support. You are responsible for maintaining the runtime and any custom workflows. The Docker Worker model means you must keep the `homerail-worker:latest` image up to date, which the Manager can rebuild asynchronously via `hr start --rebuild-worker-image`. This is a concrete maintenance task: you need to monitor image builds and ensure Docker resources are adequate.
Editorial conclusion
HomeRail is for homelab and NAS owners who want to move from unstructured agent chats to replayable, auditable workflows, and who are comfortable with a CLI-first, beta-stage tool. It is not for those who need a polished GUI, Windows-native shell support, or a stable API, as the generative UI is still exploratory and Windows requires Git Bash. Before adopting, verify that your model endpoint is Claude Agent SDK-compatible, that Docker networking on Linux is configured for Worker callback URLs, and that you accept the current beta instability. If you need a more mature, self-hosted agent orchestrator with a broader ecosystem, consider alternatives like n8n or Windmill, which offer visual workflow builders and more established community support, though they lack HomeRail's voice-first focus.
Community notes