n8n

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the automation I actually need instead of a hosted n8n: the four workflows I really run, as code, with retries and a history I can read.

Read this first: n8n is source-available and self-hosting it is a real answer — the fee buys hosting and hundreds of maintained integrations. The reason to build instead is narrow and honest: most people who pay for a workflow tool are running three or four flows, and three or four flows written directly are less code than the configuration that describes them, faster, and impossible to break by dragging a node.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker process for the queue
- Server-rendered interface; the flow drawn as a list, not a canvas
- Caddy in front

THE DATA MODEL
- flows: id, name, version, definition_json, is_active, created_at
- flow_versions: id, flow_id, version, definition_json, published_at — a run is pinned to a version, so editing never changes a run in flight
- runs: id, flow_id, flow_version, trigger_payload_json, status, started_at, finished_at, error, dedupe_key
- step_runs: id, run_id, step_id, attempt, status, input_json, output_json, error, ms
- connections: id, service, credentials_encrypted, expires_at, refreshed_at
- cursors: id, source, value, updated_at
- queue: id, run_id, step_id, run_at, attempts, locked_by, locked_at, lease_expires_at
- Every step's input and output stored. When a flow does the wrong thing at three in the morning, those payloads are the only thing that answers why

TRIGGERS
- Webhook with a secret and a signature check, answering 200 immediately and queueing
- Schedule with a cron expression and a time zone, with both daylight-saving transitions tested
- Poll a source on an interval with a stored cursor and deduplication by item identifier. A poller that re-emits everything after a restart is the classic disaster in this category
- Manual, with a payload typed by hand, which is how a flow is tested

STEPS
- HTTP request with full control of method, headers, body, timeout, and a declared retry policy
- Branch on a condition, loop over a list with a concurrency limit, delay, and stop with a reason
- Transform: a small expression language over the accumulated run state, or a sandboxed script with a time limit, no filesystem and no ambient network
- Integrations written as small modules with a declared input and output schema. Write the three you need. Three you understand beat thirty you inherited

DATA BETWEEN STEPS
- Reference earlier output by a simple path expression against the run state
- The editor shows real sample data from the last run beside every field, so a path is picked rather than typed. This is the single biggest difference between a usable flow tool and a frustrating one
- Types checked where a step declares them, with the error before the run rather than inside it

RELIABILITY, WHICH IS THE PART THAT DECIDES EVERYTHING
- Retries with exponential backoff and jitter, per step, with a maximum
- Retry only what is safe. A non-idempotent action needs an idempotency key, and the step declares whether it has one — sending an email twice is annoying, charging a card twice is a refund and an apology
- Deduplication on the trigger, so a webhook delivered twice runs once
- The queue is a table with a lease, so a crashed worker's work is resumed rather than lost
- A permanent failure goes to a dead-letter list with everything needed to replay it, and replay is one button
- Rate limits per integration, respected with backoff and the API's own headers honoured

THE INTERFACE
- A flow as a vertical list of steps with branches indented beside them. A node-and-wire canvas is more work to build and less readable for the flows people actually run
- A run view: every step with its input, output, duration and error, expandable
- Runs filterable by status, failures first
- Dark and light

SECRETS
- Connections encrypted at rest with a key from the environment, decrypted only in the worker
- OAuth refresh under a lock, so two workers cannot refresh at once and invalidate each other
- Redacted from every stored payload and every log, by key name and by value match, including encoded forms

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, ENCRYPTION_KEY, SESSION_SECRET, WEBHOOK_SECRET
- Migrations on boot, each once
- Step payloads pruned on a schedule with the retention stated — they are the bulk of the data
- Nightly backup off the machine, restore script
- Health endpoint reporting queue depth, the oldest unlocked item and any expired lease

WHAT MATTERS MOST
Idempotency and the stored payloads. Build the lease queue and the dedupe key first, then kill the worker mid-run and confirm nothing is lost and nothing repeats. An automation tool that occasionally does something twice is a tool you stop trusting with anything that matters — which is every reason you had for building it.

Give me the repository, migrations, .env.example, two seed flows, and a README with deploy steps behind Caddy.