What does peachfuzz give me that go test -fuzz does not?
Continuity, custody, and an artifact. Go's fuzzer finds the bugs. We do not improve the engine and will not pretend to. What Go does not do is keep forty targets rotating fairly for eight months, survive a broken package, keep the learning alive across a hardware refresh, measure the CPU actually spent, and sign a record an outsider can check. Those are operations problems, not fuzzing problems, which is why they never get solved. They are nobody's interesting work, and the shell script that half-solves them rots the day its author changes teams.
Does it find bugs on its own, or is it just bookkeeping?
It finds bugs the way a fuzzer finds bugs, which is to say by running for a long time. The engine is Go's, unmodified. Our contribution is that the engine gets months of CPU instead of the twenty minutes somebody watched it for, and that is not a small contribution: coverage-guided fuzzing is a search where nearly all the value sits in the tail. Calling it bookkeeping undersells what happens when a target that has run four hours in its life gets four hundred. But we will not claim we made the fuzzer smarter, because we did not.
Does peachfuzz write our fuzz targets, or tell us whether they are any good?
Neither, and the second half matters more than it sounds. We execute the harnesses you wrote, for as long as you let us, and record what that cost. A harness reaches only the code it actually drives: one that parses an input and drops it exercises the parser and nothing behind it, and it will burn a core-year without ever touching the thing you were worried about. A target written to look busy produces exactly the same clean report as a target written to break something, and the clean one is the more dangerous of the two, because a suite that cannot fail is worse than no suite at all. No tests is an honest gap somebody will eventually close. A green wall nobody can fail is a claim your team will plan around, and months of signed CPU behind it make that claim heavier, not truer. We report the hours and refuse to grade the search. Point the harness at what would actually hurt you.
Can it fuzz our C, Rust, Java, or Python code?
No, and that is a hard no rather than a roadmap item. Go's fuzzer is steered by coverage the Go compiler injects into Go code. Shell out to a non-Go binary and it runs, but the mutator gets no feedback from that subprocess, so it degrades to blind guessing, and spawning a process per input costs you two to three orders of magnitude of throughput. You would get a big, honest-looking number measuring almost nothing, which is worse than no number. Use the native fuzzer instead: libFuzzer or AFL++ for C and C++, cargo-fuzz for Rust, Jazzer for the JVM, Atheris for Python. All free, all better at it than a Go wrapper would be.
Where does it run, and does our code leave the building?
It runs on your hardware and your code never leaves it. Peachfuzz executes trusted project code directly and is explicitly not a sandbox, which means the only correct place for it is inside your own trust boundary, running your own repositories. Local sends only its lease check-in and counters. Attested and Archive can opt into Cloud Evidence: once a day the daemon uploads new coverage-increasing corpus entries, unique retained findings, and signed proof to encrypted tenant-private storage. It never uploads source, the repository tree, filesystem paths, secrets, or raw process output.
What is a core-year, and why should anyone believe the number?
One core busy for 365.25 days. It measures work, not elapsed time, so an eight-core box running six weeks records about a core-year. Believe it because of what it refuses to count: never the clock on the wall, so idle hours are worth nothing. It rounds down. It adds up in strict order from records already on disk, so a crash can neither inflate it nor lose a run. Each machine signs its own, so more machines means more independent evidence, not a shared counter someone could nudge. The number is smaller than a flattering one would be, and there is no setting to make it bigger.
What happens when it finds something?
It keeps the input, gives it an identity, and shows it in the report. That is all. No issue, no pull request, no edit to your code, no alert, and no claim that it is a vulnerability. Run reproduce and it replays exactly against the revision that produced it. The line is deliberate: a tool that grades its own findings is optimising for a dashboard, and the first false positive that reaches your security team costs more than the tool saved.
One of our targets has found nothing in months. Is that good or bad?
We do not know, and we report the fact rather than a verdict: no new entries in the last N runs. A target goes quiet because the code is solid, because the harness never reaches anything interesting, or because the inputs are wrong. Those look identical from outside. We could call it healthy and the page would read better. It would also be exactly the unverified claim this product exists to argue against. The diagnosis stays yours.
Do we have to involve procurement, legal, or a security review to buy this?
Not to buy it. Every tier is a monthly card charge: no purchase order, no annual commitment, no order form, no sales call. Start it and cancel it yourself. The top tier is $350 a month, set deliberately under the threshold where most companies turn a tool into a project with a questionnaire attached. Whether your own policy demands a review is your call, and two things help that conversation: your code never leaves your hardware, and Off Grid holds no SOC 2 or ISO 27001 today. If your process requires certified vendors, that is a real blocker. Better you hit it here than three weeks in.
Do you offer a trial or refunds?
A trial, yes. Refunds, no. Every tier comes with thirty days free, everything switched on, unlimited machines. One per customer. We take a card up front so the subscription converts without interrupting a running search, but nothing is charged during those thirty days. Cancel before day thirty and you are not billed at all. It is the most useful trial we offer on anything, because thirty days of real fuzzing on your own repo produces a real number instead of a demo. After it converts, all sales are final: no refunds, no credits, no prorating. Cancelling stops the next charge, it does not return the current one. Better you read that here than discover it after.
What is the difference between Local and Attested?
Local is the complete standalone fuzzer: every machine keeps its corpus, findings, and signed evidence locally. Attested unlocks opt-in Cloud Evidence. Enable it in the same validated JSON configuration the daemon already reads, and once a day your machines exchange new coverage-increasing corpus entries through encrypted tenant-private storage, back up unique findings separately, and send signed proof we retain for one year. The subscription authorizes that mode; a config edit cannot manufacture entitlement. Archive uses the identical mechanism with five-year retention.
Why $20 a month, and why not per repository?
Because the moment price scales with repositories, someone starts asking which repos are worth fuzzing, exactly the wrong conversation for a record that gets stronger the more it covers. Same reason we do not charge per machine or per core: we want you throwing spare hardware at this. Local is priced below the meeting where you would discuss building it yourself. Neither tier is meant to need a procurement cycle.
What happens if we stop paying?
The daemon runs on a lease. Each machine is registered to your account on first run and gets its own lease naming it, then checks in on a schedule; that check-in renews the lease and carries the effort counters your published number is built from. When opted-in Cloud Evidence is authorized, its daily exchange also carries new useful corpus entries, unique findings, and signed proof into the tenant's encrypted vault. When a payment fails nothing changes that day and our processor retries. About a week later, once those retries are done, the lease stops renewing and the daemon stops. Peachfuzz has no read-only mode to fall back to, because it is a continuous search rather than a reader of records already made, and we would rather say that here than let you assume it degrades gently like the other two. Where your tier includes custody you keep the notice period and the export window in Section 21B of the Terms before anything we hold is deleted, and paying the balance at any point before then restores everything on its own. Everything already written to your disk stays readable and verifiable without us, permanently. We say the lease expires rather than claiming the tool runs forever, because a subscription that cannot lapse is not a subscription.
What if Off Grid shuts down?
The local store remains authoritative by design: the fuzzing, corpus, run records, reproduction path, findings, and effort accounting live on your disk and remain verifiable there. Every tier sends lease check-ins; opted-in Attested and Archive fleets also use our encrypted cloud copy for corpus exchange, finding recovery, and outside proof. The wind-down commitment releases the lease rather than stranding your daemon and gives you the stated export window for everything we hold. What ends with us is fleet exchange, cloud recovery, and the published snapshot; the local corpus, findings, records, and verifier remain yours. Put the same question to every custody vendor you evaluate, and be suspicious of any whose product stops working when they do.
Will it interfere with the repository we are actively working in?
No, and this is an invariant rather than a best effort. Every slice runs in a detached Git worktree leased exclusively to that run, at a pinned revision. Your active checkout is never written to, so nothing the daemon does can appear in your working tree, your index, or your branch. It can fuzz the same repository you are editing, at a revision you pushed last week, while you rebase.
How much CPU will it take from a machine we are using?
As much as you tell it to and no more. Shared mode takes a configured fraction of the cores, so a workstation stays usable while the daemon works in the background; dedicated mode takes the machine. Both are a single config value. Child output is bounded, deadlines are enforced, and the process tree is reaped on shutdown, so it cannot leave orphans consuming a box you thought was idle.
Can we run it on several machines?
Yes, and that is the intended shape. Give each machine the same validated project configuration and its own automatic installation identity. Local machines search independently. With Cloud Evidence enabled on Attested or Archive, each machine exchanges new coverage-increasing corpus entries once a day and pulls entries it has not seen, so one machine's useful discovery becomes another machine's starting point without a customer-run coordinator or cluster. Findings are backed up separately and never become active corpus seeds. Adding capacity is starting another registered daemon, and the price does not move with machine count.
Could you, or anyone with the binary, forge our effort number?
The signing key is generated on your machine on first run and never transmitted, so evidence attributed to your installation can only be produced by your installation. Uploads are create-only and content-addressed: identical retries converge and replacement is forbidden, so a record cannot be quietly revised after the fact. A second digest for the same machine and run identity is a loud conflict rather than an overwrite. We can decline to hold your evidence. We cannot rewrite it, and neither can anyone who compromises our side without your key.
Does this help with SOC 2, ISO 27001, or a security questionnaire?
As engineering evidence, yes, and we will be precise about the limits. No tool grants a certification, and peachfuzz is not a control by itself. What auditors and reviewers repeatedly ask is whether a stated practice actually operated over time, and that is exactly what this produces: named targets, at named revisions, for a measured duration, with an artifact that does not depend on your word. It converts the weakest kind of questionnaire answer, an unqualified yes, into something a reviewer can sample. Whether your auditor accepts it for a specific control is between you and your auditor.
How does it fit with bug and Witness?
They answer three different questions with the same kind of artifact. bug proves a specific defect was really closed: described, red-tested, green-fixed, explained, and committed. Witness proves a quality run really happened and is held by a custodian who cannot quietly revise it. Peachfuzz proves you kept searching for the defects nobody ever reported. Each stands alone and none requires the others. Together they cover closure, verification, and search, which is most of what anyone reviewing your engineering practice knows how to ask about.
Who else is using this?
Nobody outside Off Grid yet, and we will not dress that up. It has run against our own Go for a long time and produces the figures on our other product pages, but that is our homework. No reference calls, no logos. What we offer instead is what a reference call stands in for: install it during the trial, watch the number grow from CPU you can account for yourself, and try to make it lie. If early is not a risk you take, wait. That is a reasonable position.
Why is it Go only when your other products support more?
Because coverage-guided fuzzing is deeply language-specific, and pretending otherwise makes a worse product, not a broader one. Almost everything here would generalise: the scheduler, the worktree leasing, the custody, the effort accounting, the ledger, the replay path. Only discovery and execution are bound to Go. So the route to other languages runs each language's own native fuzzer under the same evidence layer, not a foreign engine bolted onto Go's. That is real work and we have not done it.
Why do purchases go through Stripe?
Because payment collection is not the place to improvise. Checkout, cards, receipts, tax handling, and payment security belong on Stripe's platform. Our server still owns product identity, plan rules, and prices, so the browser cannot invent a cheaper plan. Stripe collects payment; Off Grid grants the entitlement that matches the server-side product.
No question matches that search. Book a call and ask it directly.