How do I trigger a runner?

Runners can be triggered from GitHub, cron schedules, the REST API, Slack, or webhook. Mention @drisp {runner-slug} in any supported surface, or POST to /api/v1/runners/{slug}/dispatch with a Drisp API key.

Where do runners execute?

On Drisp Cloud, or on your own infrastructure. The Drisp CLI is open-source and MIT-licensed — install it on your laptop, run it in CI, or self-host it. Drisp Cloud runs the same CLI as managed runners with triggers, queues, retries, and storage handled for you.

How does the workflow marketplace work?

Workflows are installable agent programs. Install one with a single command on the CLI, or attach it to a runner on Drisp Cloud — the same install runs underneath. Versions are pinned at create time, so upgrades are explicit.

For engineering teams

Coding agents that ship.

The runtime for coding agents. Define an agent's job once — steps, constraints, exit criteria — and run it deterministically on Claude Code or Codex. Locally, in CI, or on a managed runner.

Start free View on GitHub

Open-source CLI · MIT-licensed · Free Cloud tier

01 — the problem

The problem

The agent is fine.
The workflow around it is broken.

Same prompt. Same model. Different output every time.
Agents drift over long runs. No checkpoints, no way to recover.
What works for one dev doesn’t transfer to the team.
You see the final output. Not the 40 tool calls that produced it.
Agent tooling assumes a human at the keyboard. CI and automation are afterthoughts.

The fix

One workflow layer.
Local or in the cloud. Same result.

Drisp sits between you and the agent. Define steps, constraints, and exit criteria once. Run them on Claude Code, Codex, or any future agent runtime — locally, on your own infra, or on Drisp Cloud.

Structure over prompting

Define jobs declaratively — steps, constraints, exit criteria — not conversationally.

Checkpoints, not hope

Every step is verifiable, every run is resumable. No silent drift.

Team-portable

What one developer builds transfers to the whole team. Same workflow, same result.

Pipeline-first

Built for CI from day one. Not interactive-first, retrofitted later.

02 — one runtime, two operators

One runtime.
Two operators.

The Drisp CLI is the runtime. It sits on top of Claude Code or Codex and coordinates every step of every workflow. Run it yourself, or attach it to a managed runner on Drisp Cloud.

Open source

Drisp CLI
Run it yourself.

MIT-licensed CLI. Install it on your laptop, run it in CI, or self-host it on your own infrastructure. Bring your own agent keys. Own your data.

$ npm install -g @drisp/cli

$ drisp workflow install playwright-automation

$ drisp --workflow=playwright-automation

Free, forever
Local-first dev loop
Self-host on any container runtime
Workflows install from the marketplace or from a local path

Install the CLI →Read the self-host guide →

Recommended for teams

Drisp Cloud
Let us run it for you.

Spin up a managed runner from the dashboard, attach the workflows it should run, and trigger it from anywhere. Same CLI underneath — Drisp Cloud handles the infra, schedules, queues, retries, checkpoints, and storage.

drisp.cloud → New runner → Attach workflow → Save

Free tier included
Pay per run after that
Triggers from GitHub, cron, REST, Slack, or webhook
SSO, audit log, role-based access for teams

Start free →See pricing →

Workflows are the same in both modes. Whether you type drisp workflow install on your laptop or attach a workflow to a Cloud runner from the dashboard, the same install runs underneath.

03 — workflow marketplace

Install workflows
like packages.

Browse community-maintained workflows or publish your own. Each one is scoped, tested, and version-pinned. Workflows install with a single command on the CLI — and the same install runs underneath when you attach a workflow to a Cloud runner.