RigHaven – Self-hosted execution harness for AI agents

Developer ggmm82 released RigHaven, an open-source, self-hosted execution harness and on-demand toolbox designed to coordinate, sandbox, and supervise multi-role AI agent teams. According to github.com's report, the system allows operators to specify an objective, after which an automated coordinator provisions specialized roles, selects necessary tools from a catalog of 99 managed command-line utilities, executes assignments in isolated containers, and enforces policy checks prior to final artifact delivery.

This report examines RigHaven's containerized role model, human-in-the-loop authorization gates, supported target integrations, and installation footprints. The software targets system administrators, data engineers, and security teams who deploy autonomous agent workflows across local workstations, dedicated servers, or enterprise networks without granting models unconstrained local machine access.

RigHaven – Self-hosted execution harness: what actually changed

RigHaven replaces unconstrained shell access and manual script stitching with a deterministic container architecture. Instead of allowing language models direct access to a developer workstation or a shared operating system, RigHaven directs every user prompt to an automated coordinator that generates an execution plan paired with a policy plan. The coordinator selects from 99 managed CLI tools spanning document processing, motion graphics, audio production, computer-aided design, data pipelines, and network diagnostics.

Rather than running commands in a shared shell, RigHaven instantiates each assigned role in its own dedicated container. These runtime containers have all Linux capabilities dropped and enforce strict CPU and memory resource quotas. Role environments mount the main project directory in read-only mode and are restricted to writing outputs exclusively to their own isolated staging directories, preventing agents from altering core project files without operator review.

RigHaven – Self-hosted execution harness: how it works

A task begins when an operator submits a brief through the web workspace. If multiple tooling paths exist, the coordinator generates tool alternatives detailing specific technical trade-offs and recommendations, pausing execution until the user selects an approach. The coordinator then constructs the team, builds reusable software images on demand, and advances the project through defined execution phases. Each phase pauses to present intermediate outputs, allowing users to inspect files, request targeted revisions, or approve progression.

Security boundaries remain strictly enforced at the container and network layers. With the configuration setting RIGHAVEN_WORKER_EGRESS set to allowlist, role containers can communicate only with their configured model provider and explicitly declared domains, while blocked connection attempts are logged and surfaced to the operator. Finished deliverables undergo automated Policy Book validation checks before being presented alongside full editable source files.

RigHaven – Self-hosted execution harness: why it matters

Most autonomous agent frameworks rely entirely on system prompts to keep language models from executing destructive shell commands or exfiltrating data. RigHaven enforces system boundaries at the container runtime level rather than trusting model goodwill. State changes to external infrastructure—including database writes, physical device interactions, and active network vulnerability scans—cannot proceed without explicit human authorization. Each approved operation is granted permission to run exactly once.

The platform bridges centralized server deployments and physical workstations without requiring public inbound ports. Through three auxiliary software components—RigHaven Agent for Windows and Linux, an Android APK package, and on-premise execution nodes—the server communicates with local COM ports, Bluetooth Low Energy devices, Wi-Fi networks, and internal office subnets. These client agents establish outbound connections back to the primary server, eliminating the need to expose local router ports.

RigHaven – Self-hosted execution harness: who is affected

Software engineers, data practitioners, and operational technology teams can run complex automation tasks without provisioning separate staging environments. Database administrators gain structured integrations with PostgreSQL, MySQL, Oracle, and SQL Server or Azure SQL and Microsoft Fabric, including sign-in flows using personal Microsoft accounts and multi-factor authentication. Hardware teams gain safe access to IoT protocols, including MQTT, Modbus, Bluetooth LE, Matter, Android TV, OBD-II, and raw USB or serial boards.

Users can inspect and modify workspace files directly using integrated tools such as JupyterLab, embedded text editors, or an in-browser terminal attached to the active environment. Teams can standardize recurring multi-step workflows using Recipes, export prepared container environments, or distribute packaged software configurations across instances via the built-in Gallery catalog.

RigHaven – Self-hosted execution harness: what to watch

RigHaven supports multiple client deployments, including portable packages for Windows 10 and 11 running WSL 2 without Docker Desktop, standalone Linux packages requiring Docker Engine, VPS deployments using Docker Compose and Traefik, and standard source builds. Initial startup requires downloading approximately 1 GB of verified base images, and browser access defaults to port 2026 behind an authentication proxy enforcing a 16-character minimum master password.

Administrators must connect external model providers through the web settings panel. RigHaven currently supports OpenAI Codex, Claude Code, Antigravity, and OpenAI-compatible API endpoints such as DeepSeek, Kimi, and OpenRouter. Tracking how the coordinator balances multi-model routing across local and commercial endpoints will determine how reliably organizations adopt the harness for automated enterprise workflows.