Migration

How to migrate from QA Wolf to self-hosted agentic QA

2026-08-29 · The QA Reef team · 9 min read

"Migrate away from QA Wolf" usually means one of two different things, and they have very different costs. If you mean "stop paying for Coverage as a Service and run test execution myself," that's a real, well-scoped project — most of what you'd rebuild is your own test logic, not QA Wolf's platform. If you mean "replace the human QA engineers who reproduce and verify our failures," that's a much bigger ask, and no self-hosted tool — QA Reef included — replaces that today. This post is about the first kind of migration, done honestly, with the actual steps.

Step 1: figure out what you actually depend on

Before moving anything, separate what you use QA Wolf for into three buckets:

Flow authoring and local execution. Your .flow.ts files, and running them. This is the genuinely portable part — see below.
Hosted execution. QA Wolf's pre-warmed Kubernetes runner grid, described in their own engineering blog (qawolf.com/blog). This doesn't move with you — you need your own CI runners or a self-hosted execution setup instead.
Human verification and maintenance. QA Wolf's dedicated QA engineers reproducing and triaging failures, part of Coverage as a Service (qawolf.com/service). There's no tooling substitute for this — you either keep a human doing it, or accept that your team now owns triage.

Most teams migrating away from a managed platform are really migrating buckets one and two, and keeping (or building) their own version of bucket three internally. Be honest with your team about that trade before you start, not after.

Step 2: your flow format is more portable than you'd expect

Here's the part that's genuinely good news, and we verified it directly rather than assuming it: QA Wolf's local flow format — a .flow.ts file whose default export is flow(name, target, callback) from the @qawolf/flows package — is Apache-2.0/MIT licensed and runs entirely offline through QA Wolf's own @qawolf/cli, with no account or network call required. We cloned the CLI, built it, and ran real flow files with no QAWOLF_API_KEY set at all — confirmed by the CLI's own structured JSON output ({"type":"success","message":"Environment ready"} straight through to a pass). Only the platform-backed commands (flows run --env, environment, issue, tag, and anything under auth) require their paid API.

What this means practically: your existing .flow.ts files, and the CLI that runs them, aren't hostage to your QA Wolf subscription. You can keep running them locally or in your own CI with the same open-source runner QA Wolf itself uses, indefinitely, whether or not you keep paying for the platform.

Step 3: decide how to rebuild the recording/generation step

What you lose without a paid QA Wolf account is Mapping AI and Automation AI — the parts that turn a recorded session or a prompt into new .flow.ts code. That's the actual gap to fill. If you switch to QA Reef for this step, the shape is similar but the internals differ: QA Reef's mapping session records real clicks/types/drags as you drive your app (or lets an OCR-driven operator drive it from a plain-English goal), and an Automate job turns that recording into Playwright test code — not QA Wolf's .flow.ts format directly, but the same underlying idea (record once, generate code, own the result).

If you want to keep authoring in QA Wolf's own format specifically — because your team already knows it, or you want a cross-check against another runner — QA Reef ships a converter (app/codegen-flow.js, toQawolfFlow()) that takes a QA Reef-recorded flow and emits a .flow.ts file in QA Wolf's exact shape: the same target/preset convention, the same locator-resolution order, the same {param}-to-process.env secrets convention their CLI uses. We converted three real recorded flows and ran them through the unmodified QA Wolf CLI — two passed outright, the third failed only because its target dev server wasn't running, not because of a format mismatch. Full commands and output are documented in vendor/QAWOLF-OSS.md in the QA Reef repo, if you want to verify it yourself rather than take our word for it.

Step 4: replace hosted execution

QA Wolf's Kubernetes runner grid goes away with the platform subscription. The replacement is whatever CI you already run — GitHub Actions, a self-hosted runner, a cron job on a box you control — pointed at qawolf flows run (if you're keeping QA Wolf's own CLI) or your QA Reef-generated Playwright tests. Neither approach requires new infrastructure beyond what most teams already have for running Playwright in CI; the difference is you're now managing the runner capacity yourself instead of QA Wolf autoscaling it for you.

Step 5: rebuild triage, deliberately

This is the step teams underestimate. QA Wolf's human-verified triage is real work someone was doing for you. Moving off it means either: your team picks up triage (a failed run needs a person to look at it and decide flake vs. real bug vs. broken test), or you lean on tooling to reduce the load — for instance, a third verdict state so ambiguous results don't masquerade as real failures in the first place (see PASS / FAIL / UNMEASURED), and auto-filed bugs with evidence attached so triage starts from a trace instead of "did anyone else see this?" in Slack. Neither of those is a human-verification replacement — they reduce the noise a human has to wade through, which is a different, smaller claim.

What doesn't migrate cleanly

Be honest with stakeholders about three things that don't have a drop-in self-hosted equivalent yet: mobile testing (QA Wolf's Appium-based mobile support has no QA Reef equivalent today), a hosted execution grid (you're managing your own CI capacity now), and human-verified "zero flake" reporting (your team owns that judgment call now, or you keep paying someone to make it).

The short version

Your .flow.ts files and the CLI that runs them are genuinely yours, verified — not vendor-locked. What you're actually replacing is the AI-assisted authoring, the hosted execution grid, and the human triage layer. Plan the migration around those three, not around a fear that your existing flows are trapped, because they aren't.