n8n Hosting

Who should self-host n8n on a rented server?

Self-hosting n8n makes sense for teams and developers who want to run workflow automation without paying per execution and keep their data on their own server. n8n connects CRM, email, spreadsheets, payments, messaging and AI services through visual nodes. The cloud edition needs no installation; the version you run on your own server gives you full control over the infrastructure.

Self-hosted n8n stands out when you have:

• Heavy automation: for workflows triggered many times a day, a fixed server cost beats execution-based pricing.
• Data control requirements: customer data, internal system credentials and API keys must live on your server, not a third-party cloud.
• Internal network access: workflows that connect to an on-premises database or internal services are easier to build on a server in the same network or connected by VPN.
• Custom nodes: you want to install community nodes or nodes you develop yourself.

For users who do not want to manage a server and run only a few workflows, n8n’s own cloud service may be simpler. Self-hosting hands you responsibility for updates and backups; this page explains how to carry that responsibility easily.

Self-hosted n8n is also popular with agencies and freelance automation specialists: running a separate n8n instance on a separate VPS for each client isolates client data and simplifies billing. In that scenario, review the licence terms as described in the licence section below.

Which workflows can you automate with n8n?

With n8n you can automate almost any process where an event must trigger an action in another system: a form submission, a payment notification, a new order, a calendar event or a set time starts a workflow, which then transforms the data and passes it to other services. n8n on your own server runs these workflows continuously without worrying about execution counts.

Common examples in businesses:

• Sales and CRM: saving a contact-form enquiry from your website to the CRM and notifying the sales team in a messaging app.
• E-commerce: updating the stock sheet on a new order, creating a shipment through the courier’s API and emailing the customer.
• Bookkeeping prep: collecting payment notifications from your payment provider into a daily sheet and moving it to a folder shared with your accountant.
• Internal operations: distributing account-creation tasks to the right teams when a new employee joins, and managing approval flows.
• AI-assisted workflows: classifying incoming emails with a language model service and routing them to the right team.
• Monitoring: checking a website or API regularly and sending an alert on failure.

What these workflows share is that other services reach n8n through webhooks, or n8n polls them on a schedule; both need an always-on server with a fixed address.

Why choose a VPS for n8n?

n8n needs a VPS because it is a continuously running Node.js application that requires persistent processes, Docker and port management, none of which shared hosting provides. Shared hosting is designed for PHP websites; it cannot reliably run a long-lived background service, scheduled triggers and a webhook listener.

LIONFIN VPS plans use KVM virtualisation. Because KVM gives each virtual server its own kernel, Docker runs without issues; on some container-based virtualisation technologies Docker installation can be restricted. In addition:

• Full root access: you configure the operating system, Docker, the reverse proxy and the firewall yourself.
• NVMe storage: n8n writes each execution’s data to the database; disk speed shows when listing past executions and as the database grows.
• Static IP: your webhook URL and APIs that use IP allow lists need a fixed address.
• Scalability: as your workflow count grows you can add resources without reinstalling the server.

A current Ubuntu LTS release is a good starting operating system, as it matches most Docker documentation and community guides.

How much RAM and CPU does n8n need?

The resources n8n needs depend on the number of workflows running at once, the size of the data they process and the database you use. The official n8n documentation focuses on installation methods rather than fixed hardware requirements, so the table above is an approximate guide to match against current package values.

The main factors in resource use:

• Data volume: workflows that process a sheet of thousands of rows in one go or convert large files fill memory quickly. Processing large data in batches (with loop and pagination nodes) reduces memory needs.
• Concurrency: workflows that receive many webhook calls at once increase CPU load.
• Execution history: data from every execution is stored. If execution data pruning is off, the database and disk keep growing.
• Code nodes: heavy computation in JavaScript or Python code nodes uses extra CPU.
• Side services: if PostgreSQL, Redis and the reverse proxy run on the same VPS, add their share.

The best approach is to start small and watch real usage with docker stats and htop. When memory runs short you can upgrade your plan from the customer panel.

How do you install n8n on a server with Docker?

The recommended way to install n8n on a server is Docker Compose: a single configuration file defines n8n, the database and the persistent data folder together. Install Docker Engine and the Compose plugin first if they are not on the server yet.

A simple starting configuration (docker-compose.yml):

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=${WEBHOOK_URL}
      - GENERIC_TIMEZONE=Europe/London
      - TZ=Europe/London
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
volumes:
  n8n_data:

Put the WEBHOOK_URL and N8N_ENCRYPTION_KEY values in an .env file in the same folder: the webhook URL is your domain’s full address starting with https and ending with /; the encryption key is a long random value generated with a command such as openssl rand -hex 32. Then start the service with docker compose up -d. Three things to watch:

• The port is published only on 127.0.0.1; outside access goes through the reverse proxy.
• The /home/node/.n8n folder must live on a persistent volume; the encryption key and configuration are stored there.
• GENERIC_TIMEZONE makes scheduled triggers run in your own time zone; set it to yours (for example Europe/Istanbul for Türkiye).

Check the official n8n documentation for environment variables that may change between versions.

Should n8n use SQLite or PostgreSQL?

The default SQLite is enough for personal use and a few workflows; choose PostgreSQL for team use, heavy execution loads or if you might move to queue mode later. According to the official n8n documentation the supported databases are SQLite and PostgreSQL; MySQL and MariaDB support was removed in version 1.0.

With PostgreSQL you give n8n DB_TYPE=postgresdb plus the DB_POSTGRESDB_* variables holding the connection details. Adding PostgreSQL to the same Compose file and keeping it reachable only on the internal Docker network is the easiest way to avoid exposing the database port to the internet. Whatever database you choose, keep the .n8n folder persistent; n8n stores the encryption key and some configuration files there.

How do you set up a domain, SSL and webhooks for n8n?

To publish n8n on your domain with SSL you use a reverse proxy such as Nginx, Caddy or Traefik; the proxy accepts HTTPS on port 443 and forwards requests to n8n on local port 5678. This setup is essential for webhook nodes to be callable from outside.

1. DNS record: create an A record for a subdomain such as n8n.yourdomain.com pointing to the server IP.
2. Reverse proxy: with Nginx, define a server block that forwards requests to 127.0.0.1:5678 using the proxy_pass directive. Because the n8n interface uses WebSocket, the Upgrade and Connection headers must be passed through.
3. SSL certificate: get a free certificate from Let’s Encrypt; Caddy does this automatically, and Certbot is used with Nginx.
4. Webhook URL: set the WEBHOOK_URL variable to your HTTPS domain. Otherwise n8n shows an address in webhook nodes that cannot be reached from outside.

Most payment providers and SaaS services require a valid HTTPS certificate for webhooks.

How do you secure an n8n server?

You secure an n8n server by closing port 5678 to the internet, allowing access only over HTTPS, using a strong owner account with two-factor authentication and restricting SSH to key-based login. n8n stores credentials for every service it connects to; compromising it means compromising all of them.

• The Docker and firewall trap: ports published by Docker add iptables rules that bypass UFW. If you write ports: "5678:5678", the port may be reachable from outside even though UFW shows it as closed. Bind the port to the local address only, as 127.0.0.1:5678:5678.
• Firewall: open only 22 (or your changed SSH port), 80 and 443 in UFW.
• SSH: use keys instead of passwords and add Fail2ban against brute-force attempts.
• Owner account: give the owner account created at first setup a strong password and enable the two-factor authentication n8n supports.
• Encryption key: store the N8N_ENCRYPTION_KEY value somewhere safe; if you lose it, saved credentials cannot be decrypted.

On the infrastructure side, the LIONFIN network filters DDoS traffic at network level with the RouteFence firewall; configuration inside the server is your responsibility.

How do you back up n8n workflows and credentials?

An n8n backup has three parts: the database (workflows, credentials, execution history), the .n8n data folder (including the encryption key) and your Compose and environment configuration. If any of the three is missing, a restore will be incomplete; in particular, credentials in a backup are useless without the encryption key.

Recommended routine:

1. Database backup: for PostgreSQL, take a nightly backup with pg_dump; for SQLite, stop n8n briefly and copy the database file.
2. Workflow export: the n8n CLI can export workflows as JSON: docker compose exec n8n n8n export:workflow --all --output=/home/node/.n8n/backup/. Keeping these files in a Git repository lets you track workflow changes as versions.
3. Configuration: store docker-compose.yml and .env in an encrypted location.
4. Off-server copy: move backups to other storage with a scheduled cron job.

For a full server-level copy, take a VPS snapshot. A snapshot is also ideal as a quick rollback point before a major n8n version upgrade.

How do you update and scale n8n?

n8n installed with Docker is updated by pulling the new image and recreating the container; when load grows it scales out to several workers in queue mode. Update often, because new releases bring both security fixes and new nodes.

Safe update flow:

1. Read the release notes for breaking changes; n8n publishes migration guides for major versions.
2. Take a database backup or a server snapshot.
3. Pull the new image with docker compose pull and recreate the container with docker compose up -d.
4. Trigger your critical workflows manually to confirm they work.

In production, pinning the image to a specific version tag instead of latest prevents surprise updates.

For scaling, in queue mode the main n8n process handles incoming requests and triggers while executions are distributed to separate worker processes through a Redis queue. This mode requires PostgreSQL and Redis. A single process is enough for most small and medium workloads; moving to queue mode only makes sense once executions start piling up and lagging. When vertical growth on one server is not enough, you can move to a bigger plan or a VDS server with dedicated resources.

What does the n8n licence allow for self-hosted use?

n8n is source-available and distributed under the “fair-code” Sustainable Use License, which lets you use n8n free of charge on your own server for your own internal business processes. The Community Edition runs self-hosted within this framework.

Distinctions to know:

• Internal use: your own company’s automation, workflows processing your own customer data and personal projects are generally covered by the licence.
• Commercial resale: offering n8n to others as a hosted service or selling it as part of your product may run into licence restrictions; in that case look at n8n’s commercial licence options.
• Enterprise features: some features such as advanced user management, SSO or environment management may require a paid licence.

Licence terms can change over time, so compare your use case with n8n’s current licence text. LIONFIN does not sell n8n licences; renting a server gives you the infrastructure, and the software licence terms are between you and n8n.

What are the most common n8n server problems?

The most common problems are a wrong webhook URL, time zone errors, a disk filled by a growing database and execution failures caused by insufficient memory.

The webhook URL shows localhost

If the WEBHOOK_URL variable is not set, n8n does not know it sits behind a reverse proxy and generates an address that cannot be called from outside. Set the variable to your HTTPS domain and recreate the container.

A scheduled workflow runs at the wrong time

Check that GENERIC_TIMEZONE and TZ match your time zone and that no different time zone is selected in the workflow settings.

The disk is full

If execution history is not pruned, the database keeps growing. Enable execution data pruning, consider saving only failed executions and clean up unused images with docker system df and Docker’s prune commands.

A workflow stops with “out of memory”

Large data is being processed in one go. Split the data into batches and consider settings that write binary data to disk instead of memory; add memory if needed. On Linux, a swap file helps as a temporary measure, but the lasting fix is enough RAM.