For developers and engineering teams

The alert is not the fix.

Your error tracker has been telling you about the same unhandled null for three weeks. It is correct, it is well-formatted, and it has never once written a patch. Patcherly drafts the change, you approve it, and it applies on your own infrastructure, or arrives as a pull request for your normal review.

How it avoids breaking prod What leaves your server
patcherly · live incident
Detect
Analyse
Patch
Test
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.

The Patcherly patch review dialog: the AI explanation of a division-by-zero bug, the proposed two-file diff, and the Apply patch button.
A diff and a rationale before anything is written. Nothing changes on disk until you click Apply patch.

Approval by default

Every fix waits for your say-so. Dry-run starts off on new sites - turn it on only for preview-only. Auto Apply on Pro is opt-in per site - never a surprise default.

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 site. 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 site, 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 on Pro. It is opt-in, scoped to a single site, 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 site after you have watched it work - not a default you have to remember to turn off.

Your review process, kept

Merge it yourself, or let it patch live.

If your team only trusts what went through review and CI, keep it that way. Delivery mode is set per site: production can wait for your merge, or get the fix now with the PR following behind.

Every plan

Live Patch

The connector applies the approved fix on your server, after a local backup, then checks the site still responds. If it does not, the backup goes straight back. The fastest way to stop the bleeding.

Every plan

PR Only

Your server is never written to. The approved fix arrives as a pull request on your GitHub repo, on its own patcherly/ branch. Review it, let CI run, merge when it suits you. The error closes when the PR merges.

Every plan

Live Patch + PR

Fix production now and keep the repo in step. The patch applies live and the same change opens as a pull request, so your next deploy does not quietly undo it.

How Repo PRs work →

After a live patch, run your own steps

Python, Node.js and PHP apps often need more than a changed file: a process reload, a cache clear, a quick test run. Write those steps once in a short YAML manifest, and the connector runs them on your server after every successful patch.

  • Reload with systemd, PM2, Supervisor or Gunicorn
  • Clear framework caches, reset OPcache, rebuild autoload files
  • Run your smoke tests right after the patch lands
  • A failing step is reported back and locks automation for that site until you review it

App restart docs →

app-restart.yaml
# Sites → your site → App restart → Configure
version: 1
when: on_fix_success
working_directory: /srv/shop-api
steps:
  - name: reload_api
    run: pm2 reload shop-api
    timeout_seconds: 60
  - name: smoke_tests
    run: npm test -- tests/smoke
    timeout_seconds: 120
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 site

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-site 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.

Prefer a registry install? Use WordPress.org, npm, PyPI, or Packagist for your stack.

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. Every patch waits for an explicit approval, and low-confidence proposals need a second confirmation. Dry-run starts off on new sites (Approve can apply for real); turn it on per site only when you want preview-only. Auto Apply exists on Pro, but it is opt-in, scoped per site, 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 site 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?

Yes, on Python, Node.js and PHP sites (Pro). You list the steps in a short YAML manifest, such as a process reload, a cache clear or a smoke-test run, and the connector runs them after each successful patch. The WordPress plugin deliberately does not run server commands. Manual restart is always available on your host.

How do you handle prompt injection from error payloads?

Error text is untrusted input, so it is treated as hostile. Suspicious payloads are quarantined and flagged rather than analysed, and our protection mode controls how aggressively that gate closes.

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 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.

Point it at your ugliest error log.

Add one site and watch what it proposes. Turn Dry-run on if you want a preview-only week first: it cannot write anything until Dry-run is off and you approve (or Auto Apply is on on Pro), so the worst case is that you learn what your logs have been hiding.

Start your free 30-day Pro trial Read the security page first

Full Pro plan for 30 days. No credit card. Free Personal plan after that, for as long as you like.

Not ready to connect anything? Start with getting the real error out of a 500, per stack and by hand.

Checking API...
Checking AI Gateway...
Check status
⚠️ Setup Required