Off Grid Software
Buy now

peachfuzz

Attackers need a goal. You need a shutout.

24/7/365 continuous fuzzing. Defence in layers, the whole fleet on one target.

  • Every machine you light up makes it stronger
  • What one learns, the next one starts from
  • Go only. One JSON file, then leave it alone
  • Polite in the background, or flat out
  • Your code never leaves your hardware
  • From $20 a month, every machine included

Idle hands

Your machines do nothing most of the day.

Every laptop, build box, and spare server you own sits idle most of its life. You already bought the hardware. You already pay for the power. Put those hours to work and they buy you the one thing a real security search needs, which is time.

It does not try to prove your code is safe. It spends every idle hour trying to prove it is not.

01

It stops the week it starts

Someone runs it on a Friday. Watches for twenty minutes. Sees nothing. Closes the terminal. The target was fine. It just never got the hours.

  • When did that target last run?
  • For how long, in total?
  • Who would notice if it never ran again?
02

The learning dies with the laptop

Every hour of searching leaves something behind. It sits in one engineer's cache folder. Never committed. Never backed up. Gone at the next hardware refresh. The next run starts from zero.

  • Where is the corpus right now?
  • Would a new hire inherit it or restart?
  • What did the last two years of searching leave behind?
03

The claim outruns the proof

The questionnaire asks if you fuzz. You write yes. It is true, because someone did. But there is nothing behind the word. No hours. No targets. No artifact. One more claim in a document full of claims.

  • What would you attach to that answer?
  • Could a reviewer check it without asking you?
  • Would the number survive someone hostile reading it?
What most teams can say
  • We have fuzz targets in the repo
  • We ran them at some point
  • CI runs them for sixty seconds
  • Someone has the corpus, probably
  • No, we cannot show you the hours
What the record shows instead
  • 38 targets under continuous search
  • 3.4 core-years of measured CPU
  • Every slice bound to an exact revision
  • Corpus durable on the machine that made it
  • Two retained candidates, both reproducible

What waiting costs

Someone finds it first.

Nobody asks what you did to look until the bug is public. By then the honest answer and the provable answer are two different answers. Only one of them helps.

  1. 01

    A parser bug ships

    Bad input reaches a decoder nobody thought could be reached. This is the exact kind of bug a fuzzer finds in hours. It is also the kind that becomes a CVE instead of a ticket.

  2. 02

    The question arrives

    It comes from a customer's security team. Or a regulator. Or an acquirer. Or a lawyer. Different words, same question. What did you do to look for this before you shipped it?

  3. 03

    You go looking

    Someone searches the repo and finds four fuzz targets. Nobody can say when any of them last ran, or for how long. Chat history gets read. CI logs get scrolled. The answer turns into a paragraph about what you meant to do.

  4. 04

    Intent reads as nothing

    A reviewer cannot tell care that left no record from care that never happened. From the outside they look the same. So they get treated the same.

Disclosure timeline

the record either exists already or it never will

  • Vendor security questionnaires
  • SOC 2 and ISO 27001 sampling
  • Acquisition technical diligence
  • Post-incident review and disclosure
  • Procurement and enterprise onboarding

Evidence is cheap before it matters and impossible after.

While nothing is wrong, the record costs $20 a month and some spare cores. After something goes wrong, no amount of money can buy it. What it records is time, and time only runs forward.

Evidence model

Search on your machines. Share the useful frontier.

Your code stays on your hardware, inside your trust boundary. Cloud Evidence is off until you opt in; then only signed proof, coverage-increasing corpus entries, and unique retained findings enter your encrypted tenant-private vault.

  1. 01

    Find the targets, at one exact revision

    It finds every fuzz target at a pinned revision, then runs each one by exact name. Ordinary tests stay out of it. One broken package elsewhere never takes a healthy target down with it.

    pinned revision · exact target · isolated failure

  2. 02

    Run somewhere that is not your checkout

    Every run gets its own detached worktree, leased to it alone. Your working copy is never touched. It can search all night in the same repo you are editing.

    detached worktree · exclusive lease · zero checkout writes

  3. 03

    Measure it, then seal it

    It records the CPU time the run actually used, writes that to a durable record, and seals the result into one signed piece of evidence. The signing key is made on your machine and never leaves it.

    rusage CPU · content-addressed · signed locally

  4. 04

    Opt in once; the fleet learns together

    Once a day, each machine sends only new coverage-increasing corpus entries, unique retained findings, and sealed proof into encrypted tenant-private cloud storage. Other machines pull unseen corpus entries and start from the fleet's combined frontier. Findings stay in a separate vault and are never fed back into normal fuzzing.

    explicit opt-in · daily exchange · encrypted custody

Inside your boundary

Source, repository contents, secrets, paths, and raw process output never leave. Cloud Evidence uploads are disabled until you opt in, and Local has no cloud evidence plane.

Add machines and the search gets bigger. Hosted fleets exchange useful corpus entries once a day without a coordinator, shared lock, or customer-run cluster.

  • Your local copy remains authoritative. If we go down, searching continues and the encrypted upload backlog stays visible until service returns.
  • Coverage corpus entries help the fleet search; retained findings remain separate so a known failure never poisons the active corpus.
  • We never receive your source, repository tree, credentials, filesystem paths, or raw child output.

The number

One sentence, and it has to be true.

The whole product exists to earn one line about one project. Everything else on this page is what makes that line worth believing.

Not a mockup. These figures are read live from our own run records, right now, for a codebase peachfuzz has been searching for months.

The unit, in plain terms

  1. core-second One core, busy, for one second The grain everything else is counted in. Measured, never guessed.
  2. core-hour One core for an hour. Or four cores for fifteen minutes About what one careful afternoon buys. Most teams never get past this.
  3. core-day Twenty-four core-hours, in any shape A spare eight-core box gets here in three hours. This is the first number that sounds like a habit.
  4. core-year One core, busy, for 365.25 days You cannot get here by hand. You get here by leaving it alone. This is the number that ends the conversation.

Why the number is allowed to be believed

  • It counts the CPU the work actually used. Two workers pinning two cores for a minute record about two core-minutes, because that is what they burned.
  • It never counts the clock on the wall. A machine that sat idle all night records nothing for those hours. That is the whole difference between a measurement and a boast.
  • It rounds down, never up. You get the largest unit that still tells the truth.
  • It adds up in strict order from records already written to disk, behind a mark that pruning cannot cross. A crash cannot inflate the total, and cannot lose a run.
  • Each machine signs its own. Adding machines adds more signed evidence, not a shared counter someone could nudge.

A number you have to defend is worse than no number at all. Ours is smaller than a wall-clock number would be. There is no setting to make it bigger, and there never will be.

Who it pays off for

One machine. Three teams stop worrying.

You buy it to keep looking for holes. What surprises people is who else comes asking for the output.

Engineering sleeps better

Something attacks your code every night that never gets bored and never skips a target. It finds the input that breaks the parser before a stranger does, hands you a repro, and stops there.

Marketing gets a number

"We have run core-years of continuous fuzzing against this codebase." Nobody else in your category can say it, because nobody else is counting. The rare security claim that survives being checked.

Legal gets evidence

Certifications, questionnaires, diligence: all of them ask you to show it. A signed record held by an outsider closes the question instead of opening a longer one.

What the daemon does

A harness that lets Go's fuzzer shine.

Go already ships a world class fuzzer. We do not replace it, improve it, or wrap it in anything clever. We build the harness that lets it run for months instead of minutes.

Built on

  • go test -fuzz
  • Git worktrees
  • launchd / systemd
  • Object storage
peachfuzz the long run

rotate / retain / measure / sign

Produces

  • Signed run evidence
  • Per-project effort snapshot
  • Retained candidates
  • Fleet and project reports

Continuous evidence

— inputs tested

— of continuous fuzzing

Awaiting live evidence.

Last sealed
—
Peachy since
—
packages
—
targets
—

What it tests

Peachfuzz sends millions of malformed, unexpected, and adversarial inputs through the code.

Why it matters

It uncovers crashes and security flaws that ordinary tests can miss before customers encounter them.

Runs continuously. Every figure above comes from tamper evident, replayable run records.

The fleet searches as one

Opted-in hosted machines exchange new coverage-increasing corpus entries once a day. Add a machine and it starts from the tenant's shared frontier without a leader, lock server, or customer-run cluster.

A dial, not a decision

Shared takes 60% of cores at lowest priority, so the machine stays yours. Max takes 95% on a box with no other job. One word in the config.

Every target gets its turn

One loud target cannot eat the budget. None can go unvisited for weeks. There is a hard ceiling on how stale any target may get.

One broken package breaks one package

A package that stops compiling does not retire a healthy target. Breakage stays where it happened.

Replay any finding

Every retained input knows its project, target, and revision. One command runs it again, exactly.

Runs like infrastructure

Writes its own launchd or systemd unit. Bad config fails at startup, not at 3am. Typed exit codes, bounded shutdown.

Day one

Install, point it at a repo, leave it alone.

There is no onboarding call and no dashboard to learn. The setup is a JSON file and a service unit; after that the product's job is to be boring for months at a time.

  • Peachfuzz runs trusted project code and is not a sandbox. It belongs on your hardware, running your repositories, inside your own trust boundary.
  • It never files an issue, opens a pull request, edits a project, or claims a retained candidate is a vulnerability. It points at repros and stops.

the whole command surface

peachfuzz discover
peachfuzz once
peachfuzz run --mode=shared
peachfuzz activity
peachfuzz report
peachfuzz reproduce <finding>
peachfuzz unit

What each command answers

discover

Shows the exact targets peachfuzz sees at the pinned revision, so what it will run is never a surprise.

once

Runs a single scheduling cycle in the foreground. This is the whole product, visible, before you supervise it.

activity

Live budget, active targets, and current slice ages, for the moment you want to confirm it is really working.

report

The fleet or one-project account: effort, freshness, breadth, and retained candidates with reproduction identities.

On your disk

peachfuzz.json

Strict configuration

Unknown fields, duplicate fields, trailing data, unsafe Git refs, and out-of-range values all fail before anything executes. A typo is a startup error, not a silently different daemon.

identity

Machine signing key

Generated locally on first run and never transmitted. The public key derives the machine identity in the ledger. Peachfuzz refuses to silently re-key an installation and strand its history.

candidates/

Content-addressed corpus

Every retained input is stored under its SHA-256 digest. Bytes become durable before the generated source is allowed to be cleaned, so a crash cannot lose a finding.

runs/

Durable run records

One crash-consistent record per slice with a monotonic sequence. Restart streams and folds every newer record in order, which closes the append-before-report window.

Design rules

Rules we will not trade for a feature.

These are the rules the code is written against. They are on the sales page because they are the product.

It never touches your checkout

It works in worktrees it leases. Nothing it does reaches your working tree, index, or branch.

Findings survive a crash

Bytes hit the disk before the source that made them can be cleaned up. Losing a finding is not an acceptable failure.

Nothing can be overwritten

Uploads are create-only and digest-checked. A ledger you can edit is a database, not evidence.

Everything has a ceiling

Reads, output, retries, history, shutdown. Unbounded is how a watchdog becomes the outage.

Backlog pauses, never drops

If archiving falls behind, work stops and the backlog stays visible. It will not quietly bin evidence or fill your disk.

The number can be rebuilt

Delete the published snapshot, replay the ledger, get the same snapshot back.

What we will not claim

The limits, stated first.

A page arguing that unchecked claims are worthless has no business making any. Here is what peachfuzz does not do.

Go only

Not C, Rust, Java, or Python. Driving a non-Go binary would lose the coverage feedback that makes fuzzing work at all.

A finding is not a vulnerability

It records what ran and what survived. Whether that is a security defect is your engineers' call. We will not inflate a count by pretending otherwise.

A quiet target proves nothing

We report the fact: no new entries in N runs. We do not call it healthy. Excellent, unreachable, and starving all look identical from here.

Execution counts are approximate

Go prints progress as text, so counts are parsed and labelled approximate. CPU time is the number we stand behind.

The engine is Go's, not ours

We do not improve the mutator and never claim to. We give it months instead of minutes, on hardware that was idle anyway. That is the whole difference, and in practice it is the one that matters.

No reference customers yet

It has run against our own Go for a long time. That is our homework, not a track record. If early is not a risk you take, wait.

Where it sits

Three products, one argument.

Off Grid builds evidence infrastructure for engineering claims. Each product answers a different question the same way: with an artifact somebody outside your company can check.

An attacker only has to find it once. You have to be looking the whole time.
  • bug proves a defect was really closed: described, red-tested, green-fixed, explained, and committed.
  • Witness proves a quality run really happened, sealed and held by a custodian with no stake in the result.
  • Peachfuzz proves you kept searching for the defects nobody ever reported.
  • Closure, verification, search. Each is worth something alone; together they answer almost every question a reviewer knows how to ask.
  • None of the three requires trusting us. That is the point of all three.

Honest comparison

What else you could reasonably do.

Every one of these is a real choice and some are free. Here is what each gives you, including where it beats us.

Run go test -fuzz yourself

Free, installed, finds the same bugs. Beats us on cost and nothing else. Nobody sustains it for months, and there is no artifact at the end.

A cron job and a shell script

Works until the disk fills, a broken package retires a target, two runs race the same checkout, or the engineer who wrote it leaves. Then it is nobody's job.

OSS-Fuzz

Excellent, free, better resourced than us. Open-source only, on Google's terms, and the artifact is theirs. If you qualify, use it.

Mayhem and the commercial platforms

More capable than us: multi-language, hosted, real triage. They sell fuzzing. None of them hands you a signed record you can publish without them.

Fuzzing in CI

Worth doing. But sixty seconds in a pull request is a regression check, not a search. Wrong shape for something whose value is accumulated time.

Nothing

The most common choice, and fine right up until someone asks. Nothing costs zero every month, then all at once.

Getting it running

Minutes to start, then months of nothing.

The install is deliberately small. The whole point is that afterwards you stop thinking about it.

1. Find a machine

A spare workstation, an idle build host, a cheap box. Anything you already own.

2. Write the config

Point it at your repos and an output directory. Two fields are required. A config that starts is a config that is correct.

3. Watch one cycle

Run discover to see the exact targets, then once to watch a cycle in the foreground. Nothing gets supervised until you have seen it work.

4. Supervise it

Generate the launchd or systemd unit from the same binary. This is the last step that needs you.

5. Then light up every other machine

Here it stops being a tool and becomes a shield. Every machine signs its own hours; an opted-in hosted fleet exchanges useful corpus entries once a day through the same JSON configuration, with no customer-run coordinator or cluster.

6. Come back when asked

You will open it again because a questionnaire, an auditor, or an incident asked what you did. That is when months of nothing become the answer.

Then it runs without you

Setup is a short config and one command, and then it does not need you. Every hour the machine is up is another hour of search you never had to think about, and the record of those hours is what you hand over when somebody finally asks.

Where peachfuzz fits and how to judge it

Why this exists

We built it for ourselves first.

It exists because we needed to answer this question about our own products and could not.

  • We ship Go that other companies put in their evidence path. That raises the bar for what we can claim about it.
  • We had fuzz targets and no way to say how long they had run. The honest answer was a shrug.
  • Every option was open-source only, another vendor's dashboard, or a shell script waiting to rot.
  • So we built it boring, bounded, and supervised, and made the number smaller than a flattering one would be.
  • We sell what we run, at the price we would pay, with the limits on the page instead of in your way later.

How to judge this

Questions to ask any vendor, including us.

Do not take this page's word for anything. Ask these of everyone, us included.

  • Measured CPU, or wall-clock? Wall-clock counts hours the machine sat idle. That is not a measurement.
  • Who holds the signing key? If the vendor does, the vendor can make the evidence without you.
  • Can the record be overwritten? A ledger where a conflict is loud behaves nothing like a database row.
  • Does the artifact outlive the vendor? If verifying needs their servers, you rent your own history.
  • Does your code leave your hardware? For a fuzzer that is also the sandbox question.
  • Is the price published? Most of this category hides it behind a demo. Ours is above.

The going rate

What proof costs elsewhere.

Peachfuzz is narrower than everything below it: Go only, no hosted compute, no triage workflow. It is also the only one that hands you an effort record you own. Judge the price against both facts.

  • $236/mo

    Commercial fuzzing platform, entry tier

    Mayhem's reported starting price, scaled by tier and core count. Multi-language and hosted, with the evidence living in their platform.

    Capterra vendor listing (opens in new tab)
  • $49/dev

    GitHub Advanced Security, per active committer

    A twenty-developer team pays about $980 a month for code scanning across every repository, and none of it is fuzzing.

    AppSec market survey (opens in new tab)
  • $25-98/dev

    Snyk, per developer per month

    Priced per scanner bundle, so the real figure depends on how many products are switched on. Static analysis and dependencies, not search.

    Snyk published plans (opens in new tab)
  • Contact us

    Most of this category

    The dominant pricing model in fuzzing is a demo booking. When a price is not published, it is because it varies by how much the seller thinks you can pay.

    Code Intelligence pricing page (opens in new tab)

Published prices, org-wide, on this page, the same for a two-person team as for a public company. Peachfuzz starts below every figure above it, and the tier that competes with them on custody still costs less than the entry tier of a platform that keeps the evidence. If a number stops making sense for us we will change it for new subscriptions, not for yours.

Pricing

One price. Unlimited everything.

Every tier runs the same local daemon on unlimited machines. Attested and Archive unlock opt-in encrypted Cloud Evidence: daily fleet corpus exchange, finding backup, and independently held proof. They differ only in how long we retain it.

Every tier is a monthly card charge you can cancel yourself. No purchase order, no procurement cycle, no vendor onboarding, no sales call, no annual commitment. Even the top tier is priced to remain a card purchase rather than turn the tool into a procurement project.

No custody

Local

$20per month, org-wide, after the trial

Works on Go only

For teams that want the search to actually happen and do not need anyone outside the company to vouch for it.

  • The complete local fuzzing daemon
  • Unlimited repositories, machines, cores, and targets
  • Your effort number, your corpus, your reports, held by you
  • Nothing leaves your machines but the lease check-in and its counters
  • Self-attested: useful to your engineers, not to an auditor
1 year custody

Attested

$175per month, org-wide, after the trial

Works on Go only

For teams that ship Go someone else depends on and will be asked to prove what they did about it.

  • Everything in Local
  • Opt-in encrypted Cloud Evidence, disabled until you enable it
  • Daily tenant-private exchange of new coverage-increasing corpus entries
  • Unique retained findings backed up separately from the active corpus
  • Signed proof ledger and published effort snapshot
  • 1 year of rolling cloud custody while paid
  • Email support, direct to the person who wrote it
5 year custody

Archive

$350per month, org-wide, after the trial

Works on Go only

For regulated programs where the record has to outlive the engineers who produced it.

  • Everything in Attested
  • 5 years of rolling cloud evidence and finding custody
  • Founder statement explaining the record to auditors or a court
  • Procurement and legal review support

Honest. Up front. Predictable.

What each tier is for
Tier and windowWho needs itWhy it is worth it
Local, no custodyTeams who want the searching to genuinely happen and answer to nobody outside the company about it.Keeps the complete search, corpus, findings, and proof on your own machines.
Attested, 1 yearMulti-machine teams that want one shared search frontier, finding backup, and outside proof.Encrypted daily exchange prevents useful corpus discoveries from remaining trapped on one machine and holds a year of the resulting record.
Archive, 5 yearsFinance, healthcare, government, and defense programs with long retention obligations.Uses the same private fleet exchange while preserving cloud evidence and findings for the long review window.

Published list prices, the same for a two-person team as for the Fortune 100. No negotiated rate, no Contact Sales button, no discount cycle.

Thirty days free, one trial per customer. Nothing is charged until the trial converts, and cancelling before then costs nothing.

Your rate is locked from your start date for the whole of your tier's custody window. A later list price rise applies to new subscriptions, not to yours.

You supply the compute. That is deliberate: it keeps your code on your hardware, and it means adding cores costs you nothing here.

Custody

One encrypted frontier. Still yours.

Cloud Evidence is an explicit opt-in for Attested and Archive. It gives the tenant's machines a shared coverage frontier, backs up unique findings separately, and lets an independent custodian hold the signed proof.

Local

Your disk, your policy.

Teams who answer to nobody outside the company.

No custody. It runs, the number grows, none of it reaches us.

Retained
Nothing at all.
Reason
Some teams do not need a third party. Selling them one anyway is the behaviour this page argues against.
Guardrail
Your own backups. Without them a dead machine takes the learning with it, exactly as it would without us.

Attested

1 year, rolling, while you are subscribed.

Multi-machine teams shipping Go that other companies depend on.

Opt-in encrypted fleet corpus exchange, finding backup, signed evidence custody, and the published snapshot.

Retained
New coverage-increasing corpus entries, unique retained findings, signed run evidence, and the folded ledger.
Reason
Useful discoveries stop dying on one machine, and the outside proof no longer depends on your copy alone.
Guardrail
Create-only, encrypted, digest-checked. Tampering makes verification fail rather than pass quietly.

Archive

5 years, rolling, while you are subscribed.

Regulated programs with retention measured in years.

The same encrypted exchange and vault, a long window, and a person who will explain the record.

Retained
The same cloud evidence and findings, held longer than the staff who produced them.
Reason
Regulators, acquirers, and courts ask years after the engineers have moved on.
Guardrail
Same guarantees, plus founder testimony at the published rate.

The vault, in plain terms

Storage is cheap and we are not charging you for disk. The fee buys an obligation: hold the record, keep it verifiable, and account for how it was held when somebody asks.

  • Cloud Evidence is off until an Attested or Archive customer explicitly enables it.
  • Opted-in uploads are encrypted in transit and at rest, tenant-private, content-addressed, and limited to useful corpus entries, unique findings, and signed proof.
  • We never receive source, repository contents, filesystem paths, credentials, secrets, or raw process output.
  • Custody is rolling, not prepaid. Cancel in month three and you bought three months plus the export window.
  • If payment fails you get thirty days to fix it, then thirty more to export everything. A runway, not a hostage situation.
  • Your copy is the real one. If we vanish tomorrow, your daemon keeps running and your records keep verifying.
  • Off Grid holds no SOC 2 or ISO 27001 today. Better you read it here than find it in your vendor review.

FAQ

Straight answers.

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.

peachfuzz

Start the clock today.

The record is made of elapsed time, which is the one input that cannot be bought later. Thirty days from now you either have a number or you have the same shrug you have today.

Start the free trial