Pre-deploy testing for n8n

Test n8n workflow changes before your clients do

Preflight records real executions from a client’s n8n instance, replays your edit against them, and compares each node’s output with the recording, naming any node it could not check — so you see behavior changes before clients do. n8n can report “succeeded”; Preflight reports whether the behavior changed.

Founding members keep the prices on this page for life. One email when the beta opens.
Replay report · fulfillment-watchdog Deploy blocked
n8n Run succeeded No errors. No alerts. Nothing to see.
Preflight Behavior changed at “Analyze Fulfillment” the first node whose output differs from the recording
Output diff — first divergence
flag_count4→6
flags4 items→6 items
Cause analysis: your edit — the first diverging node was itself modified. Previous version pinned for one-click rollback.

A real replay from our test suite: a one-word bug planted in an order matcher. n8n reported no error; shipped, it would have sent wrong alerts every morning.

The problem

The failures that cost you clients don't throw errors.

They run “successfully” while doing the wrong thing, and surface days later — on the client's side. Each of these is a recurring topic on the n8n community forum.

The silent edit

One node changes, the editor looks fine, and a downstream output quietly changes shape. Data is wrong for a week before anyone notices.

“Nothing failed, so nothing told us.”

Breakage that isn't your edit

A third-party API renames a field, a token expires, a node is deprecated in an update. Most incidents aren't caused by the person who answers for them.

“It broke by itself over the weekend.”

The sub-workflow blind spot

A sub-workflow is edited; the parent's definition is byte-for-byte identical. Definition-based diffs report no change at all. The behavior changed. How to test a sub-workflow change before you publish it.

“The diff was clean. The output wasn't.”

The first of those in depth: why an n8n workflow succeeds with the wrong output, and what to check before a client sees it.

FAQ

Questions agencies ask before connecting a client.

What is Preflight?

Preflight is a pre-deploy testing and deploy gate for n8n workflows. It records real executions, replays your edit in a sandbox, diffs every node’s output, and can block deploy when behavior changed.

How do I test n8n workflow changes before clients see them?

Connect the client instance (URL + API key), record real runs, replay your edit against those recordings, then review per-node diffs before you deploy. Testing installs nothing on the client side; the optional run-rate monitor for watched deploys is one workflow you import yourself.

How is Preflight different from n8n’s workflow history and diffs?

n8n history/Git diffs compare workflow definitions (JSON). Preflight compares behavior — it reruns the edit on recorded inputs and checks what each node actually produced.

Do client credentials leave the client’s n8n instance?

Not the ones stored in it. Preflight never reads the credentials stored in a client’s n8n, and replays run with every credential stripped. The one credential it holds is the n8n API key you register, encrypted at rest.

Can Preflight check an n8n upgrade before I upgrade?

Yes. It replays each workflow’s latest recording on the target n8n version in a sandbox, without touching the client's server, and reports each workflow as safe, breaking on the new version only, already flaky, or untestable. Untestable covers two cases: a workflow with no recording yet, and a recorded workflow whose HTTP or side-effect nodes a replay cannot vouch for, because a replay never calls outside services. Most real workflows contain at least one such node, so untestable is a common answer here rather than a rare one. It is never folded into safe.

What happens when an execution was only partially recorded?

Every recording carries a completeness score. Nodes whose data was not captured are marked untestable and are never counted as passing. A replay reports a pass only for nodes with complete recorded data.

What can Preflight tell me before there is anything to compare against?

The conservation check compares a recording to arithmetic rather than to another run, so it needs no baseline, no replay and no sandbox, and it answers on the first execution you record. Where a node should pass every item through, it reports items in against items out and names the input row that went missing; elsewhere it compares counts. It judges the node types in its contract table and reports the rest as unjudged, so a quiet result is never read as a clean bill of health.

How much does Preflight cost?

Preflight is priced per agency, not per client instance. Solo is $29 per month for 3 instances, Agency is $79 per month for 15 instances with deploy gates and an audit trail, and Scale is $199 per month for unlimited instances. Plans and billing begin with the beta. Founding members who join the waitlist keep the prices on this page for the life of their subscription.

Is Preflight related to CORS preflight requests in n8n?

No. Preflight (preflightgate.com) is a pre-deploy testing tool for n8n workflows and has nothing to do with CORS preflight requests, the browser’s OPTIONS check that n8n webhooks sometimes fail. A CORS preflight error is fixed in the webhook’s allowed-origins setting or the reverse proxy in front of n8n, not with Preflight.

Is Preflight affiliated with n8n?

No. Preflight is an independent product. It works with your clients’ n8n only through n8n’s public API, and runs replays in an n8n sandbox of its own. It is not affiliated with or endorsed by n8n GmbH.

Every way to test a change, with or without Preflight: how to test n8n workflow changes before production.

How it works

A flight check for every change.

Connect a client instance with its base URL and an API key. Testing installs nothing on their side. From then on, every change follows the same four steps.

Record

Real executions become replayable fixtures: per-node inputs and outputs, with an honest completeness score. Email addresses, phone numbers, card numbers, IBANs, US Social Security numbers and IP addresses that match known patterns are redacted on ingest.

Replay

Your edited workflow runs in Preflight’s sandbox against the recording. HTTP Request nodes are answered from the fixture, email, chat and SMS sends are switched off, every other step runs with no credentials, and anything the sandbox could not faithfully run is marked untestable. Preflight never reads the credentials stored in your client’s n8n.

Diff

Every node’s output is compared, with noise rules for timestamps and volatile fields. A red diff names the exact node, and whether it is the one you edited or one reacting to an edit upstream.

Gate

By default, a deploy needs a green replay of that exact change, or a red or partly untestable replay you have explicitly accepted. The previous version stays pinned for one-click rollback, and every deploy is audited.

Beyond the replay

Some failures a faithful replay cannot catch.

A replay reproduces what one recorded run did. These four checks cover what that cannot see: a workflow nobody has replayed yet, a side effect that is correct once and wrong twice, a case that has never happened, and the minutes after the deploy lands.

Conservation

Items in against items out, from the recording alone — no baseline, no replay, no sandbox. It answers on the first execution you record. Where a node should pass every item through, it names the input row that went missing; elsewhere it compares counts, and it calls the node types it has no rule for unjudged.

Repeat safety

The same fixture run twice in one sandbox lease, counting how many times each send step it recognises (Send Email, Gmail, Outlook, Slack, Telegram, Discord or Twilio) was reached. A workflow with no dedupe guard in front of a notification is green on every single replay. Run it twice and it isn’t.

Designed cases

Plant a case the recording never contained, such as a duplicate line or an unknown item code, on a webhook-triggered workflow, replay it, and read what each step did with it. Steps answered from the original recording, and everything after them, are marked untestable by construction.

Watched deploy

After a deploy, a window watches whether the workflow keeps running, and marks the deploy stalled on the workflow’s page if the runs stop where its usual rhythm predicted some. It counts runs; it does not judge their output, and it needs the optional run-rate collector on the client’s n8n. It never reverts on its own: rollback stays one click away.

Upgrade check

Know if the next n8n release breaks you — before you upgrade.

Every n8n release produces the same forum thread: workflows that ran flawlessly for months, crashed after the version bump. Preflight replays each workflow’s latest recording on the target n8n version in its own sandbox — the client's server is never touched — and reports, workflow by workflow, what survives. Each workflow also replays on the current version, so one that was already unstable is called flaky instead of being blamed on the upgrade. A replay never calls outside services, so a workflow whose HTTP or side-effect nodes cannot be vouched for is reported untestable, with the count and the reason. Most real workflows contain at least one such node. That answer is the honest one, and it is never folded into safe.

Upgrade check · Acme Corp instance · 2.33.7 → 2.35.7 Hold the upgrade
order-router Safe Reproduces its latest recording on 2.35.7
invoice-sync Breaks on 2.35.7 Output diverges at “Format Invoice” — on the new version only
charge-retry Untestable 3 nodes could not be tested — 2 stubbed HTTP, 1 side effect skipped
lead-enrich Flaky Diverges on both versions — not the upgrade's fault
pdf-export Untestable No recording yet — reported honestly, never counted as a pass
Fix or re-record invoice-sync before touching the client's server — and read charge-retry as unproven, not as safe.

Illustration of the report’s format: the client and workflow names are examples.

Upgrading to n8n 3.0? How to test your workflows before you upgrade, with or without Preflight.

The difference

Definitions tell you what changed. Behavior tells you what broke.

n8n's Business tier compares workflow definitions. Preflight replays your edit and compares every node's output, which catches what a definition diff cannot: an expression that now resolves to nothing, a renamed field, a branch that quietly stopped running. What a replay cannot see is an outside API that changes its response, because a replay never calls one: HTTP Request nodes get their recorded answers.

What n8n Community, n8n Business and Preflight each include
Capabilityn8n Communityn8n Business (€667/mo, billed annually)Preflight
Version history & rollback24-hour history onlyIncludedIncluded, needs only an API key
Definition diffs—Included—
Replay real executions against an edit——Included
Per-node behavior diffs with cause analysis——Included
Replay your workflows on the target n8n versionMigration Report (lists known changes)Migration Report (lists known changes)Included
Deploy gate & audit trail——Included
Agency pricing model—Per instancePer agency, from $29/mo

Side by side, in detail: n8n definition diffs vs behavior testing — what a clean JSON diff still misses.

Pricing

Priced per agency, not per client.

Per-instance pricing is precisely what agencies resent. One subscription covers your client base.

Solo
$29
per month
  • 3 client instances
  • Version history & one-click rollback
  • Record, replay & diff
Join the waitlist
Scale
$199
per month
  • Unlimited instances
  • Seats & roles planned
  • Priority support from launch
Join the waitlist

Founding members: join the waitlist now and keep the prices on this page for the life of your subscription. Plans and billing begin with the beta; items marked planned are not built yet.

Principles

Built to be trusted with production.

Public API only

Preflight works with your clients’ n8n only through its public API. Replays run in a separate n8n sandbox that Preflight owns, never on the client’s server.

Credentials stay put

Preflight never reads the credentials stored in your clients’ n8n. Replays run with credentials stripped, and recognised secrets in recorded runs are fingerprinted before anything is stored.

Honest coverage

Nodes without a complete recording are marked untestable. A test never claims coverage it doesn't have.

Audited deploys

Every deploy writes its audit entry before it executes: what changed, when, and which replay cleared it.

Self-hosted first

Built for self-hosted n8n, Community edition included — where agencies actually run client work.

Runs where you want it

Preflight is designed to run on your own hardware and to send nothing home unless you press Send on a bug report, which shows you exactly what it contains first. Recordings and records stay in its own database.

Private by design

Email addresses, phone numbers, card numbers, IBANs, US Social Security numbers and IP addresses that match known patterns are redacted when recordings are ingested; the originals are kept in an encrypted vault.

Early access

Stop finding out from your clients.

This isn’t a mockup: the engine — record, replay, diff, gate, deploy, rollback — is built, and that core loop runs end to end against a real self-hosted n8n in CI on every pull request. The beta opens to the founding cohort first, at founding prices kept for life.

One email when the beta opens. That's the whole list.