Should I vibe code
Use a managed open-source workflow runner instead of operating queues and upgrades
Activepieces is MIT, so don’t build it — run it. Then answer the real question: who gets paged at 4am?
?
Their verdict, the Plus price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
This entry has an unusual answer, because the thing you would be cloning is MIT-licensed and sitting on GitHub. So do not write an automation engine — bring up the real one and you get the run history, the retries, the credential store and hundreds of connectors without designing any of them. That is the correct consolation build and it is honest to say so out loud. What Cloud actually sells is everything left over: a webhook endpoint on someone else’s TLS that answers at 04:00, workers that survive a redeploy, a Postgres you are not responsible for backing up, and a version upgrade that does not take your flows offline while a supplier’s API retries three times and gives up. Self-hosting swaps a coding problem for an operations one. That is a fine trade if you already run infrastructure, and a bad one if this would be the first service you own with a queue in it.
What actually breaks
not "if". the specific failures.
- The webhook endpoint, every time your instance is down or redeploying. Upstream services retry for a few minutes and then drop the event forever, and nothing tells you a trigger never arrived
- The credential store. One instance holds OAuth tokens for every SaaS account your flows touch, and its encryption key is an environment variable on the same host
- Upgrades. Pieces are versioned and flows pin them, so a major bump can change what a step means while the flow keeps running and reporting success
- Disk. Run history is the only thing that can answer “what did it actually send”, and it grows until Postgres stops accepting writes on a Sunday
- The queue. Redis is not optional in this architecture, and a Redis with the wrong eviction policy drops jobs without saying anything
- Retries that are not idempotent — the same duplicate-invoice story as every automation platform, except now the platform is yours to patch at speed
- Nobody else. Cloud has an on-call rotation; you have a phone and a weekend
Your instance runs on one box, because it always has. Friday’s upgrade holds a migration lock slightly too long, the API container restarts twice, and for nineteen minutes the webhook endpoint answers 502. A payment provider tries three times across four minutes and then discards each event, exactly as its documentation says it will. Monday’s reconciliation is eleven orders short and there is no trace of them anywhere in your system, because a webhook that was refused never became a run, and a run that never existed is not in the run history you had been relying on as your audit trail.
Is that you?
the verdict is a default, not a law
- You already run Postgres, Redis and containers in production, with backups you have actually restored from
- The flows are internal glue over systems you own, and a few hours of downtime is an inconvenience rather than an incident
- You are running the real Activepieces rather than something you wrote that resembles it
- Flows are triggered by webhooks from systems whose retry window is measured in minutes
- It holds OAuth tokens for accounts belonging to clients
- The only monitoring is you opening the dashboard when something feels off
- This would be the first thing you have ever operated that has a queue in it
If you build it anyway
the checklist, then the prompt that enforces it
- Do not write the engine. Run the MIT one, or n8n, or Windmill. Whatever you write yourself will be a worse version with no run history.
- Put the webhook ingress in front of the engine — a queue or a tiny always-on receiver that accepts and persists the payload — so a redeploy is a delay rather than a lost trigger.
- Back up Postgres and test the restore before the first production flow, because the run history is your only audit trail.
- Take the encryption key and connection secrets from a secrets manager rather than a .env beside the compose file, and write down how to rotate them.
- Monitor from outside: an uptime check on the webhook host and a heartbeat on at least one scheduled flow, alerting to a phone. Nothing inside the instance can tell you the instance is down.
- Pin piece versions, upgrade a copy first, replay a real payload against it, then upgrade production.
- Set run-history retention deliberately and alert on disk at 70 per cent, not 95.
- Every step that writes into a system you do not own gets an idempotency key and starts disabled.
I am considering replacing a hosted automation platform with something I run. Start by talking me out of writing the engine.
1. First, say this plainly: Activepieces is MIT-licensed and self-hostable, so
the correct build here is a compose file, not a new workflow engine. n8n
and Windmill are the same answer. Only continue past this point if I
explicitly say I want my own runner anyway.
2. If I am self-hosting theirs, the work is operations, so order it that way.
Postgres backups with a tested restore come first, because the run history
is the only record of what my automations actually sent.
3. Set the encryption key and all connection secrets from a secrets manager,
not a .env sitting beside the compose file, and write down the rotation
procedure before the first credential is added.
4. Put the webhook ingress in front of the engine — a queue or a tiny
always-on receiver that accepts and persists the payload — so a redeploy is
a delay instead of a lost trigger. Upstream services retry for minutes and
then give up forever.
5. Add external monitoring before the first production flow: an uptime check
on the webhook host and a heartbeat on one scheduled flow, alerting to a
phone. Nothing inside the instance can tell me the instance is down.
6. Set run-history retention deliberately and alert on disk at 70 per cent.
Postgres refusing writes on a Sunday is how this actually falls over.
7. Pin piece versions. Upgrade a copy, replay a real payload against it, then
upgrade production — a step’s behaviour can change underneath a flow.
8. If I insisted on my own runner: persist the run before executing it, give
every outbound side effect an idempotency key derived from the input, and
build the dead-letter queue and manual resume path before the second
integration.
9. Any step writing to a system I do not own starts disabled and needs an
explicit flag to turn on.
10. Out of scope, and say so rather than faking it: a visual flow builder, a
connector marketplace, multi-tenant projects and SSO.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The first time a flow touches a system you do not own, or the first time you notice you are the only person who could restore the database. Twenty dollars a month rents workers, a webhook endpoint with an uptime target, a managed Postgres and somebody else’s upgrade window — and because it is credit-metered, a runaway loop becomes a bill instead of a suspended API account. The free tier is real, too: if your automations are a handful of daily runs, start there and keep self-hosting in your pocket.
$20/mo is cheaper than your weekend.
Flows export as JSON, so keep them in git and treat the instance as disposable — that much is genuinely good, and it is the strongest argument for running the real project rather than your own. What does not export is the connections: every OAuth grant has to be re-authorised by hand on the other side, and nobody has a list of them until they need one. Keep that list yourself, one line per connection with the account, the scopes and which flows use it. Export the run history before you tear anything down, too; it is the only record of what your automations did.
The product itself: MIT-licensed core with connectors, durable execution and run history, self-hostable from a compose file.
Fair-code workflow engine with error workflows and execution retries already solved, and a large self-hosting community.
Questions
It is open source — why is self-hosting rated this harshly?
Because the verdict is about consequences, not authorship. Running the real engine removes the code risk almost entirely, which is exactly why this entry tells you to do that instead of building one. What remains is operational: your instance is now the thing a supplier’s webhook talks to, the thing holding a dozen OAuth grants, and the thing whose disk fills up. That risk does not care that the code is excellent.
How does this differ from the Make and Zapier entries?
Zapier is where the retry-and-idempotency argument lives, and Make is where the half-applied run does. This one is about the option neither of those has: the product is open source, so the honest advice is to run it rather than clone it, and the interesting question becomes operations — backups, webhook availability, upgrades — rather than whether you can write a workflow engine.
What breaks first on a self-hosted instance?
Disk, usually, followed by a webhook window. Run history is the feature that makes the platform worth having and it is also the thing that grows without limit, so people either turn retention off and lose their audit trail, or leave it on and discover that Postgres has stopped accepting writes. Set the retention window on day one and alert on disk long before it matters.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The canvas is not the product. The queue of half-finished runs you can fix and resume is the product.
Retries are the feature. A loop without them silently drops work; a loop with them sends it twice.
An automation hub is a box holding every API key you own, wired to the internet.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice