Architecture

1. You own n8n

You install, operate, upgrade, and back up your n8n instance. PulserNode stores its URL and one API key, and talks to it only through n8n's public REST API with that key.

PulserNode does not host an n8n runtime, embed or proxy the n8n editor, log into the editor on your behalf, or broker editor sessions. Anything you do in the editor keeps working exactly as before.

2. What runs on our side

• The web app holds interaction state and never a secret.
• The API is the authorization and transaction boundary. Every request carries your workspace.
• The MCP server turns authenticated tool calls into API calls. It does not bypass any policy the API enforces.
• Workers run builds, live tests, and repairs as durable jobs that survive a closed browser.
• PostgreSQL is the source of truth, with row-level security as a second boundary behind the application checks.

The providers behind these services are listed on the subprocessors page.

3. Your n8n workflow is the authority

Before any change, PulserNode reads the workflow as it exists in your n8n and stores an exact, immutable snapshot. The change is written through the public API, read back, and recorded with before and after snapshots.

Each write carries a fingerprint of the version it was based on. If the workflow changed in n8n since then, the write is rejected with HTTP 409 rather than overwriting someone else's edit.

4. Outbound calls to your instance

Every request to your instance goes through one controlled path. It requires HTTPS, resolves the hostname and checks every address it returns, refuses private and loopback destinations, validates redirects, and times out rather than hanging.

Reading n8n's published documentation uses a second, stricter path that only reaches docs.n8n.io.

5. The Pulser AI boundary

Pulser AI plans from the node catalog your instance publishes, so it builds with nodes you actually have. Its output is parsed into an allowlisted set of patch operations. Raw code, invented node types, and arbitrary API calls are rejected before they reach your instance.

Workflow data, error text, and documentation are treated as untrusted input: delimited and sanitized before a model reads them. Changes that touch credentials, triggers, or remove nodes wait for your approval.

6. Builds and repairs are durable

A build is a stored state machine: plan, build, deploy, live test, repair. You can close the tab and come back; the worker keeps going and the page replays what happened. A build has a 60-minute deadline and at most three repair attempts. A workflow without a testable trigger finishes as untested, never as passed.

Guard repairs of live workflows follow a fixed sequence:

detected -> locked -> diagnosed -> patched -> validated
   -> deployed -> replaying -> succeeded
                    |
                    +-> rolling_back -> failed -> retry (max 3)
                                             \-> circuit_open

Each attempt has an absolute 15-minute deadline, and one repair worker runs per workflow.

7. MCP authentication

MCP clients authenticate with a workspace token that starts with pn_mcp_. It is stored as a SHA-256 hash and can be revoked from Settings at any time.

A client may point one request at a different instance with X-N8n-Url and X-N8n-Key, but only alongside a valid token, and those calls pass through the same outbound controls as a saved connection.

8. Redaction

Credentials and execution payloads are redacted before anything is stored, logged, or sent to a model. Run views show node names, timings, and the error n8n recorded, never the items that flowed through the workflow.