Auto-fix production errors, approval-gated

The objection, first

“Letting an AI write to production is how you get an outage.”

Correct, if the AI decides. The whole design here is that it does not. There are six gates between a model producing a diff and a byte changing on your disk, and you own four of them.

Dry run by default

A new target applies nothing. It collects, analyses and proposes, and waits. You decide when — and whether — that changes.

Explicit approval per patch

Every fix waits for a human. Low-confidence proposals need a second, separate confirmation before they can be applied at all.

Path rules you set

Monitored paths, excluded paths and patch-exclusion paths are per target. Whole trees can be declared untouchable, and stay that way.

Local snapshot before any write

Every path in the patch is snapshotted on your own host first, with sha256-verified backup manifests. The restore copy never leaves your machine.

Syntax check, then verify

The file is parsed before and after the write. Then a health request runs against your target, plus tests or deeper checks on supported plans.

Rollback, automatic or manual

A failed check triggers restore from the local snapshot. You can also roll back any applied patch yourself, whenever you like. Docs →

Auto Apply does exist. It is opt-in, scoped to a single target, revocable in one click, and it still runs the backup, the syntax check, the health check and the rollback. It is a decision you make per target after you have watched it work — not a default you have to remember to turn off.

Where it sits

It does not replace your error tracker.

Sentry, Rollbar, Bugsnag and Datadog do tracing, performance, release health, session replay and a breadth of SDKs Patcherly does not attempt. If you are evaluating this as a swap, you will be disappointed, and we would rather say that here than in month three.

Patcherly picks up where they hand off. The error is known. The stack trace is beautiful. Somebody still has to open the file, work out what changed, write the patch, get it reviewed and ship it. That gap is the product.

Read the product scope doc before you buy. It is written to set expectations, not to sell.

Your tracker Detects, groups, alerts, traces. Tells you it is happening 340 times an hour.

The gap Someone reads it, opens the file, works out the change, writes it, reviews it, ships it.

Patcherly Drafts the patch with a rationale and a confidence score, waits for approval, applies locally, verifies, rolls back on failure.

Data flow

Exactly what leaves your server.

Not “we take security seriously”. The actual list, so you can decide whether it is acceptable before you install anything.

Outbound, per error

The error message and stack trace
The file path and line number
A scrubbed snippet of the file around the error
Runtime and framework versions
Optionally, environment context you opt into per target

API keys, passwords and tokens are pattern-redacted before anything reaches a model or a log line.

Never leaves, at all

Your repository — not cloned, mirrored or stored
Your database and its contents
Your pre-apply backups — they stay on your host
SSH keys, deploy keys, repo credentials — never requested
Your code as training data for any foundation model

Inbound is a signed patch payload. Unsigned or replayed messages are refused, and signing cannot be disabled.

Error text is treated as hostile

Log lines are attacker-influenceable input on their way to a model. Suspicious payloads are quarantined and flagged instead of analysed, with a per-target protection mode. How →

OAuth device grant, scoped

Connectors pair through a short-lived device-code grant with fixed scopes that never widen for the life of the connection. Revoke from the dashboard and the connector is dead immediately.

EU-hosted, DPA published

Frankfurt. The Art. 28 DPA and the subprocessor list are on the site, not behind a sales call. Full detail on the security page.

Measured, not asserted

What changed when the AI got real context.

Patcherly started as a research question, tested across a million simulated sessions before it was a product. The numbers and the methodology are both published.

~18%

Errors resolved without a human.

Against roughly 5% without enriched context. Same error pool, same review process.

57% faster

Drop in resolution time.

Base scenario. Includes human approval time, not just machine time.

~94% → ~82%

Errors still needing a person.

Roughly one in eight handed back to automation. Not a revolution — a real dent.

Full methodology, charts and tables

Before you evaluate

Where it falls down.

You are going to find these in week two anyway. Better you find them now and decide with the real shape of the thing in front of you.

It is not uptime monitoring

It reacts to errors your application emits. It does not poll your endpoints every minute to tell you the box is alive. Keep your monitoring stack.

Verification is best-effort

Checks confirm the app loads and tests pass. They cannot prove every user journey works. Bugs behind rare paths still need QA.

Code files, not config or data

It patches source. It does not migrate a schema, edit a database row, or rewrite your infrastructure config.

Intermittent bugs stay intermittent

Environment-specific and race-condition errors may not reproduce on a post-apply check, so verification tells you less than you would like.

WordPress cannot run commands

No post-fix test runs or restarts on the WordPress plugin, by directory rule and by design. Use the standalone connectors where you need that. Docs →

Four stacks today

PHP, Python, Node.js and WordPress. Go, Ruby, Rust, Java and .NET are roadmap, not shipping. Tell us what you run.

Getting in

One command. No SDK in your codebase.

Nothing to import, no middleware to wire, no build step. The connector reads the logs you already write. Your PR flow and your CI do not move an inch.

Connector source is open — read it before you run it, which is rather the point.

Linux / macOS

curl -sSL https://api.patcherly.com/install.sh | sudo bash

The Connect modal in your dashboard hands you the same command with the pairing code already in it. All connectors · Install docs

The sceptical questions.

The ones we would ask too. Not answered here? Ask directly — the founder is also the person on call for Patcherly itself.

Is this a replacement for Sentry, Rollbar or Datadog?

No, and we would rather say so than lose the argument later. Those products do tracing, performance, release tracking, session replay and breadth of SDKs that Patcherly does not attempt. Patcherly starts where they finish: you already know the error exists, and something still has to write the patch. Plenty of teams run both.

Does my source code get uploaded?

No. The connector sends the error message, the file path and line, a scrubbed snippet around the error, and environment metadata. Secrets are pattern-redacted before anything leaves the host. Your repository is never mirrored, cloned or stored, and your code is never used to train third-party foundation models.

How is this different from an agent that applies fixes autonomously?

The apply step is gated by default. New targets start in dry run, every patch waits for an explicit approval, and low-confidence proposals need a second confirmation. Auto Apply exists, but it is opt-in, scoped per target, and revocable in one click. The failure mode people rightly worry about with autonomous remediation is the one this architecture removes.

What happens on a bad patch?

The connector snapshots every path in the patch before writing, verifies syntax before and after, then runs a post-apply health request against your target URL, and on supported plans tests or deeper checks. If verification fails, rollback restores from the local snapshot — automatically, or manually whenever you want.

Can it restart my app or run my test suite after a fix?

On the standalone Python, Node.js and PHP connectors, yes — they run as separate processes and can be granted permission to execute commands. The WordPress plugin cannot, ever: it only changes files. That is a WordPress plugin-directory rule and a deliberate safety boundary, not an oversight.

How do you handle prompt injection from error payloads?

Error text is untrusted input that reaches a model, so it is treated as hostile. Suspicious payloads are quarantined and flagged rather than analysed, and a per-target protection mode controls how aggressively that gate closes. The mechanism is documented rather than described in marketing terms.

Where does the data live?

The EU, in Frankfurt. Your code and your pre-apply backups stay on your own machine and never reach us. A Data Processing Agreement is published rather than gated behind a sales call, and the subprocessor list is public.

What are the real limits?

It patches code files, not database rows or configuration. Post-patch verification is best-effort inside the workflow — it can confirm the app loads and tests pass, not that every user journey works. Intermittent and environment-specific bugs may not reproduce on a check. And it is not uptime monitoring; it reacts to errors your application emits.

The alert is not the fix.