Why n8n and not Zapier or Make
Zapier and Make are solid entry-level tools. They're fast to set up and require no server. But as workflows grow more complex, you hit limits: per-task pricing that scales up when you process high volumes, limited code options when you need something outside a standard node, and little control over where your data goes.
n8n takes a different approach. The visual editor works similarly to Zapier, but you can run your own JavaScript or Python at any point in a workflow. You're not constrained by what the tool vendor has pre-built. And because n8n is open source, you can run it on your own infrastructure: no per-task fees, full data sovereignty and no dependency on external uptime.
The tradeoff of self-hosting is that you manage something extra. That's exactly the deal: more control, a bit more responsibility. I solve that by building the setup so you rarely need to touch it.
Self-hosting vs n8n Cloud: the tradeoff
n8n offers a managed cloud plan. For small teams or if you don't want to manage a VPS, that's a valid choice. But there are situations where self-hosting is clearly better:
- ▸You process personal data or customer data you don't want stored with an external provider (GDPR data sovereignty).
- ▸You have a high volume of executions per month: n8n Cloud charges per workflow execution, self-hosting does not.
- ▸You want queue mode for reliable processing of large batches without timeouts.
- ▸You want to horizontally scale workers as load increases.
- ▸You want credentials stored in your own Vault or encrypted Postgres rather than with a third party.
For teams without devops capacity, n8n Cloud works fine. For anyone with a VPS or existing Hetzner account who runs hundreds of thousands of executions per month or processes sensitive data, self-hosting is cheaper and more secure.
My standard n8n setup
I run self-hosted n8n in production on a Hetzner VPS. The stack I use and roll out for clients:
- ▸Docker Compose with a separate container for the n8n main instance and one or more worker containers for queue processing.
- ▸PostgreSQL as the backend database instead of the default SQLite, so workflow history and credentials are stored reliably.
- ▸Redis as the queue backend for queue mode: workflows are queued and handled by workers, even if the main instance restarts.
- ▸Traefik as reverse proxy with automatic TLS via Let's Encrypt.
- ▸Daily automated backup of the Postgres database to an S3-compatible object store (Hetzner Object Storage or Backblaze B2).
- ▸Webhook security via n8n's built-in basic auth or API-key verification on sensitive endpoints.
The result is a setup that crashes and recovers without losing workflows. Queue mode ensures that an n8n restart or a server reboot doesn't mean lost executions.
What I typically automate with n8n
n8n isn't a replacement for everything, but for a broad category of integration and orchestration problems it's the right tool. Examples from practice:
- ▸Form submissions from a website or Typeform are forwarded directly to a CRM, enriched with company data, and a Slack notification is sent.
- ▸Incoming email attachments are downloaded, processed (PDF extraction, OCR or conversion to CSV) and stored in a shared drive.
- ▸Webhook orchestration: multiple external services send events that n8n merges, deduplicates and processes in the correct order.
- ▸Daily reports: data from multiple sources is fetched, merged and sent as a table or PDF by email.
- ▸Multi-step approval flows where a manager approves an action via email or Slack before a downstream system is updated.
The common thread: n8n excels when multiple tools need to talk to each other and there's logic or conditions involved. Simple one-to-one integrations are possible too, but that might be overkill.
Building custom nodes in TypeScript
The built-in node library covers most common tools. But sometimes you need to integrate an internal system, a niche API, or a service that n8n doesn't support out of the box. That's when I build custom nodes.
A custom node is a TypeScript package that you deploy alongside n8n. The node has a manifest with the fields visible in the editor, and an execute method that handles the actual API call or logic. You publish the node as an npm package or load it via the n8n custom extension directory.
The build process is straightforward: compile TypeScript, create the package structure, optionally publish to a private npm registry. After deployment, the node is immediately available in the editor and behaves like any other node. Credentials are managed through n8n's built-in credential system, so you don't store keys in the node logic itself.
-- Client case
Order processing from manual to fully automated
A logistics service provider processed incoming orders daily via email: a staff member read the attachments, manually entered the data into the WMS and sent a confirmation back. This cost several hours each day and was prone to errors.
After analysis, the solution was straightforward: n8n listens on a dedicated inbox, recognizes order emails via pattern matching, parses the attachment, validates the data and sends it via an internal API to the WMS. On errors or missing fields, a Slack message with the raw data is sent to the responsible team member.
The setup runs on the same self-hosted n8n instance as the client's other workflows. Maintenance is minimal: the WMS schema rarely changes, and when it does, the fix in the node is immediately visible.
What I don't use n8n for
n8n is a capable tool, but it's not the right choice for everything. I don't use n8n for:
- ▸ETL processes where terabytes of data need to move through a pipeline: dedicated tools like dbt, Airbyte or Prefect are better suited.
- ▸Replacing a message queue system like BullMQ, RabbitMQ or Kafka when you're processing hundreds of thousands of messages per minute and need microsecond latency.
- ▸Complex state machines where you need full control over execution stack and retry logic: in those cases I'd rather build a lightweight service in Node.js or Python.
- ▸Workflows so business-critical that even queue mode provides insufficient guarantees: then a proper job orchestration system with SLA monitoring is the better choice.
If your question sits near one of these boundaries, I'll say so directly. I'll look at the right tool with you.
What does an n8n implementation cost?
Scope determines price. A single integration is considerably less work than a full self-hosted setup with queue mode, worker pool and backup strategy. I'll give you an honest proposal after a short call.
Schedule a short call. I'll look at your situation and come back with an honest proposal.