n8n (pronounced “en-eight-en”) is a workflow automation platform that connects SaaS products and APIs to run repeatable operations automatically. It’s easy to start with a no-code, node-based editor, but it also supports webhooks, HTTP calls, and code execution—so you can treat it as a lightweight integration layer that holds up in real operations.
This guide is conclusion-first: what n8n is best at, how to choose between n8n Cloud vs self-hosting, and the most common production pitfalls (webhook URLs, persistence, and security).
n8n is a node-based automation tool where you build workflows as a clear sequence: trigger (start condition) → processing (transform, branch, call APIs) → action (notify, create, update). You connect nodes with lines, which keeps complex automations readable. Compared to “SaaS connector-only” tools, n8n is more flexible because you can receive external events via webhooks and call virtually any API via raw HTTP requests. Key takeaway n8n’s Webhook node is a trigger node: when an external system sends an HTTP request to the webhook URL, n8n starts the workflow and makes the request data available inside it. The Webhook node supports standard HTTP methods, which lets you treat it like a simple API endpoint when needed. The Webhook node works as a trigger. When the webhook URL is called, the data becomes available to your workflow (and it supports standard HTTP methods).
n8n Overview
n8n isn’t just “automation.” It handles HTTP, webhooks, and credentials, which means it can function as a lightweight integration platform. That’s powerful—but if you expose it publicly, you need a real security plan.What You Can Do with n8n
Common use cases
Trigger workflows from external systems via webhooks
The HTTP Request node lets you call arbitrary REST APIs to fetch, create, or update data. This is one of n8n’s biggest advantages: even if there’s no official integration node for a service, you can still integrate it as long as it has an API. Note For self-hosting, Docker is usually the quickest path. n8n’s official docs also recommend Docker for many self-hosted use cases and show a setup that persists data by mounting
Connect to any API over HTTP
n8n Cloud vs Self-Hosting: What’s Different
Dimension
n8n Cloud
Self-hosted
Initial setup
Fast (create an account and start)
You need Docker/DB/SSL and basic infrastructure setup
Operations
Low operational overhead
You own updates, monitoring, and backups
Security & governance
Depends on vendor-managed controls
You can design network controls and authentication to fit your environment
Cost model
Typically tied to plan limits (for example, executions)
Server costs + operational time (the best option depends on scale)
Cloud pricing and execution limits can change as plans evolve. For any purchasing decision, confirm the latest details on the official n8n website.Fastest Way to Get Started
Start n8n with Docker
n8n_data to /home/node/.n8n.
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
Persistence comes first
Mount a Docker volume (or host directory) from day one so /home/node/.n8n persists across restarts. This directory is where critical state lives (database, encryption-related material, and configuration). A common failure pattern is “temporary test run” silently becoming production—then data disappears when the container is recreated.
Set the correct public webhook URL
If you run n8n behind a reverse proxy, n8n can’t always infer the externally reachable webhook URL correctly. In that case, you need to explicitly set the public webhook base URL. The official docs describe WEBHOOK_URL as the variable you use to manually set webhook URLs when running behind a reverse proxy, so n8n displays and registers the right URLs.
# docker-compose example (excerpt)
services:
n8n:
image: docker.n8n.io/n8nio/n8n
ports:
- "5678:5678"
environment:
- N8N_PROTOCOL=https
- N8N_HOST=example.com
- WEBHOOK_URL=https://example.com/
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:Operational Gotchas
Webhook collisions
In n8n, you can’t register multiple webhooks with the same “path + HTTP method” combination. If you reuse a path and method across workflows (or even within the same workflow), registration fails. This limitation is explicitly called out in n8n’s troubleshooting notes.
Minimum security baseline
If you self-host n8n and expose webhooks to the public internet, treat it like any other internet-facing integration service. At minimum, cover these three areas:
- Restrict access to the admin UI (VPN, allowlisted IP ranges, or strong authentication in front of it)
- Add authentication to webhooks (header-based secrets, signature verification, etc.)
- Update regularly to keep up with known vulnerabilities
n8n’s documentation also provides an operational security overview (for example, account and instance hardening guidance) under “Securing n8n.”
Warning
Webhooks are convenient—but they also expand your attack surface. If you publish them, think in bundles: reachability controls (WAF/reverse proxy), authentication, and logging/monitoring should ship together.
Webhook authentication: which approach to choose
The right webhook auth depends on your integration partner and threat model. For simple internal integrations, a fixed secret in a custom header can be enough. If the external SaaS provides request signing (for example, HMAC-based signatures), prioritize signature verification—it’s usually safer than static secrets alone. n8n documents webhook-related credential/authentication options as well.
FAQ
Is n8n free?
If you self-host, the software itself can be used (you still pay infrastructure costs). n8n Cloud is managed hosting, so it requires a paid plan.
Can you use n8n for web scraping?
n8n is an automation platform, so you can build a workflow like “fetch a page over HTTP → extract/transform data → store it.” That said, web scraping needs careful design around the target site’s terms, rate limits, bot detection, and legal/compliance risk. High-frequency access and attempts to bypass access controls are especially risky.
Where should I start?
Pick one trigger and build something small: either “receive data via webhook” or “run on a schedule.” After that works, add the operational pieces—retry behavior, failure notifications, and execution logging—so your automation doesn’t break silently.
Summary
- n8n automates operations by combining SaaS integrations with HTTP/API building blocks
- For self-hosting, start with Docker and persistence; design webhook URL generation with environment variables
- If you publish webhooks, assume “authentication + reachability control + updates” are non-negotiable
References
