Getting started with Rebar

Rebar detects, diagnoses, and repairs production-software breakage. It watches your connected systems against a per-system intent baseline, diagnoses what diverged, and ships reversible fixes as pull requests, on its own or under your approval. You decide which, per system.

1. Connect a system

From the console, open Connections and connect a hosting provider (Vercel) so Rebar can observe deploys and runtime signals. Connect GitHub so Rebar can open fix PRs against the backing repository. Credentials are encrypted at rest and scoped to your organization.

2. Let it learn

Rebar observes each system and matures an intent baseline over time, so it can tell genuinely new breakage from known, expected behavior, so there are no false alarms on day one.

3. Choose how much Rebar handles

Each system has one autonomy setting, and you control it:

• Review: every fix Rebar proposes waits in your inbox. You approve it (Rebar opens the pull request) or send it back.
• Autonomous: Rebar ships fixes on its own. It opens the pull request, waits for your project’s CI, and merges. It still holds anything it judges risky for your review.

New systems start in Autonomous. That’s the point of Rebar. Switch a system to Review whenever you want a human in the loop, and the fleet-wide kill switch halts every autonomous change at once. Either way, Rebar verifies each fix in a sandbox before it ships and every change is reversible.

4. Choose your model

In Settings, pick the provider and model Rebar uses to diagnose breakage (Anthropic or OpenAI). The model only proposes and judges; whether a fix ships stays with Rebar’s core and your autonomy setting.

Multi-tenant by design

Each organization’s systems, connections, and model settings are fully isolated. Sign-in and organizations are handled by Clerk.