Should I vibe code
Workflow automation platform with self-hosted and cloud options
An automation hub is a box holding every API key you own, wired to the internet.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Self-hosting the real thing is sensible. Building your own means storing long-lived credentials for a dozen services in something you have not threat-modelled, and running it unattended forever.
What actually breaks
not "if". the specific failures.
- One host holding long-lived credentials for a dozen services, so a single compromise is a dozen compromises
- The web UI, exposed to the internet so you can edit a workflow from a laptop, now an authenticated attack surface you maintain
- Nodes that execute arbitrary code, which is the point of the tool and also a remote code execution primitive if the UI is reachable
- Encryption keys stored next to the encrypted credentials, which is the default nobody revisits
- Unattended operation forever, so a dependency's security advisory is only read if you happen to see it
The instance has been running quietly for fourteen months, which is exactly why nobody has looked at it. It is on a subdomain, behind a login you set up once, running a version with a published advisory from eight months ago. Inside it are working credentials for your email, your cloud storage, your CRM, your payment processor and your source control. Nothing about this is a workflow-automation incident. It is a credentials incident, and the automation host is simply where they all happened to be kept together.
Is that you?
the verdict is a default, not a law
- It runs on your own machine or a private network, with no public ingress
- The credentials in it are read-only and individually low-value
- You self-host the real n8n rather than writing your own
- The editor UI is reachable from the public internet
- It holds credentials that can move money, send mail as you, or deploy code
- There is no process that updates it and reads its advisories
- You could not enumerate, right now, which services it can act on
If you build it anyway
the checklist, then the prompt that enforces it
- No public ingress. Bind to localhost and reach it over a VPN or SSH tunnel. This one decision removes most of the risk in this entry.
- Scope every credential to the minimum it needs, and prefer short-lived tokens over long-lived keys wherever the service offers them.
- Keep the encryption key out of the host — environment or a secret manager — so a stolen disk is not a stolen credential set.
- Write down every service the instance can act on, and review that list on a schedule. The blast radius is the list.
- Subscribe to the upstream security advisories and set a recurring calendar reminder to patch. Unattended is the risk.
- Self-host upstream n8n rather than writing your own. The workflow engine is not the hard part; the credential handling is, and theirs has been reviewed.
Before you write or deploy a workflow automation host, apply these and push back if I ask you to break them. 1. Ask me why I am not self-hosting n8n itself, which is open source and has had its credential handling reviewed by more people than mine will be. If I have no specific reason, tell me to do that. 2. Do not expose the editor or admin UI to the public internet. Bind to localhost and tell me to reach it over a VPN or an SSH tunnel. If I insist on public access, refuse until there is SSO or mTLS in front of it, and explain that this service executes arbitrary code by design. 3. Enumerate, in the README, every external service this instance holds credentials for. Tell me this list is the blast radius of one compromise. 4. Store the credential encryption key outside the host filesystem — environment variable or secret manager — never in a file beside the encrypted data. 5. Use the narrowest scope available for every credential, and short-lived tokens over long-lived API keys wherever the provider supports it. Ask me to justify any credential that can write. 6. Any node that runs arbitrary code is disabled unless I explicitly enable it, and enabling it prints a warning explaining what it means. 7. Log every workflow execution with the credentials it used, so an incident has an audit trail. 8. Set up automatic dependency updates and tell me to subscribe to upstream security advisories. State plainly that this thing will run untouched for a year and that is the actual threat. 9. Out of scope unless I ask: multi-user access, sharing, public webhooks without authentication.
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
$24 a month, or self-host the real thing for the cost of a small VPS. Either beats writing your own, because what you would be writing is a credential store with a workflow engine attached, and the credential store is the part with the consequences.
$24/mo is cheaper than your weekend.
Keep workflows exported as JSON in version control, and keep an inventory of every credential the instance holds so you can rotate the whole set in one pass. If you retire the host, rotating is the exit — deleting the machine does not invalidate the keys that were on it.
The product's open-source workflow automation core.
Questions
Self-hosting n8n is rated fine but building my own is YOUR FUNERAL. Why the gap?
Because the difficulty is not the workflow engine, it is everything around the credentials: encryption at rest, key separation, scoping, rotation, audit. Upstream has already been through that with many eyes on it. Your version has the same blast radius and none of the review.
Is keeping it off the public internet really sufficient?
It is not sufficient, but it is the single highest-value control here, because it turns a remotely exploitable service that executes arbitrary code into one an attacker must already be inside your network to reach. Do that first, then scope credentials and patch on a schedule.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice