Workflow automation without the per-execution bill
Zapier and Make both bill by execution count, which turns “automate this annoying manual task” into a line item that grows with exactly the thing you automated it to avoid thinking about. n8n does the same job — visual workflows connecting APIs and services without writing glue code — as self-hosted, open-source software, which changes the economics entirely: the cost is the server, not the number of times a workflow fires.
What the template launches
railyard launch n8n --server <id>A verified template: n8n’s own image, an automatically generated N8N_ENCRYPTION_KEY (the key that protects stored credentials — generated once, not left for you to invent), and a persistent volume for workflow and credential data so neither disappears on a redeploy.
The honest tradeoff, stated in the template itself
This is the detail worth knowing before building anything serious on it: the single-container template keeps workflow data and credentials on one volume, which is exactly right for a single user or a small team’s internal automation — simple, nothing extra to manage. For actual production use at real volume, n8n’s own architecture benefits from splitting webhook receiving from workflow execution, which is why a separate queue mode stack template exists specifically for that case rather than trying to make one container do both jobs well. Knowing which one you actually need before committing data to it is cheaper than migrating later.
What it’s actually good for
- Connecting APIs and services without writing and maintaining custom integration code for each one — the same job Zapier/Make do, with the same category of workflow builder.
- Internal operations automation: the unglamorous but constant stream of “when X happens, do Y” that a team accumulates over time and usually either pays per-execution for or never automates at all because the SaaS bill isn’t worth it for a low-volume internal task.
Why the cost model is the actual pitch here, not the features
n8n’s workflow editor is good on its own merits, but the reason to specifically self-host it instead of using a hosted competitor is the same reason that applies everywhere on this platform: a workflow that fires 50,000 times a month costs the same server time as one that fires 50 times. The incentive to under-automate because of a per-execution meter simply isn’t there.
Browse the full catalog: Templates.