Introduction

Trill is a CI and workflow automation system. Define workflows in YAML, run them locally for fast iteration, or submit them to trill.build where runner agents pick up jobs and a web dashboard shows live progress.

trill run workflow.yaml

Why Trill?

CI feedback loops are slow. You push, wait for a runner, read logs in a web UI, fix a typo, push again. Local development and production execution feel like different worlds.

Trill uses the same workflow format everywhere. Run it on your laptop with a terminal UI, or submit it to trill.build and watch it in the web dashboard. The format is familiar if you’ve used GitHub Actions or GitLab CI — jobs, steps, dependencies — but the same YAML works locally and in the hosted service without translation.

What It Does

• Parallel job execution with dependency DAG — jobs run as fast as their dependencies allow
• Approval gates — pause for human (or LLM) decisions with structured input fields, reviewable in the TUI or web dashboard
• Wait and signal — durable waits that pause for a duration, an external signal, or both. State survives disconnects and restarts when running on trill.build
• Expression steps — in-process MiniJinja template evaluation, no subprocess needed
• HTTP steps — built-in HTTP requests with auto-parsed JSON responses
• Structured data flow — JSON outputs flow between steps and jobs, preserving types end-to-end
• Dynamic extension — running steps can add new jobs to the workflow at runtime
• Interactive TUI — job tree with step expansion, live logs, status bar with attention system for approvals and waits
• Web dashboard — real-time run monitoring, DAG visualization, approval forms, re-run and retry
• Debug mode — step through each command, inspect rendered templates and environment
• JSON protocol — every interactive feature has a machine-readable mode for LLM agents and automation

Two Modes

Local mode — Run workflows directly on your machine. The TUI shows live progress and you interact with approval gates in the terminal. No infrastructure needed, no account needed. This is the fastest way to develop and test workflows.

trill run workflow.yaml

Hosted — Submit workflows to trill.build with a personal access token, or run a runner agent on your own hardware that claims jobs and reports results back. A web dashboard shows live progress, approval forms, and full run history.

# Run a local agent that picks up jobs from trill.build
trill agent --server https://app.trill.build --token trl_<runner-token>

The same trill binary works in both modes — as a local runner and as a remote agent.

Design Principles

Familiar format. Workflows are YAML with jobs, steps, and dependencies. No SDK, no framework, no language lock-in. If you’ve written a GitHub Actions or GitLab CI config, you already know the structure.

Local-first development. Local execution is how you develop and iterate on workflows — fast feedback, no infrastructure. Your workflow runs on your machine with the same behavior it has on the hosted service.

Incrementally powerful. Start with jobs and steps. Add data flow when you need it. Add approval gates for deployment safety. Add wait steps for external coordination. Add dynamic extension for discovered work. You never hit a wall where you need a different system.

Next Steps

• Installation — Get the binary
• Quick Start — Run your first workflow locally
• Defining Workflows — Jobs, dependencies, parallel execution