What is Haystack (haystack.sh)?

Haystack is a pre-production verification platform that gives every code change its own copy of production and replays real customer journeys against it to expose what breaks. It's aimed at teams whose failures slip past conventional tests — the quiet kind where nothing throws, every request returns 200, and the test suite still passes. According to the site, Haystack is early and taking on a small number of teams, so access is via early signup or a demo rather than open self-serve.

How it works

The workflow has four moving parts, and the ordering matters: cases are derived from the change, environments are forked per case, then each case runs twice so the change is the only variable.

Blast radius

Haystack reads the diff and works out every case the change can affect. The cases are your customers' real journeys, learned from production traffic, narrowed to the ones the change can reach — not scenarios someone invented for a test.

In the worked example on the site, a permissions refactor touching two files reaches 3 services and 27 code paths, producing 14 cases worth running, mapped in about five seconds. You do not write the cases.

Fork your infrastructure

Haystack snapshots your services and the data behind them — Postgres and Redis through to queues and object storage — then forks that snapshot once per case. The example: 14 copies of prod, ready in 26 seconds. These are real environments, not mocks, and nothing inside one reaches prod.

Run every case at once

Each environment is seeded into a different state: a workspace over its seat limit, an invite nobody accepted, a member whose role just changed. Every environment runs twice — with and without your change — so any difference is caused by the change.

See what actually broke

Failures come with the screen before and after, the network calls that changed, and the events that stopped firing. The environment stays live, so you can open it and look around.

Your agent runs the loop

The failing case goes back to your coding agent in a form it can act on. It fixes, re-runs, and keeps going until nothing fails.

Why it catches what tests miss

The failures that reach production are usually quiet. In the site's worked example, a frontend stopped sending a member's role and the access API treated a missing role as editor — so anyone with a pending invite could edit and delete anything in the workspace. Nothing threw, every request returned 200, and the test suite passed.

That example is the clearest statement of what Haystack is for: it targets silent behavioral regressions that don't surface as errors, which is exactly the class of bug a passing test suite can't rule out.

Using it

The CLI is haystack verify. The site points to three references for the details:

Getting started

Haystack is early and taking on a small number of teams. You can sign up for early access at https://haystack.sh/ or book a demo.

Who this fits

Haystack is worth evaluating if your changes touch shared services and data — permissions, roles, invite flows, anything where a missing field silently changes behavior — and your existing tests keep passing while production breaks. It's a weaker fit if your changes are isolated enough that a conventional suite already covers the reachable cases, or if you need open self-serve access today, since the site describes early access for a limited number of teams rather than general availability.