Plain language in. Working n8n automations out.

RunFlowPilot is built for automation builders who already run — or are setting up — an n8n instance: operators connecting business tools, builders shipping client automations, and technical users who prefer describing an outcome over hand-wiring nodes. You do not need to be a developer, but you do need an n8n instance you control, because that is where everything you build lives and runs.

If you are evaluating whether it fits, the documentation walks through setup end to end, and pricing shows the plans, including the 3-day trial with 40 AI credits.

1. Describe. In the Copilot chat you write what should trigger the automation and what it should do, in plain language.
2. Review the plan. The assistant proposes a structured plan — trigger, nodes, connections — which you can question and revise before anything is built.
3. Generate. The plan becomes a visual, editable workflow on a canvas. Every node keeps its type, parameters, and connections visible for inspection.
4. Configure. You fill the fields that only you know — webhook paths, queries, the values behind your systems — and save each node.
5. Deploy inactive, then activate. Deployment creates the workflow on your instance switched off. You attach credentials there and flip it on yourself.

Four distinct stages — confusing them causes most deployment problems:

• AI-generated drafts are proposals, not finished automations. The model assembles nodes from its knowledge; it can be wrong about a parameter or a version, which is why every draft is validated and shown to you before anything leaves the chat.
• Validation checks structure and completeness — supported node types, required parameters, resolvable connections, reachable URLs — in the editor and again server-side as preflight. A green check means the configuration is coherent, not that the automation will succeed in production.
• Your configuration is the part no AI can supply: your webhook paths, your SQL, your field mappings, and your credentials. Required fields are marked, validated on save, and re-checked at deploy time against what you actually persisted.
• Activation in n8n is a deliberate human step, always. Deploys land inactive; only you switch a workflow on, after reviewing it where it will run.

• Show the work. Plans, parameters, validation results, and deployment stages are visible and inspectable — never a black box that reports success on trust.
• Yours to run. Automations execute on your n8n instance under your credentials. The product proposes; you dispose.
• Inactive until you say otherwise. Nothing is published or activated automatically — every deploy lands switched off.
• Specific errors over vague ones. When something fails, the product shows the actual reason, the failing field, and whether anything was created — so the next step is obvious.
• No silent loss. Edits are confirmed saved before they count, interrupted work resumes instead of restarting, and retries link existing work rather than duplicating it.

Your n8n API key is encrypted before storage and never displayed again. Third-party secrets — database passwords, OAuth logins, API tokens — are never asked for, stored, or transmitted by RunFlowPilot at all: they are created and kept inside n8n, and the product only checks whether a required credential type exists on your instance.

Concretely: connection checks run server-side, stored keys are never returned to the browser, deleting an instance offers to remove only the workflows the product deployed, and anything you created manually in n8n is never touched. See configuring credentials for the exact steps.

Questions, feedback, or something broken? Write to info@runflowpilot.com — include what you were doing and the exact error text and you will get a useful answer faster.