Production autopilot for n8n
Your n8n workflows fail quietly.
PulserNode catches them. A control plane for the n8n you already run: versioned changes, watched executions, and bounded repair.
- Execution failedEnrich company returned HTTP 422
- Diagnosedcompany.name moved under company.profile
- Patch proposedset-parameter on one field, inside the allowlist
- Replayed and verifiedAttempt 1 of 3, snapshot not restored
REV 01 / CONTROL PLANE / 2026
Works with the n8n nodes you already use
The workflow worked the day you built it.
Then a schema changed. A token expired. An upstream API started returning null where it used to return a string. n8n kept running, and nothing told you.
It breaks at 3am and succeeds at 4am
One execution errors, the next one passes, and the error never becomes an alert. The rows that never got written are gone until someone goes looking.
The editor tells you what failed, not why
A node turns red. Finding the field whose shape changed means reading raw execution JSON against an API you did not change.
Every fix is a live edit
You patch production directly, because there is no draft. The last known good version is a JSON export somebody took in March.
- 1New lead12ms
- 2Extract details19ms
- 3Enrich company842ms
- 4Qualified?4ms
- 5Notify sales216ms
Find out before your customer does.
Connect the n8n instance you already own. PulserNode watches every execution, keeps the runtime data each node received, and tells you which node changed behaviour.
- Per-node runtime capture
- PulserNode reads what each node actually received, not just the status the editor shows.
- Redacted before it is stored
- Diagnostics are recursively redacted. Credential values and ordinary business payloads never enter the durable model.
- Scoped to your tenant
- Tenant IDs are mandatory in every table, queue job, and audit record, with row-level policies as a second layer.
Guard
Repair with a contract, not a prompt.
Handing a production workflow to a model is only safe if the model cannot do anything you did not allow. Guard runs a bounded loop, and every boundary is enforced in code.
Diagnose
Classify the failure against the runtime data the failing node actually received.
Patch
Emit a structured WorkflowPatch. Only allowlisted operations are accepted, never raw generated code.
Replay
Run the patched workflow against the test input you saved during enrolment.
Verify
Compare the result to the baseline. A pass promotes the patch, a regression restores the snapshot.
Guard will not turn on until all four are true
- A callable test trigger and saved, redacted test input
- Your explicit acknowledgement that every repair is replayed live
- A baseline execution that passes
- A capability probe confirming your n8n exposes the APIs Guard needs
Every change is a version. So is every rollback.
PulserNode holds the canonical draft. Manual edits and AI edits land in the same place, and nothing reaches n8n until you publish it.
See the diff before it ships
Publishing shows exactly which nodes were added, which parameters moved, and what the validation pass found.
- Enrich companyHTTP Request
- Notify salesSlack
- Qualified?Threshold 60 to 70
- Workflow settingsTimeout set to 15s
Immutable versions
Publish creates a version and a deployment record. Neither is ever edited in place.
Rollback moves forward
Rolling back writes a new version rather than rewriting history, so the audit trail stays honest about what ran and when.
One canonical draft
Autosaved, revision-checked, and shared between the canvas, the copilot, and the MCP tools. There is no second source of truth to reconcile.
Your AI client is already the interface.
Point Claude, Cursor, or any Streamable HTTP client at the PulserNode MCP server. Tools call the same API boundary the web app uses, so tenant scoping and Guard policy still apply when the caller is a model.
- Claude
- Claude Code
- Cursor
- Windsurf
Read only
- search_nodes
- get_node
- get_workflow_patterns
- get_best_practices
- list_workflows
- get_workflow
- n8n_validate_workflow
Mutating, annotated as such
- n8n_create_workflow
- n8n_update_workflow
- n8n_execute_and_diagnose
- n8n_heal_workflow
- n8n_watch_workflow
The same five jobs, before and after.
Finding a failure
On n8n alone: Someone reports it, or you notice a gap in the data days later.
With PulserNode: Executions are polled and classified as they happen.
Understanding it
On n8n alone: Read raw execution JSON and compare it against an API you did not change.
With PulserNode: The diagnosis names the node and the field whose shape moved.
Fixing it
On n8n alone: Edit the live workflow and hope the next run is different.
With PulserNode: A patch is replayed against saved test input and verified before it stays.
Shipping a change
On n8n alone: Export JSON, import it, reconnect credentials, repeat.
With PulserNode: Publish creates an immutable version and a deployment record.
Undoing a change
On n8n alone: Find the export you hope you took.
With PulserNode: Roll back to any version, recorded as a new version.