How to Get Access to Haystack (haystack.sh)

Updated

Haystack is in early access and is onboarding a small number of teams, so there is no self-serve signup flow described on the site. To get in, you sign up for early access at https://haystack.sh/ or book a demo. Both routes are listed under the site's "Getting started" section, and neither is described as instant — expect to be evaluated as part of a limited cohort rather than getting immediate access.

What you are actually requesting access to

Haystack is a pre-production verification tool. It gives every code change its own copy of production and replays real customer journeys against it to expose what breaks, before customers see it. That framing matters for access: this is not a product you can meaningfully trial on a toy repo, since its value comes from reading your diff, forking your real infrastructure, and replaying your production traffic.

The two access routes

Route What it is When to use it
Early access signup Register at https://haystack.sh/ You already know you want in and can wait for a slot
Book a demo A guided walkthrough of the product You want to see how it works on realistic scenarios before committing

The site does not state pricing, seat limits, or contract terms for either route. If cost or procurement terms are a deciding factor, treat the demo or signup conversation as the place to get them — nothing in the public material answers it.

What happens once you have access

Access leads into a CLI-driven workflow, so it helps to know what you are signing up for:

  1. Point Haystack at a change. It reads the diff and works out every case the change can affect. The cases are your customers' real journeys, learned from production traffic and narrowed to what the change can reach — you do not write them.
  2. Fork your infrastructure. Haystack snapshots your services and their data (Postgres, Redis, queues, object storage) and forks that snapshot once per case. In the site's worked example, 14 copies of prod were ready in 26 seconds.
  3. Run every case at once. Each environment is seeded into a different state — a workspace over its seat limit, an unaccepted invite, a member whose role just changed. Every environment runs twice, with and without your change, so any difference is attributable to the change.
  4. Read the failures. Results 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.
  5. Close the loop with your agent. The failing case goes back to your coding agent in an actionable form; it fixes, re-runs, and repeats until nothing fails.

The command is haystack verify. The site points to separate pages for haystack verify and its flags, "Working with runs" for reading results, and "Agents" for the MCP server and the agent loop.

Why the access bar is narrow

The site's own example explains the pitch: a permissions refactor touching two files reached 3 services and 27 code paths, producing 14 cases worth running, mapped in about five seconds. In that scenario a frontend stopped sending a member's role, the access API treated a missing role as editor, and anyone with a pending invite could edit or delete anything in the workspace. Nothing threw, every request returned 200, and the test suite passed. Catching that class of quiet failure requires real environments and real traffic, which is why Haystack is onboarding teams selectively rather than opening a free tier.

Practical next step

If you want access, start at https://haystack.sh/ and sign up for early access, or book a demo if you would rather see it working first. Come prepared with a specific change you would want verified — the product's value is easiest to judge against a real diff and real traffic, not a hypothetical.