heal.dev

Heal is a runtime bug hunter for software teams. Code review reads the diff of a pull request; Heal runs the actual product inside a sandbox that replicates production, then hunts for reproducible bugs, runtime vulnerabilities and performance issues. It is aimed at engineering teams that already review code and test against staging but still ship defects that only appear when the application is actually running — broken flows between untouched code, configuration, data and third-party services. Heal runs locally or in the cloud, connects to GitHub, and hands back a report where every defect is accompanied by the failing test that proves it. The gap it targets is specific. AI code review sees the diff of one pull request, so a bug that lives between untouched code, configuration, data and a third-party service is outside what it can see; it can flag a pattern that looks wrong, but whether that path is reachable, and what happens when it is, is left to the developer. End-to-end tests run the happy path against staging, where requests that fail, slow down or come back with a field missing are never staged, and where payments, mail and third-party calls are switched off. A static scanner reports a pattern in code that may never be reachable and cannot tell you if it is. Heal addresses exactly that space: untested integrations, edge cases, services disabled in staging, hard-to-mock async services, dead pages and screens nobody owns a test for — everything that requires a runtime. Heal begins by reading the code and mapping the product's architecture, naming features and the screens that belong to each one, with pointers into the codebase such as routes/checkout.tsx or features/billing/plans.tsx. From that map it builds a sandbox that replicates production. Inside the sandbox the web app and the API run for real, Postgres holds test data, Stripe runs as a local emulator, and Slack can be mocked or reached through the live API. Services that cannot run are stubbed. Because the services behind payments, mail and third-party calls are emulated rather than switched off, the flows that depend on them run for real instead of being skipped. Against that sandbox Heal hunts three classes of issue: behaviour, security and performance, each selectable at Quick, Standard or Deep depth (security offers Quick and Standard). For security work it runs established tooling inside the sandbox — schemathesis, ZAP, dalfox, jwt_tool, nuclei, semgrep, trufflehog, sqlmap and more. Instead of stopping at a pattern match, it fires the real exploit at the sandbox, signed in as two people, and reports what came back. It also walks every flow again with the world failing — requests that fail, slow down or return with a missing field — and files the screen that says "nothing here" when the server broke. It crawls every link once across the whole running app, so dead pages, assets that do not load and routes no feature names are surfaced. The defining rule is that Heal only files what it can reproduce. A defect must fail twice, then fail again when Heal re-runs it itself; what it cannot reproduce, it does not file. That turns a finding into evidence. Each report carries a situation, the actual result, the expected result, the screen it failed on, how it happens, where to look in the code, and the failing test that reproduces it. A worked example from the site: a shopper enters SUMMER24, an expired discount code, the cart says "Discount applied" and shows a lower total, and then checkout charges the full price. Heal produces checkout/expired-code-is-refused.spec.ts, red 2 of 2, and once the defect is fixed the same test goes green 2 of 2. Because the output is a real failing test, it plugs into agent-driven remediation. Heal's example shows a terminal session where an agent is told to fix defect #41 and mark it fixed; the agent edits src/cart/apply-code.ts (+3 −1), runs playwright test expired-code and gets 2 passed. Teams point Heal at a repository by connecting GitHub and get a report, running it locally or in the cloud. The suggested cadence is weekly, or before a release, on the whole product — code review stays on every pull request while Heal covers what a diff cannot show. The method is a four-step loop: map the product, build the sandbox, hunt for bugs and vulnerabilities, then prove what it found. Mapping reads the code and derives the architecture. Sandboxing reproduces the environment and mocks what cannot run. Hunting comes from two directions at once — reading the code for suspicions the way a reviewer would, then running each suspicion against the sandbox. Proving is the filter: only what a test reproduces is filed. The same loop makes the comparison concrete. Where AI review sees one pull request's diff, Heal sees the running product: every feature, its data and the services it calls, changed or not. Where a reviewer flags a pattern, Heal proves it with a test. Where a scanner matches code that looks like a vulnerability, Heal fires the exploit and reports what came back. Where review sees a call to payments, mail or a third-party API but never what the service answers, Heal mocks or emulates it in the sandbox and replays it failing, slow, or answering twice. The outcome is a shorter path from finding to fix. Teams get a defect with its steps, the captures and the reproducing test instead of a backlog of AI-generated suspicions, so triage effort goes to real problems. The proof also makes the finding portable: a failing test can be handed to a human engineer or to an agent, and the same test verifies the fix. Coverage extends to places staging never reaches — failing, slow or malformed responses, flows behind disabled services, and links no test owns. Heal has been run on open-source repositories at scale, building a production-like environment for each: twentyhq/twenty returned 83 defects, formancehq/payments 89, NVIDIA-NeMo/nemo-platform 41, windmill-labs/windmill 259, odoo/odoo 165, Infisical/infisical 307, calcom/cal.com 197 and strapi/strapi 127. A published benchmark sets four review bots against Heal on 174 pull requests. Typical use is a whole-product hunt run weekly or before a release, sitting alongside pull-request code review rather than replacing it. A team that ran Heal on Twenty reported bugs their code review missed; another described running it weekly across their entire product and handing the reproductions, recordings and issue lists to their own agents. Concrete scenarios match the gaps it targets: walking checkout flows while the payment service returns an error, slows down or answers twice; exercising screens that depend on mail or a third-party API that staging has switched off; validating a runtime security issue by firing the exploit signed in as two people instead of trusting a static pattern; and crawling the running app to catch dead pages, assets that do not load and screens no feature owns. Open-source maintainers can message @healdevHQ for free credits to run Heal on their project. Heal is built for engineering teams already using code review and end-to-end testing who want the runtime layer covered, and for teams working with coding agents that need verified defects to act on. It connects to GitHub to deliver a report and runs locally or in the cloud, produces Playwright spec files as its proof, and its documented agent workflow uses Claude Code in the terminal. A free trial requires no credit card, demos can be booked, and open-source projects get free credits. Heal is SOC 2 certified, with details published at trust.heal.dev. The proposition is narrow and testable: code review reads the diff, Heal runs the product. By mapping the app, building a production-like sandbox, hunting behaviour, security and performance issues, and refusing to file anything it cannot reproduce, Heal delivers defects that are already proven — each shipped with the failing test that turns green when the bug is fixed.