Skip to content
ravel

What is Ravel

“Ravel” refers to three distinct things. Keeping them apart makes everything else in these docs easier to follow.

The runtime

Section titled “The runtime”

@runravel/ravel is an open-source npm package: an agentic runtime plus a CLI. It runs one team of agents from a folder — orchestration, budgets, scheduling, and human-in-the-loop approval, all included. You install it, point it at a team folder, and run ravel serve. No account, no network dependency on Ravel the company.

This is the free on-ramp, and it’s real software — not a trimmed-down demo of the platform. It’s Apache-2.0 licensed and built on the Claude Agent SDK.

The platform

Section titled “The platform”

The platform is the hosted, commercial control plane — everything the runtime deliberately leaves out because it’s a multi-user, multi-team, production concern rather than a single-team, local one: identity and SSO, per-team isolated workers, secret binding, spend governance, and an audit trail. Connect a GitHub repo and the platform runs your team as an always-on service.

Team repos

Section titled “Team repos”

A team repo is your content — the actual agents, prompts, tools, and processes that make up a team. It’s just files: agent.md, tools.json, a processes/ directory, optionally a plugin.ts. No build step. The same repo runs locally under the runtime and in production under the platform.

Why the split matters: dev/prod parity

Section titled “Why the split matters: dev/prod parity”

The platform doesn’t run a different, “production” version of your team. It runs the exact same runtime you run locally with ravel serve — inside an isolated worker, with secrets bound and a spend ceiling set. If a process behaves correctly when you run it on your laptop, it behaves the same way in production, because it’s the same code path. The platform adds the multi-tenant scaffolding around that runtime; it doesn’t replace it.

Next

Section titled “Next”