Activepieces

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 an automation runner that replaces a hosted Activepieces: triggers, actions, a flow I can read, and a run history that tells me exactly what happened.

Read this first: the product you are replacing is open source, so the honest options are to self-host it or to build the narrow thing you actually need. Choose the second only when your flows are few and specific — then this is a fortnight, and it is yours forever.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Workers in the same process at first, moved out when they need to be
- Server-rendered interface, the flow drawn as SVG
- Caddy in front

THE DATA MODEL
- flows: id, name, version, is_active, trigger_json, steps_json, created_at
- flow_versions: id, flow_id, version, definition_json, published_at — a running flow 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, started_at, finished_at, ms
- connections: id, name, kind, credentials_encrypted, expires_at, refreshed_at
- schedules: id, flow_id, cron, timezone, next_at, last_at
- queue: id, run_id, step_id, run_at, attempts, locked_by, locked_at
- Every step's input and output stored. When a flow does the wrong thing at three in the morning, the payload at each step is the only thing that answers why

TRIGGERS
- Webhook: a URL per flow, with an optional shared secret and signature check, answering 200 immediately and queueing the run
- Schedule: a cron expression with a time zone, with the daylight-saving cases decided and tested
- Polling: fetch a source on an interval and emit one run per new item, with the cursor stored and deduplication by an item identifier — polling that re-emits everything after a restart is the classic disaster
- Manual, with a payload typed by hand, which is how a flow is tested

ACTIONS
- HTTP request with full control of method, headers, body, timeout and retry
- Branch on a condition, loop over a list with a concurrency limit, delay, and stop with a message
- Code: a small JavaScript step run in a sandbox with a timeout, no filesystem and no network unless declared
- A handful of real integrations, each written as a piece with a declared schema for its inputs and outputs. Build the three you need, not thirty you do not

DATA BETWEEN STEPS
- Reference earlier output with a simple path expression, resolved against the run's accumulated 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 builder and a frustrating one
- Types checked where the piece declares them, with a clear error before the run rather than a crash inside it

RELIABILITY, WHICH IS THE PART PEOPLE UNDERESTIMATE
- Every step retried with exponential backoff and jitter, with a per-step policy and a maximum
- Retry only what is safe: a non-idempotent action needs an idempotency key, and the piece declares whether it has one
- Deduplication on the trigger, so the same webhook delivered twice runs once
- A run that fails permanently goes to a dead-letter list with everything needed to replay it, and replay is one button
- The queue is a table with a locked_by and a lease, so a crashed worker's work is picked up rather than lost

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

SECRETS
- Connections encrypted at rest with a key from the environment, decrypted only in the worker
- OAuth refresh handled with a lock so two workers never refresh at once and invalidate each other
- Secrets redacted from every stored payload and every log, by key name and by value match

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

WHAT MATTERS MOST
Retries, deduplication and the stored step payloads. Build the queue with leases and the dedupe key before any integration, then kill the process mid-run and confirm nothing is lost and nothing is duplicated. An automation tool that occasionally sends an email twice is a tool you stop trusting with anything that matters.

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