How to build your first n8n workflow
n8n has quickly become one of the most popular open-source platforms for workflow automation. A visual editor, over 500 integrations, a free self-hosted edition, and built-in support for AI agents. You can install n8n and build your first workflow in under 30 minutes. But there is a real gap between "got it running on my laptop" and "running reliably for the whole team." That gap is filled with configuration decisions that, if skipped, will eventually break things.
This guide walks you through the entire journey: from picking a server to backups and scaling. We will also build a practical example workflow that receives a webhook, processes the data, and sends a notification to Telegram or Slack. Whether you are just getting started or already running workflows locally and want to move them to a production server, this article has you covered.
What is n8n and why self-host it
n8n is an open-source workflow automation platform built around a visual editor. You connect blocks (called nodes) on a canvas, and each block performs a single action: sending an email, creating a task in a project tracker, calling an API, transforming data. Data flows between nodes in JSON format, and the entire chain is called a workflow.
The n8n library includes over 500 ready-made integrations: Telegram, Slack, Google Sheets, PostgreSQL, OpenAI, and many more. For everything else, there is an HTTP Request node and a Code node that runs arbitrary JavaScript or Python.
The key difference from Zapier and Make.com is that you can deploy n8n on your own server. The Community Edition is completely free. Your data stays with you, and there are no limits on workflows or executions. That is why n8n is the go-to choice for companies that care about data control and predictable infrastructure costs.
Five things you can automate with n8n right away
Before diving into setup, it helps to see what n8n can actually do in practice. Here are five scenarios that most teams start with.
Monitoring and alerts. A monitoring system (Zabbix, Grafana, Uptime Kuma) detects an incident and sends a webhook to n8n. The workflow creates a ticket in Jira, posts a message to the on-call Telegram or Slack channel, and logs the event. Kaspersky used a similar setup to automate incident handling that previously took up to three hours a day.
Lead and request processing. A new form submission lands in n8n via webhook. The data gets written to a CRM, the customer receives a confirmation email, and the sales manager gets a Slack notification. All of this without writing a single line of code.
AI assistants and agents. n8n is heavily investing in AI capabilities. You connect a language model (OpenAI, Anthropic, or a local one through Ollama), add the AI Agent node, and configure the tools the agent can call. If the agent needs access to internal documents, you upload files into n8n and set up a RAG pipeline. Ready-made templates are available for the most common agent scenarios, and a basic setup takes about 15 minutes.
Content pipeline. An RSS feed enters n8n, gets filtered by keywords, then an AI node generates a short summary for each article. The result is posted to a Telegram channel or sent as a daily email digest.
DevOps automation. A commit to a Git repository triggers a workflow: build, run tests, deploy to a server, notify the team about the result. n8n does not replace a full CI/CD pipeline, but for small projects it covers the basics.
What server do you need and how to prepare the environment
Choosing the right server configuration is the first step. Minimum requirements depend on your workload: how many workflows will run concurrently and how many users will access the system.
The recommended OS for production is Ubuntu 22.04 or 24.04 LTS. n8n also runs on other Linux distributions and even on Windows (via npm or Docker Desktop), but for stable production use, Ubuntu with Docker remains the standard choice.
| Scenario | CPU | RAM | SSD | What it can handle |
|---|---|---|---|---|
| Testing and development | 2 cores | 4 GB | 30 GB | n8n + SQLite, a handful of workflows |
| Team of up to 10 | 4 cores | 8 GB | 60 GB | n8n + PostgreSQL + Nginx + HTTPS |
| Production under load | 8 cores | 16 GB | 100 GB | Queue mode: main + workers + Redis + PostgreSQL |
You can skip the manual setup entirely: Serverspace offers a VPS with n8n pre-installed. Docker, the database, and the platform itself are already configured and ready to go. Billing is per-minute, so you only pay for what you actually use.
If you prefer to set things up yourself, prepare the server first: update the system (apt update && apt upgrade), install Docker and Docker Compose, and create a dedicated user with sudo privileges. You will need SSH access and any terminal application (Terminal on macOS/Linux, PowerShell or PuTTY on Windows).
Step-by-step: installing n8n with Docker on a VPS
Docker is the recommended way to deploy n8n in production. Containers provide isolation, straightforward updates, and reproducible configurations. Here is the process, step by step.
Step 1. Connect to your server via SSH and update the system:
apt update && apt upgrade -yStep 2. Install Docker if it is not already present:
curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.shStep 3. Create a project directory:
mkdir ~/n8n-docker && cd ~/n8n-dockerStep 4. Create a .env file with the essential variables (each one is explained in the next section):
N8N_HOST=n8n.example.com N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.com/
N8N_ENCRYPTION_KEY=your_key_from_openssl_rand_hex_32Step 5. Create a docker-compose.yml file. A minimal configuration includes an n8n container and a reverse proxy (Traefik or Nginx). The official n8n repository has ready-made examples for various architectures.
Step 6. Start the containers:
docker compose up -dStep 7. Check the logs and make sure there are no errors:
docker compose logs -f n8nStep 8. Open your server address in a browser and create the first account. This is important: the first registered user automatically gets admin rights. If you delay registration, someone else could claim the admin account.
At this point, installation is complete. The system is running, but several more settings are needed before it is production-ready.
Environment variable checklist: what to configure before going live
Most production issues are not caused by n8n itself but by incomplete configuration. Out of the box, n8n starts with settings meant for local development: an SQLite database, a randomly generated encryption key, and execution history that accumulates without limits. None of that is suitable for a production server. Here is what you need to set up.
| Variable | Purpose | What happens if you skip it |
|---|---|---|
| N8N_ENCRYPTION_KEY | Encrypts stored credentials (API keys, tokens, passwords) | All credentials become unreadable if the container is recreated |
| DB_TYPE=postgresdb | Switches from SQLite to PostgreSQL | SQLite locks under concurrent writes; potential data loss |
| N8N_PROTOCOL=https | Sets the protocol for generated links | Webhooks and URLs will be generated with http |
| WEBHOOK_URL | External address for incoming webhooks | Webhooks from external services will not trigger |
| EXECUTIONS_DATA_PRUNE=true | Automatically cleans up execution history | Database grows without limit; performance degrades |
| N8N_BLOCK_ENV_ACCESS_IN_NODE=true | Blocks Code nodes from reading environment variables | Workflows can access sensitive server data |
| NODES_EXCLUDE | Disables dangerous nodes (ExecuteCommand) | Users can run arbitrary commands on the server |
A closer look at the encryption key. N8N_ENCRYPTION_KEY is the single most critical setting in the entire instance. n8n uses this key to encrypt every stored credential: API tokens, passwords, OAuth data. If the key is lost (for example, the container is recreated without a volume and the key was never set via an environment variable), there is no way to recover the credentials. You will have to recreate every connection from scratch.
Generate a strong key with: openssl rand -hex 32. Store it in a secrets manager (1Password, Bitwarden, HashiCorp Vault) and keep a backup copy in a separate location. If you plan to use queue mode with multiple workers, the key must be identical across all processes.
Security: HTTPS, firewall, and access control
Security configuration is not optional. Without HTTPS, login credentials and workflow data travel in plain text. Without a firewall, port 5678 (n8n's default) is open to anyone on the internet.
The minimum set of measures for production: place a reverse proxy (Nginx or Traefik) in front of n8n and set up a free SSL certificate via Let's Encrypt. Use a firewall to block all ports except 443 (HTTPS) and 22 (SSH). Port 5678 should never be exposed externally. If multiple people use the instance, do not give everyone admin rights. n8n 2.0 introduced custom project roles that let you separate workflow creators from those who publish them.
On Serverspace, the firewall is configured in a few clicks right from the control panel. Just allow inbound traffic on ports 443 and 22 and block everything else. No need to work with iptables manually.
One more security note: in n8n 2.0, Code nodes run inside isolated task runners by default, and the ExecuteCommand node is disabled out of the box. Even if someone writes malicious code in a workflow, it cannot crash the main n8n process or access the server's file system.
Database and backups: what you cannot afford to lose
By default, n8n uses SQLite. That is fine for testing, but in production SQLite becomes a liability: it does not handle concurrent writes, and with several active workflows writing constantly, the database will eventually lock up and workflows will start failing. On top of that, SQLite is not compatible with queue mode. Switch to PostgreSQL before the system goes live.
What to back up: the PostgreSQL database (via pg_dump on a cron schedule), the Docker volume with n8n data (~/.n8n), configuration files (.env, docker-compose.yml), and the encryption key separately. An additional safety net: export workflows to JSON and store them in a Git repository. n8n supports direct Git synchronization (push from one instance, pull to another), which is useful both for backups and for moving workflows between environments (dev, staging, production).
Serverspace provides built-in server snapshots that you can create directly from the control panel. This adds another layer of protection on top of database backups: if something goes seriously wrong, you can roll back the entire server to a working state.
The golden rule: a backup is useless if you have never tested the restore. Once a month, spin up a test server, restore from backup, and verify that workflows launch and credentials decrypt properly. Without this, you do not actually know whether your backups work.
Scaling: when a single server is no longer enough
In the default single-node setup, the editor, workflow execution, and webhook processing all share the same process. As the number of workflows grows or they become CPU-intensive, the editor starts lagging and webhooks are processed with noticeable delays.
The solution is queue mode. In this architecture, responsibilities are split. The main instance handles the editor, API, and task scheduling. It pushes jobs into a Redis queue. Workers (one or more) pick jobs from the queue and execute workflows. Results are stored in PostgreSQL.
To enable queue mode, set EXECUTIONS_MODE=queue on the main instance and on every worker. Redis acts as the message broker; PostgreSQL stores the data (SQLite is not supported in this mode). Adding a worker is as simple as spinning up another container with the n8n worker command and the same environment variables. Recommended concurrency per worker: 5 or more executions.
Switching to queue mode usually means running multiple servers. On Serverspace you can spin up additional VPS instances in minutes and connect them via an isolated private network with up to 1 Gbit/s throughput.
An important caveat: do not share a filesystem between the main instance and workers for binary data storage. This leads to file corruption. If your workflows process attachments or large files, use external storage such as S3 or MinIO.
Common mistakes when taking n8n to production
Running SQLite in production. The most common mistake. Everything works fine until the load increases, and then the database starts locking on concurrent writes. Fix: switch to PostgreSQL before going live, not after the first incident.
No encryption key set. If you do not set N8N_ENCRYPTION_KEY via an environment variable, n8n generates a random key and stores it inside the container. Recreate the container without a volume and the key is gone, along with every stored credential. Fix: set the key explicitly and keep a copy in a secrets manager.
Port 5678 exposed to the internet. Without a reverse proxy, anyone can access the n8n editor or send requests to the API. Fix: block the port with a firewall and use Nginx or Traefik as a proxy with HTTPS.
No execution history pruning. Every workflow run is recorded in the database. Without pruning, the executions table grows to gigabytes within months and queries slow down. Fix: set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=168 (keep 7 days of history).
Updating without testing. n8n ships a new minor version nearly every week. Upgrading without testing can break existing workflows, especially after major releases like n8n 2.0 (task runners, blocked environment variables, the new Save/Publish mechanism). Fix: pin specific Docker image tags (never use :latest) and test updates on a staging server.
Losing the encryption key. If the key is lost permanently, every stored API token, password, and OAuth connection is locked forever. There is no recovery. You will have to recreate all credentials in every workflow manually. Fix: store the key in multiple places (secrets manager plus an encrypted copy in a separate storage location).
Conclusion
The full path from a fresh server to stable production looks like this: a VPS with Ubuntu, Docker Compose, PostgreSQL instead of SQLite, an encryption key set via an environment variable, HTTPS through a reverse proxy, a firewall, and automated backups. For a growing team, the next step is queue mode with Redis and workers, monitoring, and workflow versioning via Git.
n8n 2.0 is moving toward "secure by default": code isolation, separate Save and Publish actions, dangerous nodes disabled out of the box. But responsibility for infrastructure, backups, and updates remains yours.
Get started with a pre-configured n8n server on Serverspace: n8n is already installed, and all that is left is to go through the checklist in this guide and take your automation to production.
FAQ
Can I use n8n instead of Zapier?
Yes, for most use cases. The main difference is that n8n can be self-hosted, so your data never leaves your servers. Zapier is easier to get started with, but it gets expensive as you scale and does not give you control over the infrastructure. n8n also counts entire workflows rather than individual actions, which makes it more cost-effective for complex automations.
Do I need to know how to code to use n8n?
No. n8n is designed for no-code use. Workflows are built visually by dragging and connecting nodes on a canvas. Code (JavaScript or Python) is only needed for advanced scenarios, and even then basic knowledge is enough. The majority of n8n users are not developers.
How much does self-hosted n8n cost?
The Community Edition is entirely free, including AI nodes and unlimited workflows. The only expense is server rental. A VPS suitable for a small team costs just a few dollars a month.
