What kinds of issues can I ask Heal to look for?

Behaviour (Quick, Standard, Deep), Security (Quick, Standard), and Performance (Quick, Standard, Deep) hunts.

It runs locally or in the cloud. You point it at your repo, connect GitHub, and get your report.

Can coding agents fix the defects it finds?

Yes. Defects are structured so agents can act on them — for example, an agent can be instructed to fix a specific Heal defect, run the failing test, and mark it fixed.

Is it free for open source?

Yes. Open-source projects can message @healdevHQ to get free credits. Heal has already run on repos like Twenty, Odoo, Cal.com, Strapi, Infisical, and Windmill.

heal — Find bugs and vulns code review misses

Heal is an automated bug and vulnerability hunter that runs your product rather than just reading its code. It builds a sandbox that replicates your production environment (web app, API, Postgres with test data, Stripe emulation, Slack mocking, etc.), maps your architecture, reads your code for suspicions like a reviewer would, then validates each one against the running sandbox. Only defects a failing test reproduces get filed, and every defect comes with steps, captures, and a failing test that turns green once fixed. It hunts for reproducible bugs, runtime vulnerabilities, and performance issues, and can run locally or in the cloud.

Key Features

Sandbox that replicates production

Heal learns how to run your environment: it maps your product (features, screens, routes), builds a sandbox with your real web app or API, test data in Postgres, and mocks or emulates third-party services like Stripe and Slack so the flows behind them run for real.

Proven, reproducible defects

Each finding comes with the failing test that proves it — the test fails, then fails again when Heal re-runs it itself. What Heal cannot reproduce, it does not file.

Runtime security testing

Instead of matching code that looks like a vulnerability, Heal fires the real exploit at the sandbox, signed in as two people, and reports only what a test reproduces.

Hunts with a battery of tools

Runs tools like schemathesis, ZAP, dalfox, jwt_tool, nuclei, semgrep, trufflehog and sqlmap against the sandbox, covering static-scanner and E2E blind spots.

Edge-case and failure-mode testing

Walks every flow with the world failing — requests that fail, slow down, or return twice — and files screens that say 'nothing here' when the server broke. It also crawls every link over the whole running app to find dead pages and missing routes.

Agent-friendly fix workflow

Defects include steps, captures, and where to look in the code, and can be handed to coding agents (e.g. fixed via Claude Code by pointing it at the defect) and marked fixed.

Runs locally or in the cloud

Point it at your repo, connect GitHub, and get your report. Runs locally or in the cloud, and can be scheduled weekly or before a release.

How It Works

Maps the product

Reads your code and maps your architecture, identifying features, screens, and routes (e.g. 6 features and 29 screens in the demo).

Builds a sandbox

Builds a production-like sandbox: your real web app or API, Postgres with test data, and mocks/emulators for services that can't run (e.g. Stripe emulator, Slack mock or live API).

Hunts for bugs and vulns

Reads your code for suspicions like a reviewer, then hunts for behavioural bugs, security vulnerabilities (Quick/Standard depths), and performance issues (Quick/Standard/Deep).

Proves what it found

Validates every suspicion against the running sandbox; only defects that a failing test reproduces are filed, each with steps, captures, and the failing test.

Pros & Cons

Pros

Files only reproducible defects — every issue ships with a failing test that proves it and turns green when fixed
Tests the running product, so it catches bugs spanning untouched code, config, data, and third-party services that per-PR review cannot see
Mocks/emulates services like Stripe and Slack so real flows run instead of being skipped as in staging
Validates security findings by firing real exploits at the sandbox rather than reporting unreachable patterns
Produces structured defect reports with steps, captures, and code locations that can be handed directly to coding agents

Who It's For

Best for

Engineering teams that rely on AI or human code review but want runtime-verified bugs, vulns, and performance issues across the whole produc
Teams whose staging environments disable or mock payments, mail, and other third-party services, leaving those flows untested
Teams using coding agents (e.g. Claude Code) that can consume reproducible, test-backed defect reports
Open-source maintainers looking for free automated bug hunting on their repos

Not ideal for

Developers looking for lightweight per-pull-request diff review — Heal explicitly complements code review rather than replacing it

Use Cases

Weekly or pre-release bug hunts on an entire product, complementing per-PR code review

Finding runtime vulnerabilities that static scanners flag but can't confirm are reachable

Testing flows behind third-party services (payments, mail) that are disabled or mocked in staging

Discovering edge cases where failing, slow, or duplicated requests break the UI

Finding dead pages, broken assets, and orphaned routes no test covers

Handing verified defects with failing tests to coding agents for automated fixes

FAQ

What does Heal do?

Heal runs your product in a sandbox that replicates production and hunts for reproducible bugs, runtime vulnerabilities, and performance issues. Each finding comes with the failing test that proves it.

How is it different from AI code review?

AI code review only sees the diff of one pull request and flags patterns that look wrong; whether a bug is reachable is left to you. Heal sees the running product — every feature, its data, and the services it calls, changed or not — and proves each finding by reproducing it. What it cannot reproduce, it does not file.

How is it different from E2E tests and static scanners?

E2E tests typically run the happy path against staging with third-party services switched off; Heal walks every flow with the world failing and mocks services so flows behind them run for real. Static scanners report code patterns that may never be reachable; Heal fires the real exploit at the sandbox and reports only what a test reproduces.

What does a defect report include?

heal