What is Runyard

𓂽 Runyard is a self-hosted control plane for durable agent work. Agents and humans trigger workflows over the web app, CLI, HTTP API, MCP, ACP, schedules, hooks, or workflow endpoints; runners execute those workflows with the Smithers engine; and the Hub stores the durable record of everything that happened: stable run IDs, immutable attempts, logs, events, artifacts, approvals, diagnostics, usage, and knowledge. A run started from a chat agent, a cron schedule, or a terminal leaves the same auditable trail in the same place.

Runyard is designed as one private deployment per company. Your Hub holds your workflow catalog, Work/Factory board, secrets, runners, schedules, repositories, agents, skills, knowledge, and history; nothing about your deployment is published to a shared Runyard service. The Hub makes outbound calls only for integrations you configure, plus an optional passive read of the public GitHub Releases API for update checks. Operators, teammates, and their agents all authenticate to the same Hub with scoped access tokens.

Runyard is API-first by construction. Every HTTP route the Hub serves is declared in a single API surface registry; the OpenAPI document is generated from it and the MCP tool list is parity-tested against it. The web app is an ordinary API client with no privileged endpoints: anything it can show or do is equally available over the API and MCP, so a third-party client built on those surfaces loses nothing.

What operators get

• Stable run identity with immutable attempts for retry, recovery, rerun, and crash-safe continuation.
• Human decision gates through the web app, API/MCP, and Telegram; waiting suspends work instead of timing it out.
• A persistent contextual Copilot shelf that can inspect the current surface and propose typed, confirmation-gated actions.
• Work/Factory boards that connect signal, approved direction, implementation runs, evidence, and release decisions.
• Runner fleet capacity, queue visibility, isolated worktrees, sandbox controls, logs, artifacts, diagnostics, and usage.
• Workflows driven by web, CLI, HTTP, MCP, ACP, schedules, hooks, workflow endpoints, and response endpoints.
• CI/repository automation, agents, skills, knowledge, encrypted secrets, scoped tokens, audit logs, and self-update checks.

Next steps

• Quickstart - install the Hub, start a runner, and run your first workflow.
• Concepts - understand workflows, runs, runners, approvals, Work/Factory, and the Hub's durable record.
• Factory operating model - see how ideas become tickets, decisions, runs, releases, and accepted work.
• HTTP API - drive Runyard from any language with bearer-token auth and openapi.json.
• MCP - connect AI agents to your Hub with the runyard-mcp server.