Category: n8n

  • n8n Free: Self-Host Workflow Automation with Docker

    n8n Free: How to Self-Host the Open-Source Automation Tool with Docker

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’ve been comparing Zapier, Make, and other automation platforms, you’ve probably noticed the pricing adds up fast once your workflow volume grows. That’s why so many developers and sysadmins are switching to n8n free — the open-source, node-based automation tool that you can self-host without per-execution fees.

    This guide walks through exactly how to get n8n running for free on your own infrastructure using Docker, how it compares to the paid n8n Cloud plans, and how to harden it for production use.

    What Is n8n and Why Is It Free?

    n8n (pronounced “n-eight-n”) is a fair-code workflow automation tool. Unlike Zapier, its core is licensed under the Sustainable Use License, which means you can self-host it for free — including for internal business use — as long as you don’t resell it as a competing service.

    That’s the key distinction developers care about: n8n free isn’t a crippled trial. When you self-host, you get:

  • Unlimited workflow executions (no per-task billing)
  • Full access to 400+ integration nodes
  • Custom JavaScript/Python code nodes
  • Webhook triggers, cron scheduling, and error workflows
  • Complete data ownership — nothing leaves your server
  • The only thing you give up compared to n8n Cloud is managed hosting, automatic updates, and official SLA-backed support. For most technical teams, that trade-off is easily worth it.

    n8n Free (Self-Hosted) vs n8n Cloud

    | Feature | Self-Hosted (Free) | n8n Cloud (Paid) |
    |—|—|—|
    | Cost | $0 (server costs only) | Starts ~$20/month |
    | Execution limits | Unlimited | Plan-based caps |
    | Data residency | Your server | n8n’s infrastructure |
    | Maintenance | You manage updates | Fully managed |
    | Custom nodes | Yes | Limited |
    | SSO/enterprise features | Requires Enterprise license | Available on higher tiers |

    If you’re comfortable running a VPS, self-hosting is almost always the better economic choice long-term.

    Prerequisites

    Before you start, make sure you have:

  • A Linux VPS (Ubuntu 22.04+ recommended) with at least 1 GB RAM
  • Docker and Docker Compose installed
  • A domain name (optional but recommended for HTTPS)
  • Basic familiarity with the command line
  • If you don’t already have a server, providers like DigitalOcean offer droplets that are more than capable of running n8n comfortably, even on their cheapest tier. We cover general VPS hardening in our Linux server security checklist if you want to lock things down further.

    Installing Docker and Docker Compose

    If Docker isn’t installed yet, run:

    curl -fsSL https://get.docker.com -o get-docker.sh
    sudo sh get-docker.sh
    sudo usermod -aG docker $USER
    newgrp docker

    Verify the install:

    docker --version
    docker compose version

    Running n8n with Docker Compose

    Create a project directory and a docker-compose.yml file:

    mkdir ~/n8n-stack && cd ~/n8n-stack
    nano docker-compose.yml

    Paste in the following configuration:

    version: "3.8"
    
    services:
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          - N8N_HOST=n8n.yourdomain.com
          - N8N_PORT=5678
          - N8N_PROTOCOL=https
          - NODE_ENV=production
          - WEBHOOK_URL=https://n8n.yourdomain.com/
          - GENERIC_TIMEZONE=America/New_York
        volumes:
          - n8n_data:/home/node/.n8n
    
    volumes:
      n8n_data:

    Start the stack:

    docker compose up -d

    Check the logs to confirm it started cleanly:

    docker compose logs -f n8n

    At this point n8n is running on port 5678. You can access it directly via http://your-server-ip:5678, but for anything beyond local testing, you’ll want a reverse proxy with HTTPS — running automation workflows with credentials over plain HTTP is a bad idea.

    Adding HTTPS with Caddy

    The simplest way to get free, auto-renewing HTTPS is Caddy. Add it to your compose file:

      caddy:
        image: caddy:2
        restart: unless-stopped
        ports:
          - "80:80"
          - "443:443"
        volumes:
          - ./Caddyfile:/etc/caddy/Caddyfile
          - caddy_data:/data
    
    volumes:
      caddy_data:

    Create a Caddyfile:

    n8n.yourdomain.com {
        reverse_proxy n8n:5678
    }

    Point your domain’s A record at your server IP, then restart the stack:

    docker compose up -d

    Caddy will automatically request and renew a Let’s Encrypt certificate. If you’re using Cloudflare for DNS, you also get free DDoS protection and can proxy traffic through their network for an extra layer of security.

    Securing Your Free n8n Instance

    Running n8n free doesn’t mean cutting corners on security. A few essentials:

  • Enable basic auth or SSO — set N8N_BASIC_AUTH_ACTIVE=true with N8N_BASIC_AUTH_USER and N8N_BASIC_AUTH_PASSWORD environment variables at minimum.
  • Restrict the firewall — only allow ports 80, 443, and SSH; block direct access to 5678 from outside.
  • Back up the n8n_data volume regularly — this contains your workflows, credentials, and execution history.
  • Keep the image updated — pull the latest tag periodically to get security patches.
  • Use environment variables for secrets — never hardcode API keys inside workflow nodes.
  • For firewall rules, ufw makes this simple:

    sudo ufw allow OpenSSH
    sudo ufw allow 80/tcp
    sudo ufw allow 443/tcp
    sudo ufw deny 5678/tcp
    sudo ufw enable

    If uptime matters for your automations (e.g., triggering alerts or syncing data), it’s worth pairing your instance with an uptime monitor. BetterStack offers free-tier uptime checks and status pages that can ping your n8n webhook health endpoint and alert you the moment it goes down.

    Building Your First Free Workflow

    Once you’re logged in, try a simple test workflow:

    1. Add a Webhook trigger node — this gives you a unique URL n8n listens on.
    2. Connect it to an HTTP Request node to call any public API (e.g., a weather API).
    3. Add a Set node to reshape the response data.
    4. Send the result somewhere — Slack, email, or a Google Sheet.

    Here’s what a minimal workflow JSON export looks like, which you can import directly:

    {
      "nodes": [
        {
          "parameters": {
            "path": "weather-hook",
            "httpMethod": "GET"
          },
          "name": "Webhook",
          "type": "n8n-nodes-base.webhook",
          "typeVersion": 1,
          "position": [250, 300]
        }
      ],
      "connections": {}
    }

    This pattern — webhook in, transform, action out — covers the majority of real-world automation needs: syncing CRM data, monitoring alerts, posting to Slack, or scraping and reformatting content. It’s the same building block whether you’re running the free self-hosted version or paying for n8n Cloud.

    If you’re already running other self-hosted tools, check our guide on setting up Docker Compose stacks for home labs for patterns on organizing multiple services alongside n8n.

    Common Pitfalls with Self-Hosted n8n

  • Forgetting persistent volumes — without a named volume, restarting the container wipes all workflows.
  • Not setting WEBHOOK_URL — webhooks silently fail to register correctly behind a reverse proxy without this.
  • Running as root — the official image already drops privileges; don’t override the user in custom Dockerfiles unless necessary.
  • Ignoring execution data growth — by default n8n keeps all execution logs, which can bloat your database over time. Configure EXECUTIONS_DATA_PRUNE=true to auto-clean old records.
  • Skipping backups — export your workflows periodically with the CLI or API, not just relying on the volume snapshot.
  • Scaling Beyond a Single Server

    For low-to-moderate workflow volume, a single Docker container backed by SQLite (the default) is fine. If you start running hundreds of concurrent executions, switch to PostgreSQL and consider n8n’s queue mode with Redis, which lets you run multiple worker containers in parallel. This is still entirely free under the self-hosted license — you’re only paying for the extra compute.

    A typical scaled setup adds:

      postgres:
        image: postgres:15
        restart: unless-stopped
        environment:
          - POSTGRES_USER=n8n
          - POSTGRES_PASSWORD=changeme
          - POSTGRES_DB=n8n
        volumes:
          - postgres_data:/var/lib/postgresql/data

    Then point n8n at it with DB_TYPE=postgresdb and the corresponding connection environment variables.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Is n8n really free to self-host?
    Yes. The core n8n platform is licensed under the Sustainable Use License, allowing free self-hosting for internal use, including commercial businesses automating their own operations. You only pay for the server it runs on.

    What’s the catch with the free version?
    There isn’t a feature catch — you get the same nodes and capabilities as paid plans. The trade-offs are that you manage your own updates, backups, and uptime, and certain enterprise features (SSO, advanced permissions, dedicated support) require a paid Enterprise license.

    Can I use n8n free for client work or a SaaS product?
    You can use it internally to automate your own business processes, but reselling n8n itself as a hosted service to third parties violates the license. Read the Sustainable Use License terms before commercial redistribution.

    How much server power do I need?
    A 1 GB RAM / 1 vCPU VPS handles light-to-moderate workflow volume fine. Heavier usage with many concurrent executions benefits from 2 GB+ RAM and a PostgreSQL backend instead of SQLite.

    Does self-hosted n8n support webhooks and scheduling?
    Yes, both are fully supported in the free self-hosted version, including cron-based triggers and webhook-based triggers, identical to the cloud offering.

    How do I back up my n8n workflows?
    Export workflows via the UI, use the n8n CLI (n8n export:workflow --all), or snapshot the Docker volume where .n8n data is stored. Automating this with a cron job is recommended for production instances.

    Wrapping Up

    Running n8n free via Docker gives you enterprise-grade automation capability without recurring per-task fees. Between the Docker Compose setup, Caddy for HTTPS, and a few security hardening steps, you can have a production-ready automation server running in under thirty minutes. From there, the only real cost is your VPS — and a small droplet is enough to run dozens of active workflows comfortably.

    If you found this useful, check out our related guide on self-hosting monitoring stacks with Docker to pair uptime alerts with your new automation server.

  • n8n API Guide: Automate Workflows via REST & Docker

    The Complete Guide to the n8n API

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’re running n8n for workflow automation, sooner or later you’ll outgrow the visual editor. That’s where the n8n API comes in — it lets you create, update, trigger, and manage workflows programmatically, without touching the UI. This guide walks through everything you need to start using the n8n API in a real production setup, from authentication to Docker deployment.

    n8n (short for “nodemation”) is an open-source, node-based workflow automation tool similar to Zapier or Make, but self-hostable and far more flexible for developers. Its REST API exposes nearly every capability available in the editor — workflows, credentials, executions, tags, and users — making it possible to build automation pipelines that manage themselves.

    What Is the n8n API?

    The n8n API is a REST interface built into every n8n instance (both cloud and self-hosted). It allows external systems to interact with your n8n instance programmatically: creating workflows from templates, activating or deactivating them, pulling execution logs, or triggering runs via webhook.

    For DevOps teams, this is the difference between manually clicking around a UI and treating your automation layer as infrastructure-as-code. You can version-control workflow JSON, deploy it via CI/CD, and monitor executions the same way you’d monitor any other service.

    REST API vs Webhook Triggers

    n8n actually exposes two distinct ways to interact programmatically:

  • The REST API (/api/v1/...) — used for managing workflows, credentials, executions, and other administrative tasks. Requires an API key.
  • Webhook nodes — used to trigger a specific workflow’s execution from an external event (like a GitHub push or a form submission). No API key required unless you configure webhook authentication.
  • They solve different problems. The REST API is for managing the automation platform itself; webhooks are for feeding data into a specific workflow. Most production setups use both — REST API calls for deployment/CI, and webhooks for the actual event-driven automation.

    Setting Up n8n for API Access

    Before you can call the API, you need a running n8n instance with API access enabled. The cleanest way to do this — and the way most self-hosters run n8n in production — is via Docker.

    Self-Hosting n8n with Docker

    Here’s a minimal docker-compose.yml that gets n8n running with persistent storage:

    version: "3.8"
    
    services:
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          - N8N_HOST=n8n.yourdomain.com
          - N8N_PORT=5678
          - N8N_PROTOCOL=https
          - NODE_ENV=production
          - WEBHOOK_URL=https://n8n.yourdomain.com/
          - GENERIC_TIMEZONE=UTC
        volumes:
          - n8n_data:/home/node/.n8n
    
    volumes:
      n8n_data:

    Bring it up with:

    docker compose up -d

    If you’re new to running multi-container stacks, our Docker Compose fundamentals guide covers the basics of services, volumes, and networking used here.

    For production, don’t expose port 5678 directly to the internet — put n8n behind a reverse proxy (Nginx or Caddy) with TLS termination, or use a tunnel service. A small VPS is more than enough to run this; providers like DigitalOcean and Hetzner offer cheap droplets/instances that handle n8n comfortably at low traffic volumes.

    Generating an API Key

    Once n8n is running, generate an API key from the UI:

    1. Log in to your n8n instance.
    2. Go to Settings → API.
    3. Click Create an API Key.
    4. Copy the key — it’s shown only once.

    You’ll pass this key in every request as the X-N8N-API-KEY header. Store it in a secrets manager or environment variable — never hardcode it in scripts committed to version control.

    export N8N_API_KEY="your-api-key-here"
    export N8N_HOST="https://n8n.yourdomain.com"

    Working with the n8n REST API

    With the API key in hand, you can start scripting against the instance. All endpoints live under /api/v1/. The full reference is in the official n8n API documentation, but here are the endpoints you’ll use most.

    Creating and Managing Workflows via API

    List all existing workflows:

    curl -s -X GET "$N8N_HOST/api/v1/workflows" 
      -H "X-N8N-API-KEY: $N8N_API_KEY" 
      -H "Content-Type: application/json" | jq

    Create a new workflow from a JSON definition:

    curl -s -X POST "$N8N_HOST/api/v1/workflows" 
      -H "X-N8N-API-KEY: $N8N_API_KEY" 
      -H "Content-Type: application/json" 
      -d '{
        "name": "Daily Report Sync",
        "nodes": [],
        "connections": {},
        "settings": {}
      }'

    Activate a workflow by ID:

    curl -s -X POST "$N8N_HOST/api/v1/workflows/123/activate" 
      -H "X-N8N-API-KEY: $N8N_API_KEY"

    This pattern — export workflow JSON from a dev instance, commit it to git, and POST it to production via CI — is how most teams keep n8n workflows in sync across environments without manual UI edits.

    Triggering Workflows Programmatically

    To actually run a workflow from external code, you generally use a Webhook node inside the workflow rather than the REST API directly. Set up a Webhook trigger node, then call it like a normal HTTP endpoint:

    curl -s -X POST "$N8N_HOST/webhook/daily-report" 
      -H "Content-Type: application/json" 
      -d '{"report_date": "2026-07-05"}'

    If you need to trigger an execution without a webhook (for example, testing), you can also use the executions endpoint on a manually-triggered workflow:

    curl -s -X POST "$N8N_HOST/api/v1/workflows/123/execute" 
      -H "X-N8N-API-KEY: $N8N_API_KEY"

    Note: this endpoint’s availability depends on your n8n version — check the API reference for your specific release, since the execution API has changed across versions.

    Authentication and Security Best Practices

    The n8n API is powerful, which means a leaked key is a serious risk — anyone with it can read credentials metadata, modify workflows, or exfiltrate data. A few rules worth following:

  • Rotate API keys periodically, and immediately if you suspect a leak.
  • Never expose the n8n management UI or API directly to the public internet — put it behind a VPN, IP allowlist, or a proxy like Cloudflare Access.
  • Use separate API keys per integration/service so you can revoke one without breaking everything.
  • Enable basic auth or an additional reverse-proxy auth layer for the /rest and /api paths, in addition to the n8n API key.
  • Store API keys in a secrets manager (Vault, Doppler, or even Docker secrets) instead of .env files checked into git.
  • For teams running n8n as critical infrastructure — say, powering internal billing or customer notification workflows — treat the API key with the same care as a database password.

    Deploying n8n in Production

    A Docker Compose setup on a single VPS works fine for low-to-medium workloads, but if you’re running dozens of active workflows with high execution volume, consider:

  • Queue mode: n8n supports a Redis-backed queue mode that separates the webhook-receiving process from the execution workers, letting you scale workers independently.
  • External Postgres: swap the default SQLite database for Postgres to avoid write-lock contention under load.
  • Reverse proxy + TLS: terminate SSL with Caddy or Nginx, and consider Cloudflare in front of your VPS for DDoS protection and easy TLS certificate management.
  • Our production Docker deployment checklist covers volume backups, restart policies, and log rotation you’ll want in place before relying on n8n for anything business-critical.

    Monitoring and Scaling n8n

    Once workflows run unattended, you need visibility into failures. n8n emits execution data you can pull via the API (/api/v1/executions), but for real alerting, pair it with an uptime/monitoring service. BetterStack is a solid option for uptime checks on your n8n webhook endpoints and log aggregation for the underlying container, so you get paged the moment a critical automation silently stops firing.

    A simple health check loop:

    curl -s -X GET "$N8N_HOST/api/v1/executions?status=error&limit=10" 
      -H "X-N8N-API-KEY: $N8N_API_KEY" | jq '.data | length'

    Run this on a cron schedule and alert if the error count spikes — it’s a cheap way to catch broken integrations before they cause downstream failures.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Do I need a paid n8n plan to use the API?
    No. The REST API is available on self-hosted (community edition, free) instances as well as n8n Cloud plans. Rate limits and some enterprise features (like advanced user management endpoints) differ between tiers, but core workflow/execution endpoints work on the free self-hosted version.

    What’s the difference between the API key and OAuth credentials stored inside workflows?
    The API key authenticates your scripts to the n8n instance itself. OAuth/credential entries inside workflows authenticate n8n to third-party services (Slack, Google, etc.) when a workflow runs. They’re unrelated and serve different purposes.

    Can I import an entire workflow JSON file via the API?
    Yes. POST the workflow’s JSON export to /api/v1/workflows, matching the schema n8n uses when you export via the UI (Download option). This is the standard way to move workflows between dev and production instances.

    Is there a rate limit on the n8n API?
    Self-hosted instances don’t impose an artificial rate limit by default, but your server’s resources are the practical limit. n8n Cloud plans do enforce request limits depending on your subscription tier.

    How do I test webhook-triggered workflows without exposing my server publicly?
    Use a tunnel tool like ngrok or Cloudflare Tunnel during development, then switch to your real domain once the workflow is verified and deployed to production.

    Can the n8n API create credentials programmatically?
    Yes, the /api/v1/credentials endpoint lets you create and manage credential entries, though sensitive fields (like OAuth tokens) still typically require a manual authorization step through the UI for security reasons.

    Wrapping Up

    The n8n API turns your automation platform from a UI-driven tool into something you can manage as code: version-controlled workflows, scripted deployments, and monitored executions. Start with a Docker-based self-hosted instance, generate an API key, and script the basics — listing, creating, and activating workflows — before moving into queue mode and production hardening. Once that’s in place, n8n stops being “another tool you click around in” and becomes a real piece of your infrastructure.

  • n8n Automation: Self-Host a Workflow Engine on a VPS

    n8n Automation: How to Self-Host a Workflow Engine on Your Own VPS

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’ve spent any time evaluating workflow automation tools, you’ve probably run into n8n. It’s a fair-code, node-based automation platform that lets you connect APIs, databases, and internal services without writing a full application for every integration. Unlike Zapier or Make, n8n automation runs entirely on infrastructure you control, which matters if you care about data residency, API rate limits, or just not paying per-execution fees forever.

    This guide walks through installing n8n automation on a Linux VPS with Docker, securing it behind a reverse proxy, wiring up your first workflow, and keeping the instance monitored and backed up. It’s written for developers and sysadmins who are comfortable with a terminal and want a production-ready setup, not a five-minute demo that falls over the first time a webhook gets hit twice.

    If you don’t already have a server, DigitalOcean droplets are a solid, cheap starting point for n8n automation workloads — a $6/month droplet handles light-to-moderate workflow volume without issue. For workflows that need to survive real traffic and cron-triggered jobs around the clock, Hetzner also offers excellent price-to-performance ratios on their cloud instances.

    What n8n Automation Actually Solves

    Most teams reach for n8n automation when they have three or more systems that need to talk to each other and none of them share a native integration. Think: a form submission in Typeform that needs to create a CRM record, notify a Slack channel, and append a row to a spreadsheet. You could write a small serverless function for each hop, or you could build one n8n workflow with three nodes and a trigger.

    The advantages over hosted-only tools like Zapier are concrete:

  • No per-execution billing — once it’s running, workflows cost you server resources, not a monthly execution cap.
  • Full data control — sensitive payloads never leave your infrastructure.
  • Custom code nodes — you can drop in raw JavaScript or Python when a built-in node doesn’t cover your case.
  • Self-hosted webhooks — no third-party proxy sitting between your systems.
  • Version control friendly — workflows can be exported as JSON and tracked in git.
  • If you’re already running other containerized services, pairing n8n automation with your existing Docker Compose stack is usually the path of least resistance.

    Installing n8n Automation with Docker Compose

    The official n8n documentation recommends Docker for anything beyond a local test, and that’s the approach we’ll use here. First, create a working directory and a docker-compose.yml:

    mkdir -p ~/n8n-stack/data
    cd ~/n8n-stack

    # docker-compose.yml
    version: "3.8"
    
    services:
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "127.0.0.1:5678:5678"
        environment:
          - N8N_HOST=n8n.yourdomain.com
          - N8N_PROTOCOL=https
          - N8N_PORT=5678
          - WEBHOOK_URL=https://n8n.yourdomain.com/
          - GENERIC_TIMEZONE=America/New_York
          - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
          - DB_TYPE=postgresdb
          - DB_POSTGRESDB_HOST=postgres
          - DB_POSTGRESDB_DATABASE=n8n
          - DB_POSTGRESDB_USER=n8n
          - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
        volumes:
          - ./data:/home/node/.n8n
        depends_on:
          - postgres
    
      postgres:
        image: postgres:16-alpine
        restart: unless-stopped
        environment:
          - POSTGRES_DB=n8n
          - POSTGRES_USER=n8n
          - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
        volumes:
          - ./pgdata:/var/lib/postgresql/data

    Create a .env file next to it with strong random values:

    echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 24)" >> .env
    echo "POSTGRES_PASSWORD=$(openssl rand -hex 16)" >> .env

    Bind it to 127.0.0.1 on the host as shown above — you don’t want n8n exposed directly on the public interface before it’s behind TLS. Bring the stack up:

    docker compose up -d
    docker compose logs -f n8n

    Using Postgres instead of the default SQLite file matters once you have more than a handful of workflows — SQLite will work for testing, but concurrent webhook executions against a file-based database are a common source of “database is locked” errors in n8n automation setups that grow past a toy project.

    Building Your First n8n Automation Workflow

    Once the container is up, n8n automation is reachable on port 5678 (we’ll put it behind a domain in the next section). Log in, and you’ll land on a blank canvas. A minimal but genuinely useful first workflow looks like this:

    1. Webhook node — set as the trigger, generates a unique URL n8n listens on.
    2. HTTP Request node — call an external API (weather, exchange rates, your own backend) using the payload from the webhook.
    3. IF node — branch logic based on the response, e.g., route differently if a status field equals "error".
    4. Slack or Email node — send a formatted notification on either branch.

    Each node’s output is inspectable in the UI, which makes debugging far faster than tailing logs from a hand-rolled script. You can also drop in a Code node for anything the built-in nodes can’t express:

    // Code node example: normalize incoming payload keys to snake_case
    const items = $input.all();
    
    return items.map(item => {
      const normalized = {};
      for (const [key, value] of Object.entries(item.json)) {
        const snakeKey = key.replace(/([A-Z])/g, "_$1").toLowerCase();
        normalized[snakeKey] = value;
      }
      return { json: normalized };
    });

    Save the workflow, toggle it Active, and the webhook URL becomes permanently listening — no manual re-trigger needed. This is where n8n automation earns its keep: workflows that used to be a cron job plus a Python script plus a systemd unit become one visual, exportable definition.

    Securing n8n Automation Behind Nginx and SSL

    Running n8n on a bare port with no TLS is a non-starter for anything beyond localhost testing, since workflows frequently handle API keys and webhook secrets. Install Nginx and Certbot on the host:

    sudo apt update
    sudo apt install -y nginx certbot python3-certbot-nginx

    Create a server block:

    # /etc/nginx/sites-available/n8n.conf
    server {
        listen 80;
        server_name n8n.yourdomain.com;
    
        location / {
            proxy_pass http://127.0.0.1:5678;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    sudo ln -s /etc/nginx/sites-available/n8n.conf /etc/nginx/sites-enabled/
    sudo nginx -t && sudo systemctl reload nginx
    sudo certbot --nginx -d n8n.yourdomain.com

    Certbot and Let’s Encrypt handle certificate issuance and renewal automatically once set up — verify the renewal timer is active with systemctl list-timers | grep certbot. If you followed our Nginx reverse proxy and SSL guide for other services on the same box, this configuration will look familiar; the pattern is identical.

    Don’t stop at TLS. n8n automation instances are frequently targeted by credential-stuffing bots once discovered, since a compromised instance can pivot into every connected service. At minimum:

  • Set N8N_BASIC_AUTH_ACTIVE=true with a strong username/password pair as an extra layer in front of the app-level login.
  • Restrict SSH and the Postgres port with ufw so nothing but Nginx faces the internet.
  • Rotate the N8N_ENCRYPTION_KEY only during a planned migration — rotating it without re-encrypting stored credentials will break every saved connection.
  • Monitoring and Backing Up n8n Automation

    A workflow engine that silently stops running webhooks is worse than one that never existed, because nobody notices until a downstream process fails days later. Add an uptime check against a lightweight health endpoint:

    curl -s -o /dev/null -w "%{http_code}" https://n8n.yourdomain.com/healthz

    Wire that check into BetterStack (or any uptime monitor) so you get paged the moment the container dies or Nginx starts returning 502s. For workflows that run on a schedule rather than a webhook, also monitor execution history inside n8n itself — the built-in Executions tab shows failures, and you can add an Error Trigger node to route failures to a dedicated Slack channel automatically.

    Backups are non-negotiable once workflows are doing real work. Two things need to be saved: the Postgres database (workflow definitions, credentials, execution history) and the .n8n data directory (encryption key, local files). A simple nightly cron job:

    #!/usr/bin/env bash
    # /usr/local/bin/n8n-backup.sh
    set -euo pipefail
    
    BACKUP_DIR=/root/backups/n8n
    TIMESTAMP=$(date +%Y%m%d_%H%M%S)
    mkdir -p "$BACKUP_DIR"
    
    docker exec n8n-stack-postgres-1 pg_dump -U n8n n8n | gzip > "$BACKUP_DIR/n8n_db_${TIMESTAMP}.sql.gz"
    tar czf "$BACKUP_DIR/n8n_data_${TIMESTAMP}.tar.gz" -C ~/n8n-stack data
    
    find "$BACKUP_DIR" -type f -mtime +14 -delete

    chmod +x /usr/local/bin/n8n-backup.sh
    (crontab -l 2>/dev/null; echo "0 3 * * * /usr/local/bin/n8n-backup.sh") | crontab -

    Ship the resulting archives off-box — an S3-compatible bucket or a second small VPS is enough. A backup that lives on the same disk as the service it protects isn’t really a backup.

    Scaling n8n Automation for Production

    A single-container setup handles most small-to-medium workloads fine, but if you’re running hundreds of active workflows or high-frequency webhooks, n8n supports a queue mode that separates the editor UI from execution workers using Redis. In queue mode, incoming webhook triggers get pushed onto a Redis queue and picked up by one or more worker containers, which means you can scale execution capacity horizontally without touching the main instance. This is also the point where it’s worth revisiting your VPS sizing — workers are CPU and memory hungry under load, and undersizing here is the most common cause of stalled queues.

    If you’re integrating n8n automation with dozens of external APIs, also keep an eye on outbound rate limits. n8n doesn’t rate-limit HTTP Request nodes by default, so a bug in a loop or a misconfigured retry can burn through an API quota in minutes. Add explicit Wait nodes or batch processing for any integration with a published rate limit.


    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Is n8n automation free to self-host?
    Yes. n8n is released under a fair-code license (Sustainable Use License), which means you can self-host and use it commercially for free. You only pay if you use n8n’s own cloud hosting or need enterprise features like SSO and advanced permissions.

    How much VPS resource does n8n automation need?
    For light use — a handful of workflows firing a few times an hour — 1 vCPU and 1GB RAM is enough. Once you add Postgres and expect webhook bursts, 2 vCPUs and 4GB RAM is a safer baseline.

    Can n8n automation replace Zapier entirely?
    For most use cases, yes, especially anything involving webhooks, custom code, or high execution volume. The main gap is the breadth of pre-built app integrations — Zapier’s app catalog is larger, though n8n’s HTTP Request node covers any API with documented endpoints.

    Is n8n automation secure enough for handling API credentials?
    Credentials stored in n8n are encrypted at rest using the N8N_ENCRYPTION_KEY. Security in practice depends on how you deploy it — TLS, basic auth, and restricted network access (as covered above) are what actually keep it safe, not the encryption alone.

    How do I move n8n automation workflows between servers?
    Export workflows as JSON from the UI (or via the CLI with n8n export:workflow) and import them on the target instance. Credentials aren’t included in exports by default for security reasons, so you’ll need to recreate those manually on the new instance.

    Does n8n automation support webhooks that need to respond immediately?
    Yes — set the Webhook node’s response mode to “Immediately” if the caller needs a fast acknowledgment, then continue processing asynchronously in the rest of the workflow. This is essential for integrations with strict timeout limits, like many payment webhooks.

  • n8n YouTube Automation: Self-Hosted Workflow Guide

    N8N YouTube Automation: Building Self-Hosted Video Workflows with Docker

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’re managing a YouTube channel alongside a streaming or cord-cutting content business, you already know the manual overhead: uploading videos, writing metadata, cross-posting to socials, and tracking analytics. n8n YouTube automation lets you replace that manual grind with self-hosted, version-controlled workflows that you fully own — no per-task pricing, no vendor lock-in.

    This guide walks through deploying n8n via Docker, connecting it to the YouTube Data API, and building real workflows: auto-publishing metadata, sending upload alerts to Slack/Discord, and archiving video stats for reporting.

    Why n8n for YouTube Automation

    n8n is an open-source, node-based workflow automation tool — think Zapier or Make, but self-hostable and free of per-execution billing once you run your own instance. For teams already managing Docker infrastructure, n8n slots in as just another container in your stack.

    Compared to closed SaaS automation platforms, self-hosted n8n gives you:

  • Full control over data — video metadata, API keys, and analytics never leave your infrastructure
  • No execution caps or surprise billing tiers
  • Native support for custom JavaScript/Python code nodes for edge cases
  • Direct integration with the YouTube Data API v3 via HTTP Request nodes or the built-in YouTube node
  • Easy chaining into other tools — Slack, Discord, Notion, Google Sheets, S3-compatible storage
  • The tradeoff is that you’re responsible for hosting, updates, and security — which is exactly the kind of operational work this site normally covers for streaming infrastructure, so it’s a natural fit.

    Prerequisites

    Before you start, you’ll need:

  • A VPS or dedicated server with Docker and Docker Compose installed
  • A domain or subdomain (e.g., n8n.yourdomain.com) with DNS pointed at your server
  • A Google Cloud project with the YouTube Data API v3 enabled and OAuth2 credentials generated
  • Basic familiarity with docker-compose and reverse proxies
  • If you haven’t set up a production-ready VPS yet, our guide to hardening a Linux VPS covers firewall rules and SSH lockdown before you expose any web service.

    Deploying n8n with Docker Compose

    The fastest reliable path to a persistent, production-usable n8n instance is Docker Compose with a Postgres backend (SQLite works for testing but isn’t recommended once you have real workflows running).

    version: "3.8"
    
    services:
      postgres:
        image: postgres:16-alpine
        restart: unless-stopped
        environment:
          POSTGRES_USER: n8n
          POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
          POSTGRES_DB: n8n
        volumes:
          - postgres_data:/var/lib/postgresql/data
    
      n8n:
        image: docker.n8n.io/n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          - N8N_HOST=n8n.yourdomain.com
          - N8N_PROTOCOL=https
          - N8N_PORT=5678
          - DB_TYPE=postgresdb
          - DB_POSTGRESDB_HOST=postgres
          - DB_POSTGRESDB_USER=n8n
          - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
          - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
          - GENERIC_TIMEZONE=America/New_York
        volumes:
          - n8n_data:/home/node/.n8n
        depends_on:
          - postgres
    
    volumes:
      postgres_data:
      n8n_data:

    Save your secrets in a .env file rather than hardcoding them:

    echo "POSTGRES_PASSWORD=$(openssl rand -hex 16)" >> .env
    echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 24)" >> .env

    Bring the stack up:

    docker compose up -d
    docker compose logs -f n8n

    Put Nginx or Caddy in front of it for TLS termination. A minimal Caddy config:

    n8n.yourdomain.com {
        reverse_proxy localhost:5678
    }

    Once it’s live, visit https://n8n.yourdomain.com, create your owner account, and you’re ready to build workflows.

    Connecting n8n to the YouTube Data API

    YouTube automation in n8n runs through Google’s OAuth2 credential flow:

    1. In Google Cloud Console, enable the YouTube Data API v3 for your project.
    2. Create an OAuth 2.0 Client ID (Web application type), and add https://n8n.yourdomain.com/rest/oauth2-credential/callback as an authorized redirect URI.
    3. In n8n, go to Credentials → New → YouTube OAuth2 API, paste in your Client ID and Secret, and complete the consent screen flow.
    4. Test the connection with a simple YouTube node action, like listing your channel’s recent uploads.

    Once authenticated, n8n can read and write almost anything the API exposes: video metadata, playlist items, comments, captions, and channel analytics (via the separate YouTube Analytics API, which you can call through an HTTP Request node using the same OAuth2 credential).

    Building a Practical Workflow: Auto-Publish and Alert

    A common first workflow: when a new video finishes uploading (or a scheduled trigger fires), update its metadata from a template and post a notification to Discord.

    Trigger: Schedule node (e.g., every 15 minutes) or a Webhook node if you’re pushing events from an external upload script.

    Step 1 — Fetch the video:

    {
      "node": "YouTube",
      "operation": "get",
      "resource": "video",
      "videoId": "={{ $json.videoId }}"
    }

    Step 2 — Update metadata via HTTP Request node (useful when you need fields the built-in node doesn’t expose):

    curl -X PUT 
      "https://www.googleapis.com/youtube/v3/videos?part=snippet" 
      -H "Authorization: Bearer $ACCESS_TOKEN" 
      -H "Content-Type: application/json" 
      -d '{
        "id": "'"$VIDEO_ID"'",
        "snippet": {
          "title": "'"$TITLE"'",
          "description": "'"$DESCRIPTION"'",
          "categoryId": "28"
        }
      }'

    In n8n, this becomes an HTTP Request node with the OAuth2 credential attached and the body built from expressions referencing your Google Sheet or database row (title, description, tags pulled dynamically per video).

    Step 3 — Notify your team:

    {
      "node": "Discord",
      "webhookUrl": "={{ $env.DISCORD_WEBHOOK }}",
      "content": "✅ Published: {{ $json.snippet.title }} — https://youtu.be/{{ $json.id }}"
    }

    Chain a Google Sheets or Postgres node afterward to log the publish event for reporting.

    Advanced Automation Ideas

    Once the basic pipeline works, extend it:

  • Pull daily view/watch-time stats via the YouTube Analytics API and store them in Postgres for a self-hosted dashboard
  • Auto-generate SEO-friendly descriptions using an LLM node, then require manual approval via a Slack interactive message before publishing
  • Trigger a workflow on new comments containing specific keywords (e.g., support requests) and route them to a ticketing system
  • Cross-post new uploads automatically to Twitter/X and Mastodon using their respective HTTP APIs
  • Archive final video renders to S3-compatible object storage as a backup step before deleting local files
  • Each of these is a small, composable workflow — the strength of n8n is chaining these together rather than building one monolithic automation.

    Securing and Scaling Your n8n Instance

    Because n8n holds OAuth tokens and API keys for your YouTube channel, treat it like any other production secret store:

  • Enable n8n’s built-in basic auth or SSO if you’re not already behind a VPN
  • Keep the container updated — subscribe to n8n’s release notes and patch regularly
  • Back up the Postgres volume on a schedule; workflow definitions and credentials live there
  • Use BetterStack or a similar uptime/log monitoring service to alert you if the container crashes or the API quota gets exhausted
  • If you’re running this on a budget VPS, DigitalOcean droplets and Hetzner cloud instances both handle an n8n + Postgres stack comfortably on their smallest tiers
  • For teams pushing this into real production use — multiple workflows, webhook triggers from external services, higher execution volume — consider a queue-mode n8n deployment with Redis, which decouples the webhook listener from the worker processes and scales horizontally.

      redis:
        image: redis:7-alpine
        restart: unless-stopped

    Add EXECUTIONS_MODE=queue and QUEUE_BULL_REDIS_HOST=redis to your n8n environment variables to enable this mode once you outgrow a single-instance setup.

    A Note on YouTube API Quotas

    The YouTube Data API enforces a default daily quota of 10,000 units, and different operations cost different amounts — a videos.update call costs 50 units, while a simple videos.list costs 1. Design your workflows to batch reads where possible and avoid polling on tight schedules; a 15-minute schedule trigger checking a single playlist is cheap, but looping through hundreds of videos on every run will burn through your quota fast. You can request a quota increase from Google Cloud Console if your automation genuinely needs it, but most single-channel workflows never come close to the default limit.

    If you’re scaling this system alongside other DevOps tooling, it’s worth reading our guide to monitoring self-hosted services to keep tabs on container health, API error rates, and disk usage on the same VPS.

    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Is n8n free to use for YouTube automation?
    Yes — n8n is fair-code licensed and free to self-host with no execution limits. You only pay for the server it runs on. n8n also offers a paid cloud version if you’d rather not manage infrastructure yourself.

    Do I need coding experience to use n8n for YouTube workflows?
    No. Most workflows are built visually by connecting nodes. Code nodes (JavaScript/Python) are optional and only needed for custom logic beyond what built-in nodes support.

    Can n8n actually upload videos to YouTube, or just manage metadata?
    n8n can perform full uploads via the YouTube Data API’s videos.insert endpoint using an HTTP Request node with multipart upload, though most users automate metadata, scheduling, and post-publish tasks rather than the upload itself, since large file uploads are often handled by dedicated encoding pipelines.

    What happens if my YouTube API quota runs out?
    Requests will fail with a 403 quota-exceeded error until the daily quota resets (midnight Pacific Time). Design workflows to fail gracefully and alert you rather than retrying aggressively, which can worsen the problem.

    Is self-hosted n8n secure enough for storing YouTube OAuth credentials?
    Yes, provided you follow basic hardening: keep it behind TLS, enable authentication, restrict network access, and keep the container patched. n8n encrypts stored credentials at rest using the encryption key you configure.

    Can I run n8n alongside my existing Docker services on the same VPS?
    Yes. n8n is lightweight and runs fine alongside other containers as long as you allocate enough RAM for Postgres and give it its own subdomain and reverse proxy block.

    Wrapping Up

    Self-hosted n8n turns YouTube channel management from a checklist of manual steps into a set of reliable, auditable workflows you control end to end. Start with one simple automation — metadata updates or publish alerts — before layering in analytics archiving and cross-posting. The Docker Compose setup above gets you a production-capable instance in under fifteen minutes, and from there it’s just a matter of wiring nodes together.

  • n8n Cloud Pricing 2026: Plans, Costs & Alternatives

    n8n Cloud Pricing in 2026: What You’ll Actually Pay (and When to Self-Host Instead)

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’ve started building workflow automations and landed on n8n, you’ve probably hit the same wall everyone does: the pricing page tells you a starting number, but not what you’ll actually pay once your workflows scale. Execution-based pricing sounds simple until you have a dozen workflows firing on webhooks, cron schedules, and API polling loops all at once.

    This guide breaks down n8n cloud pricing tier by tier, flags the costs that catch people off guard, and walks through the math on self-hosting n8n on your own infrastructure instead — including a working Docker Compose setup you can deploy today.

    What n8n Actually Is (Quick Context)

    n8n is an open-source workflow automation tool — think Zapier or Make, but self-hostable and node-based, with the ability to write custom JavaScript directly inside workflow steps. It connects APIs, databases, webhooks, and internal services without requiring you to write a full integration layer from scratch.

    Because the core project is fair-code licensed and available as a Docker image, you have two real paths to running it:

  • n8n Cloud — a managed SaaS offering, billed monthly, scaled by workflow executions.
  • Self-hosted n8n — you run the container yourself on a VPS, paying only for the server.
  • Both are legitimate choices depending on your team size, technical comfort, and how many executions you’re actually running per month.

    n8n Cloud Plan Breakdown

    n8n Cloud pricing is structured around three main variables: number of active workflows, execution volume, and feature access (things like environments, SSO, and advanced permissions). The tiers roughly break down like this:

  • Starter — entry-level tier aimed at solo builders and small teams. Includes a capped monthly execution allowance (commonly a few thousand executions/month), a limited number of active workflows, and community support only.
  • Pro — the tier most small businesses land on. Higher execution caps, more active workflows, shared team workspaces, and priority support.
  • Enterprise — custom pricing, negotiated directly with n8n’s sales team. Includes SSO/SAML, audit logs, dedicated infrastructure options, and SLA-backed uptime guarantees.
  • Exact dollar figures shift periodically as n8n adjusts its packaging, so always check the official n8n pricing page before budgeting — don’t rely on screenshots or third-party recaps, including this one, for the current number.

    What matters more than the sticker price is understanding what counts as an execution, because that’s where budgets quietly blow up.

    Hidden Costs to Watch For

    The advertised monthly price is rarely the full story. Here’s what actually drives your bill up over time:

  • Execution counting — every workflow run counts as an execution, even failed ones and ones triggered by a single webhook ping. A workflow that polls an API every minute burns through your allowance fast — that’s 1,440 executions/day from one workflow alone.
  • Overage charges — once you exceed your plan’s execution cap, you’re either rate-limited, forced to upgrade, or charged per-execution overage fees depending on the plan.
  • Active workflow limits — cloud plans often cap how many workflows can be active (not just built) at once. Testing and staging workflows can eat into that limit if you’re not archiving unused ones.
  • Data retention — execution history and logs beyond a certain window may require a higher tier to retain, which matters if you need to debug something that happened two weeks ago.
  • Add-on seats — team collaboration features are often priced per additional user once you go beyond the base seat count.
  • If your automations are lightweight — a few daily Slack notifications, a handful of CRM syncs — cloud pricing is genuinely reasonable. If you’re running high-frequency polling workflows or processing large data batches, the execution model starts working against you.

    Self-Hosting n8n: The Cost Comparison

    Because n8n ships as an open-source Docker image, you can run the exact same automation engine on your own server for the price of the VPS — no execution caps, no per-seat charges, no overage billing. The tradeoff is that you’re responsible for uptime, backups, and updates.

    Here’s a minimal but production-usable docker-compose.yml to get n8n running with persistent data and a Postgres backend:

    version: "3.8"
    
    services:
      postgres:
        image: postgres:16
        restart: unless-stopped
        environment:
          POSTGRES_USER: n8n
          POSTGRES_PASSWORD: change_this_password
          POSTGRES_DB: n8n
        volumes:
          - postgres_data:/var/lib/postgresql/data
    
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          DB_TYPE: postgresdb
          DB_POSTGRESDB_HOST: postgres
          DB_POSTGRESDB_DATABASE: n8n
          DB_POSTGRESDB_USER: n8n
          DB_POSTGRESDB_PASSWORD: change_this_password
          N8N_HOST: automation.yourdomain.com
          N8N_PROTOCOL: https
          WEBHOOK_URL: https://automation.yourdomain.com/
          GENERIC_TIMEZONE: UTC
        volumes:
          - n8n_data:/home/node/.n8n
        depends_on:
          - postgres
    
    volumes:
      postgres_data:
      n8n_data:

    Bring it up with:

    docker compose up -d

    Then put it behind a reverse proxy (Caddy or Nginx) for TLS termination, and you have a fully functional, unlimited-execution n8n instance. We cover the full reverse-proxy and TLS setup in our Docker Compose deployment guide if you want the complete walkthrough.

    Real Numbers: Cloud vs. Self-Hosted

    To put this in perspective, a small 2GB/2vCPU VPS from a provider like DigitalOcean or Hetzner typically costs between $6 and $12/month — and can comfortably run n8n plus Postgres for low-to-moderate workflow volume. Compare that to a cloud Pro-tier plan, and the break-even point usually arrives faster than people expect, especially once you factor in execution overages.

    The catch is that self-hosting shifts responsibility onto you:

  • You manage OS updates, Docker image updates, and security patching.
  • You need your own backup strategy for the Postgres volume.
  • You need uptime monitoring, since there’s no vendor SLA watching your instance for you.
  • You handle scaling manually if execution volume grows.
  • That last point is where a lot of self-hosted n8n setups quietly fail — nobody notices the container crashed until a client complains their automation didn’t fire. Setting up external uptime monitoring through something like BetterStack closes that gap cheaply, pinging your webhook endpoint or n8n health check on a schedule and alerting you the moment it goes down.

    When Cloud Makes More Sense Than Self-Hosting

    Self-hosting isn’t automatically the right call. Cloud is usually the better option when:

  • You don’t have DevOps bandwidth to manage patching and backups.
  • You need enterprise features like SSO/SAML out of the box.
  • Your execution volume is genuinely low and predictable.
  • You want a support contract and SLA rather than being your own on-call engineer.
  • Self-hosting wins when execution volume is high, you already run infrastructure for other services, or you want full control over data residency and retention — which matters a lot if you’re processing anything sensitive through your workflows.

    If you’re already running other self-hosted tools on a VPS, adding n8n to the same box (or a small dedicated one) is usually the most cost-efficient path. We go deeper into stacking multiple self-hosted services efficiently in our guide to self-hosting your DevOps toolchain.

    Migrating Between Cloud and Self-Hosted

    One underrated advantage of n8n’s architecture is that migration isn’t a one-way door. Workflows are portable JSON exports, so you can:

    1. Build and prototype on n8n Cloud while your automation needs are small.
    2. Export workflows once execution volume or costs justify moving.
    3. Import them into a self-hosted instance without rebuilding from scratch.

    This makes it low-risk to start on cloud and migrate later once you understand your actual execution patterns — which is honestly the smartest way to approach the pricing decision rather than guessing upfront.

    Choosing a VPS for Self-Hosted n8n

    If you decide to self-host, the VPS choice matters more than people assume. You want:

  • At least 2GB RAM (n8n plus Postgres is lightweight but not trivial under load)
  • SSD-backed storage for database performance
  • A provider with snapshot/backup support baked in
  • Reasonable network latency to the APIs your workflows call most often
  • DigitalOcean and Hetzner both offer droplets/servers in this range at low monthly cost, with straightforward Docker support and one-click backups. If you want managed database hosting instead of running Postgres in the same container stack, that’s a worthwhile upgrade once your automation becomes business-critical.

    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Does n8n Cloud have a free plan?
    n8n typically offers a free trial period rather than a permanent free tier for cloud hosting. For a genuinely free option long-term, self-hosting the open-source Docker image on your own server is the way to go — you only pay for the VPS.

    What counts as an “execution” in n8n pricing?
    Each time a workflow runs from start to finish counts as one execution, regardless of whether it succeeds, fails, or is triggered manually, by webhook, or by schedule. A single workflow polling an API every few minutes can consume thousands of executions per month on its own.

    Is self-hosted n8n really free?
    The software itself is free under n8n’s fair-code license, but you still pay for the server it runs on, plus your own time for maintenance, updates, and monitoring. “Free” software isn’t the same as “zero-cost” infrastructure.

    Can I switch from n8n Cloud to self-hosted later?
    Yes. Workflows export as JSON and import cleanly into a self-hosted instance, so you can start on cloud and migrate once your execution volume justifies running your own server.

    How many executions does a typical small business need per month?
    It varies enormously, but a business running a handful of automations — form submissions, CRM syncs, notification workflows — often stays in the low thousands of executions per month, which usually fits comfortably within entry-level cloud tiers.

    Is n8n cloud pricing worth it compared to Zapier or Make?
    n8n generally offers more generous execution limits per dollar than Zapier, and more flexibility for custom logic than Make, but the comparison depends heavily on your specific workflow complexity — it’s worth testing all three against your actual use case before committing.

    Final Take

    n8n cloud pricing works well for teams that want a managed, zero-maintenance automation platform and have moderate, predictable execution volume. Once your workflows scale into high-frequency polling or large data batches, the execution-based model starts costing more than a self-hosted VPS running the same open-source image. Start with cloud if you’re prototyping, track your execution counts honestly, and migrate to self-hosting once the math tips in that direction — the workflow export format makes that switch far less painful than most SaaS-to-self-hosted migrations.

  • n8n Template Guide: Deploy & Customize Workflows Fast

    The Complete n8n Template Guide for Self-Hosted Automation

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’re running DevOps pipelines, monitoring alerts, or internal tooling, chances are you’ve hit the point where Zapier gets too expensive and too limited. That’s where n8n comes in — a fair-code workflow automation tool you can self-host on your own VPS. The fastest way to get productive with it is to start from an existing n8n template rather than building every workflow from scratch.

    This guide covers what an n8n template actually is, how to self-host n8n with Docker, where to find production-ready templates, and how to adapt them for real infrastructure work like log monitoring, deployment notifications, and backup automation.

    What Is an n8n Template?

    An n8n template is a pre-built workflow — exported as JSON — that you can import directly into your n8n instance. Instead of manually wiring together nodes (HTTP requests, triggers, conditionals, database writes), you import a template and just plug in your credentials and endpoints.

    Templates cover common automation patterns:

  • Slack/Discord alerts when a server goes down
  • Syncing data between a database and a spreadsheet
  • Automated backups pushed to S3-compatible storage
  • CI/CD deployment notifications
  • RSS-to-social-media posting pipelines
  • Because n8n workflows are just JSON under the hood, templates are portable, version-controllable, and easy to share across teams.

    Why Templates Matter for Automation Teams

    Writing a workflow from a blank canvas takes time — you have to know which nodes exist, how credentials are scoped, and how error handling should be structured. A template shortcuts that learning curve. For sysadmins managing a fleet of servers, a solid n8n template library means you can deploy monitoring and alerting automation in minutes instead of hours.

    This matters even more if you’re self-hosting n8n rather than using n8n Cloud — self-hosting gives you full data control, which is often a requirement for infrastructure teams handling internal credentials and server access tokens.

    Setting Up n8n with Docker

    Before you can use any template, you need a running n8n instance. The cleanest way to do this is with Docker Compose, which also makes it trivial to back up and migrate later.

    version: "3.8"
    
    services:
      n8n:
        image: n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - "5678:5678"
        environment:
          - N8N_HOST=n8n.yourdomain.com
          - N8N_PROTOCOL=https
          - N8N_PORT=5678
          - WEBHOOK_URL=https://n8n.yourdomain.com/
          - GENERIC_TIMEZONE=UTC
          - N8N_BASIC_AUTH_ACTIVE=true
          - N8N_BASIC_AUTH_USER=admin
          - N8N_BASIC_AUTH_PASSWORD=changeme
        volumes:
          - n8n_data:/home/node/.n8n
    
    volumes:
      n8n_data:

    Bring it up with:

    docker compose up -d

    Once it’s running, n8n is available on port 5678. If you’re new to Docker networking basics, our Docker Compose guide walks through volumes, restart policies, and multi-service stacks in more depth.

    Docker Compose Configuration for Production

    For production, don’t expose port 5678 directly to the internet. Put n8n behind a reverse proxy with TLS termination — Nginx or Traefik both work well, and our Nginx reverse proxy walkthrough covers the exact config you need for HTTPS with Let’s Encrypt.

    A few production hardening steps worth doing immediately:

  • Change the default basic auth credentials before exposing any port
  • Set N8N_ENCRYPTION_KEY explicitly so credential encryption survives container recreation
  • Use a managed Postgres database instead of the default SQLite for anything beyond light personal use
  • Put the instance behind Cloudflare for DDoS protection and a free SSL layer
  • If you’re picking infrastructure to host this on, a small VPS from DigitalOcean or Hetzner is more than enough — n8n is lightweight and rarely needs more than 1-2 vCPUs unless you’re running very high workflow volume.

    Finding and Importing n8n Templates

    Once your instance is live, the fastest path to a working automation is importing an existing template rather than building one node-by-node.

    Using the n8n Template Library

    n8n maintains an official template library at n8n.io/workflows, with thousands of community-submitted workflows organized by category — DevOps, marketing, sales ops, data sync, and more. Each listing shows the exact nodes used, so you can vet a template for security before importing it (especially important if it touches credentials or webhooks).

    Search for terms relevant to your use case — “server monitoring,” “Slack alert,” “database backup” — and you’ll typically find several variations to compare.

    Importing Templates via JSON

    Every n8n template can be imported two ways:

    1. Direct import from the library — click “Use this workflow” and it opens directly in your instance if you’re logged in.
    2. Manual JSON import — copy the workflow JSON, then in your n8n editor click the three-dot menu → Import from File/URL and paste it in.

    Here’s a minimal example of what a template’s JSON structure looks like — this one triggers on a webhook and posts to Slack:

    {
      "nodes": [
        {
          "parameters": {
            "path": "server-alert",
            "httpMethod": "POST"
          },
          "name": "Webhook",
          "type": "n8n-nodes-base.webhook",
          "position": [250, 300]
        },
        {
          "parameters": {
            "channel": "#alerts",
            "text": "={{$json["message"]}}"
          },
          "name": "Slack",
          "type": "n8n-nodes-base.slack",
          "position": [500, 300]
        }
      ],
      "connections": {
        "Webhook": {
          "main": [[{ "node": "Slack", "type": "main", "index": 0 }]]
        }
      }
    }

    After importing, you’ll need to reattach your own credentials — templates never include live API keys or tokens, since those are stored separately in n8n’s credential vault.

    Building Your Own Custom Template

    Once you’re comfortable with imported templates, the next step is building your own and saving it for reuse across projects. A good pattern:

    1. Build the workflow using real nodes and test it end-to-end
    2. Remove or placeholder any credentials so it’s shareable
    3. Export via the three-dot menu → Download
    4. Store the JSON in a git repo alongside your infrastructure-as-code so it’s versioned like everything else

    This turns your automation into something reproducible — if you rebuild your server, you re-import the template instead of rebuilding logic from memory.

    Best n8n Templates for DevOps and Monitoring

    A few template categories are especially useful for infrastructure-focused teams:

  • Uptime alerting — poll an endpoint or integrate with BetterStack and push failures to Slack/Discord/PagerDuty
  • Deployment notifications — trigger on GitHub Actions or GitLab CI webhooks and post deploy status to a team channel
  • Log digesting — pull logs from a source, filter by severity, and summarize into a daily digest
  • Automated backups — schedule a cron trigger to dump a database and push it to S3-compatible object storage
  • SSL expiry checks — hit your domains on a schedule and alert before certificates expire
  • If you’re already using an uptime monitor, BetterStack pairs particularly well with n8n since it exposes webhooks you can wire directly into an alerting workflow — no custom polling logic required.

    Scaling n8n in Production

    As your workflow count grows, a single Docker container running SQLite will start to show its limits. At that point:

  • Move to Postgres for the database backend
  • Split execution workers from the main process using n8n’s queue mode (Redis-backed)
  • Monitor container health with something like our self-hosted monitoring tools guide
  • Set resource limits in your Compose file so a runaway workflow can’t take down the host
  • For teams running dozens of active workflows, a dedicated 2-4 vCPU instance is a reasonable baseline — both DigitalOcean and Hetzner offer droplets/VPS instances in that range for a few dollars a month, which is dramatically cheaper than most SaaS automation tiers once you’re past a handful of workflows.

    Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

    FAQ

    What is an n8n template exactly?
    It’s a pre-built n8n workflow exported as JSON that you can import into your own instance, then customize with your own credentials and endpoints instead of building the workflow from scratch.

    Are n8n templates free to use?
    Most templates in the official n8n.io/workflows library are free and open. Some community creators publish paid templates for more complex use cases, but the majority you’ll need for DevOps automation are free.

    Do I need to self-host n8n to use templates?
    No — templates work on both n8n Cloud and self-hosted instances. Self-hosting via Docker gives you more control over data and credentials, which matters if your workflows touch internal infrastructure secrets.

    Can a template include credentials?
    No. Exported templates never include live credential values. You reconnect credentials manually after import, which keeps shared templates safe to publish or hand off to teammates.

    What’s the difference between a workflow and a template?
    They’re the same underlying structure — a template is simply a workflow that’s been exported, generalized, and shared for reuse rather than kept private in one instance.

    How do I back up my n8n templates?
    Export each workflow as JSON and store it in a git repository. This gives you version history and lets you redeploy workflows quickly if you rebuild your n8n instance.

    Wrapping Up

    Starting from an n8n template rather than a blank canvas is the single biggest time-saver for teams adopting workflow automation. Get a Docker-based instance running behind a reverse proxy, pull a few templates relevant to your infrastructure needs, and start customizing from there. Once you outgrow SQLite and single-container deployments, moving to Postgres and queue mode keeps things stable as your automation footprint grows.

  • n8n Self Hosted: Full Docker Installation Guide 2026

    n8n Self Hosted: The Complete Docker Setup and Hardening Guide

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’re tired of paying monthly fees for Zapier or Make, running n8n self hosted on your own VPS is one of the highest-leverage moves you can make as a developer or sysadmin. You get unlimited workflow executions, full data ownership, and no per-task billing — for the cost of a $6/month server.

    This guide covers everything you need to run n8n self hosted in production: Docker Compose setup, reverse proxy configuration, database choice, backups, and scaling with queue mode.

    Why Self-Host n8n

    n8n is an open-source workflow automation tool — think Zapier, but with a visual node editor and the ability to write custom JavaScript inside any node. The hosted cloud version is convenient, but it caps executions and charges per active workflow. Self-hosting removes both limits.

    When you run n8n self hosted, you also get:

  • Full control over data retention and where your credentials are stored
  • No vendor lock-in — export/import workflows as JSON anytime
  • The ability to run community and custom nodes that aren’t approved for n8n Cloud
  • Direct network access to internal services (databases, internal APIs) without exposing them publicly
  • The tradeoff is that you own the ops burden: updates, backups, uptime, and security. This guide addresses all four.

    n8n vs Zapier and Make

    If you’re evaluating whether to self-host at all, the deciding factor is usually volume and complexity. Zapier and Make are fine for a handful of simple, low-frequency automations. Once you’re running dozens of workflows with branching logic, webhooks, and custom code, the per-task pricing on those platforms gets expensive fast, and n8n self hosted becomes the more economical option, especially at scale.

    Prerequisites

    Before you start, you’ll need:

  • A VPS with at least 1 vCPU and 2GB RAM (n8n is fairly lightweight, but PostgreSQL and Redis add overhead if you use queue mode)
  • Docker and Docker Compose installed
  • A domain name you control, with DNS pointed at your server’s IP
  • Basic familiarity with the command line
  • If you don’t already have a VPS, DigitalOcean and Hetzner both offer affordable droplets/instances that are more than capable of running n8n comfortably — a $12/month droplet handles most single-user workloads without issue.

    Installing n8n with Docker

    The fastest, most maintainable way to run n8n self hosted is with Docker Compose. This keeps n8n, its database, and any supporting services isolated and easy to upgrade.

    First, create a project directory and the required subfolders:

    mkdir -p ~/n8n-stack/local-files
    cd ~/n8n-stack

    Docker Compose Setup

    Create a docker-compose.yml file with the following contents:

    version: '3.8'
    
    services:
      postgres:
        image: postgres:16
        restart: unless-stopped
        environment:
          - POSTGRES_USER=n8n
          - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
          - POSTGRES_DB=n8n
        volumes:
          - postgres_data:/var/lib/postgresql/data
        healthcheck:
          test: ['CMD-SHELL', 'pg_isready -U n8n']
          interval: 5s
          timeout: 5s
          retries: 10
    
      n8n:
        image: docker.n8n.io/n8nio/n8n:latest
        restart: unless-stopped
        ports:
          - '127.0.0.1:5678:5678'
        environment:
          - N8N_HOST=${DOMAIN_NAME}
          - N8N_PROTOCOL=https
          - N8N_PORT=5678
          - WEBHOOK_URL=https://${DOMAIN_NAME}/
          - DB_TYPE=postgresdb
          - DB_POSTGRESDB_HOST=postgres
          - DB_POSTGRESDB_DATABASE=n8n
          - DB_POSTGRESDB_USER=n8n
          - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
          - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
          - GENERIC_TIMEZONE=UTC
        volumes:
          - n8n_data:/home/node/.n8n
          - ./local-files:/files
        depends_on:
          postgres:
            condition: service_healthy
    
    volumes:
      postgres_data:
      n8n_data:

    Next, create a .env file to hold your secrets — never commit this to version control:

    cat > .env << 'EOF'
    DOMAIN_NAME=n8n.yourdomain.com
    POSTGRES_PASSWORD=change_this_to_a_long_random_string
    N8N_ENCRYPTION_KEY=change_this_to_another_long_random_string
    EOF

    Generate strong random values instead of the placeholders:

    openssl rand -hex 32

    Run that command twice and paste the outputs into POSTGRES_PASSWORD and N8N_ENCRYPTION_KEY respectively. The encryption key is critical — it encrypts stored credentials, and if you lose it, you lose access to every saved credential in your workflows. Back it up somewhere safe outside the server.

    Now bring the stack up:

    docker compose up -d

    Check that both containers are healthy:

    docker compose ps
    docker compose logs -f n8n

    At this point n8n is running on 127.0.0.1:5678, bound only to localhost. It isn’t reachable from the internet yet — that’s intentional. We’ll expose it safely through a reverse proxy in the next section.

    Setting Up a Reverse Proxy with HTTPS

    Running n8n behind a reverse proxy with TLS is non-negotiable for anything beyond local testing, since n8n handles webhooks and stored credentials. Nginx with Let’s Encrypt is the simplest combination.

    Install Nginx and Certbot on the host:

    sudo apt update
    sudo apt install -y nginx certbot python3-certbot-nginx

    Create a server block at /etc/nginx/sites-available/n8n:

    server {
        listen 80;
        server_name n8n.yourdomain.com;
    
        location / {
            proxy_pass http://127.0.0.1:5678;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_cache_bypass $http_upgrade;
        }
    }

    Enable the site and issue a certificate:

    sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
    sudo nginx -t && sudo systemctl reload nginx
    sudo certbot --nginx -d n8n.yourdomain.com

    Certbot will automatically rewrite the config for HTTPS and set up renewal. If you’d rather use Traefik with automatic Let’s Encrypt via Docker labels, our Traefik reverse proxy guide walks through that setup in detail, and it pairs well with the Compose file above.

    Database Configuration: SQLite vs PostgreSQL

    By default, n8n ships with SQLite, which is fine for quick testing but not recommended for production. SQLite struggles under concurrent writes, and a corrupted database file can silently break your entire instance with no easy recovery path. PostgreSQL, as configured in the Compose file above, handles concurrent workflow executions far more reliably and makes backups straightforward with standard tooling like pg_dump.

    If you’re already running PostgreSQL for other services, you can point n8n at that instance instead of running a dedicated container — just make sure the DB_POSTGRESDB_HOST environment variable resolves correctly from inside the n8n container’s network.

    Securing Your n8n Instance

    A self-hosted automation tool that stores API keys and OAuth tokens for every service you connect is a high-value target if compromised. Treat it accordingly.

  • Enable n8n’s built-in user management (Settings → Users) so the instance isn’t wide open to anyone with the URL
  • Restrict SSH access to key-based auth only and disable root login
  • Keep the Docker image updated regularly — docker compose pull && docker compose up -d pulls the latest patched release
  • Set N8N_BLOCK_ENV_ACCESS_IN_NODE=true to prevent workflow code nodes from reading host environment variables
  • Put the server behind a firewall that only allows ports 22, 80, and 443
  • For a full server hardening checklist beyond n8n specifically, see our guide on securing a self-hosted VPS, which covers fail2ban, unattended upgrades, and SSH hardening in more depth.

    If uptime matters for your automations — for example, workflows that process incoming webhooks from payment providers — it’s worth pairing your instance with an external monitoring service. BetterStack offers uptime monitoring and status pages that will alert you immediately if your n8n instance or its webhook endpoint goes down, which is far better than discovering a failed workflow days later.

    Backups

    Backups need to cover two things: the PostgreSQL database (your workflow definitions and execution history) and the n8n_data volume (which holds the encryption key and local file storage).

    A simple daily backup script:

    #!/bin/bash
    set -euo pipefail
    
    BACKUP_DIR=/root/n8n-backups
    TIMESTAMP=$(date +%Y%m%d-%H%M%S)
    mkdir -p "$BACKUP_DIR"
    
    docker compose exec -T postgres pg_dump -U n8n n8n | gzip > "$BACKUP_DIR/n8n-db-$TIMESTAMP.sql.gz"
    docker run --rm -v n8n-stack_n8n_data:/data -v "$BACKUP_DIR":/backup alpine 
      tar czf "/backup/n8n-data-$TIMESTAMP.tar.gz" -C /data .
    
    find "$BACKUP_DIR" -type f -mtime +14 -delete

    Schedule it with cron:

    crontab -e
    # Add the following line:
    0 3 * * * /root/n8n-backup.sh >> /var/log/n8n-backup.log 2>&1

    Copy the backups off the server itself — to object storage or another machine — since a backup that lives only on the server it’s protecting isn’t a real backup.

    Scaling n8n with Queue Mode

    If you’re running high-volume or long-running workflows, the default setup can become a bottleneck because a single n8n process handles both the UI and execution. Queue mode splits this: a main process handles the editor and webhook triggers, while separate worker processes pull jobs from a Redis-backed queue and execute them.

    To enable it, add a Redis service to your Compose file and set these additional environment variables on the n8n service:

      redis:
        image: redis:7-alpine
        restart: unless-stopped

    EXECUTIONS_MODE=queue
    QUEUE_BULL_REDIS_HOST=redis

    Then run a separate worker container using the same image with the command n8n worker. This lets you scale workers horizontally as workflow volume grows, without touching the main instance.

    Monitoring and Observability

    Once n8n is handling anything business-critical, blind spots become expensive. At minimum, track:

  • Container health via docker compose ps and restart policies
  • Disk usage on the volumes, since execution history can grow unbounded if you don’t configure EXECUTIONS_DATA_PRUNE
  • HTTP response codes on the reverse proxy for failed webhook deliveries
  • Our Docker Compose monitoring guide shows how to wire up Prometheus and Grafana against a Compose stack like this one if you want dashboards rather than just log tailing.

    Recommended: Want to explore DigitalOcean yourself? DigitalOcean is a direct vendor link (not an affiliate/tracked link).

    FAQ

    Is n8n free to self-host?
    Yes. The core n8n software is fair-code licensed and free to self-host with no execution limits. You only pay for the server it runs on and optional enterprise features if you need SSO or advanced permissions.

    How much does it cost to run n8n self hosted?
    A small VPS with 1-2 vCPUs and 2GB of RAM, typically $6-12/month from providers like DigitalOcean or Hetzner, is enough for most individual or small-team workloads.

    Do I need PostgreSQL, or can I stick with SQLite?
    SQLite works for testing, but PostgreSQL is strongly recommended for production because it handles concurrent executions more reliably and supports standard backup tooling.

    Can I run n8n without Docker?
    Yes, n8n can be installed via npm directly on the host, but Docker is recommended because it isolates dependencies, simplifies upgrades, and matches the environment n8n is tested against.

    How do I update a self-hosted n8n instance safely?
    Back up your database and volumes first, then run docker compose pull followed by docker compose up -d. Check the n8n release notes for breaking changes before upgrading across major versions.

    Is it safe to expose n8n’s webhook URLs publicly?
    Yes, that’s expected usage, but only expose them behind HTTPS via a reverse proxy, and enable user authentication on the editor UI so the workflow builder itself isn’t publicly accessible.

    Final Thoughts

    Running n8n self hosted takes maybe 30 minutes of setup time and gives you a private, unlimited automation platform that competes with tools costing hundreds of dollars a month at scale. Start with the Docker Compose setup above, put it behind HTTPS, automate your backups, and you’ll have a production-grade instance before the end of the afternoon.

  • n8n vs Make: Workflow Automation Comparison Guide 2026

    n8n vs Make: Which Workflow Automation Tool Should You Choose?

    Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

    If you’ve spent any time evaluating workflow automation platforms, you’ve hit the n8n vs Make debate. Both tools let you connect APIs, automate repetitive tasks, and build integration pipelines without writing a full application from scratch — but they take fundamentally different approaches to deployment, pricing, and extensibility.

    This guide breaks down n8n vs Make from a developer and sysadmin perspective: what each tool actually does, how they handle self-hosting, what the real costs look like at scale, and which one you should pick for your specific use case.

    What Is n8n?

    n8n is an open-source, node-based workflow automation tool. It’s built in TypeScript, ships as a Docker image, and can be self-hosted on your own infrastructure or used via n8n Cloud. The name stands for “nodemation,” and the core pitch is fair-code licensing — you can view and modify the source, self-host for free, and only pay if you use their managed cloud offering or exceed certain usage thresholds under the Sustainable Use License.

    For developers, the killer feature is the Code node, which lets you drop raw JavaScript (or Python via a community node) directly into a workflow step. That means you’re never fully boxed in by the visual builder — if a connector doesn’t exist, you write it.

    Core n8n Features

  • Visual, node-based workflow editor with branching logic and error workflows
  • Native Docker support and official Helm charts for Kubernetes deployment
  • 400+ built-in integrations plus HTTP Request nodes for anything else
  • Self-hosted instances have no artificial execution caps — you’re limited by your own server resources
  • Built-in credential encryption and support for external secret managers (Vault, AWS Secrets Manager)
  • What Is Make (formerly Integromat)?

    Make is a cloud-only visual automation platform, rebranded from Integromat in 2022. It uses a “scenario” model — modules connected on a canvas — and is generally considered more polished and beginner-friendly than n8n out of the box. Make does not offer a self-hosted version; everything runs on their infrastructure, and pricing is based on “operations” consumed per billing cycle.

    Make shines for non-technical teams who want drag-and-drop automation without touching a terminal. It has strong error-handling visualizations, a cleaner UI for mapping data between apps, and a large library of pre-built app connectors maintained by Make’s own team.

    Core Make Features

  • Visual scenario builder with real-time execution mapping
  • 2,000+ pre-built app integrations
  • Operation-based pricing (each module execution consumes one “operation”)
  • No self-hosting option — vendor lock-in is part of the deal
  • Built-in scheduling, webhooks, and API endpoint creation per scenario
  • n8n vs Make: Pricing Comparison

    This is where the two tools diverge hardest. Make bills you per operation, which sounds fine until a workflow runs thousands of times a day across multiple modules — costs scale directly with usage. n8n’s self-hosted tier is free (you only pay for your own server), while n8n Cloud uses execution-based pricing that’s generally more generous at the entry tier.

  • Make Free plan: 1,000 operations/month, limited to 2 active scenarios
  • Make Core plan: starts around $9/month for 10,000 operations
  • n8n self-hosted: $0 licensing cost, only infrastructure spend (a $6-$12/month VPS easily handles moderate workloads)
  • n8n Cloud Starter: starts around $20/month with generous execution limits
  • If you’re running high-volume workflows — say, syncing data every few minutes across multiple systems — self-hosted n8n is almost always cheaper long-term, because you’re paying for compute, not per-execution metering. We cover how to size that compute correctly in our guide to choosing a VPS for Docker workloads.

    Self-Hosting and Deployment

    This is the single biggest differentiator in the n8n vs Make comparison: n8n can run entirely on infrastructure you control, Make cannot.

    A minimal self-hosted n8n deployment with Docker Compose looks like this:

    yaml
    version: "3.8"
    services:
    n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
    - "5678:5678"
    environment:
    - N8N_HOST=automation.yourdomain.com
    - N8N_PORT=5678
    - N8N_PROTOCOL=https
    - NODE_ENV=production
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=postgres
    - DB_POSTGRESDB_DATABASE=n8n
    - DB_POSTGRESDB_USER=n8n
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
    - n8n_data:/home/node/.n8n
    depends_on:
    - postgres

    postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
    - POSTGRES_USER=n8n
    - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    - POSTGRES_DB=n8n
    volumes:
    - postgres_data:/var/lib/postgresql/data

    volumes:
    n8n_data:
    postgres_data:
    `

    Run it with:

    `bash
    export N8N_ENCRYPTION_KEY=$(openssl rand -hex 24)
    export POSTGRES_PASSWORD=$(openssl rand -hex 16)
    docker compose up -d
    `

    Put this behind a reverse proxy with TLS (Caddy or Traefik both work well) and you have a production-grade automation server for the cost of a small VPS. We walk through the full reverse-proxy setup in our Docker Compose deployment guide.

    For reliable uptime on a self-hosted instance, a provider like DigitalOcean or Hetzner gives you predictable pricing and enough headroom to run n8n plus Postgres comfortably on a $6-$12/month droplet or CX22 instance. If uptime matters for business-critical automations, pair your instance with BetterStack for uptime monitoring and incident alerting — self-hosting means you own the reliability, so monitor accordingly.

    Make, by contrast, requires zero infrastructure knowledge. You sign up, connect your apps via OAuth, and build. That simplicity is the entire value proposition — but it also means you're fully dependent on Make's uptime, rate limits, and pricing changes.

    Ease of Use and Learning Curve

    Make generally wins on initial onboarding. Its module-mapping interface makes data transformation between apps visually intuitive — you click a field, drag it to the target, done. n8n's node editor is powerful but assumes more comfort with JSON, expressions, and occasionally raw code.

    That said, n8n's expression editor ({{ $json.fieldName }} syntax) is straightforward once you've used it a few times, and the built-in Code node means you're never stuck waiting for an official connector — you can just call the API directly:

    `javascript
    const response = await this.helpers.httpRequest({
    method: 'GET',
    url: 'https://api.example.com/v1/status',
    headers: {
    Authorization:
    Bearer ${$credentials.apiToken}
    }
    });

    return [{ json: response }];
    `

    Teams with at least one developer tend to outgrow Make's constraints faster than they outgrow n8n's, simply because n8n gives you an escape hatch into real code.

    Integrations and Extensibility

    Make has a larger catalog of pre-built connectors out of the box — roughly 2,000+ compared to n8n's 400+. But raw connector count is misleading: n8n's HTTP Request node combined with the Code node means you can integrate with virtually any REST or GraphQL API even without a dedicated node, whereas Make's no-code-only model makes truly custom integrations more cumbersome.

    n8n also supports community nodes — npm packages that extend functionality — and because it's open source, you can fork it and build entirely custom nodes for internal tools. Make has no equivalent; you're limited to what Make's team builds or what you can construct with their generic HTTP module.

    Performance and Scalability

    For high-throughput automation (thousands of executions per hour), self-hosted n8n scales with your infrastructure — you can run it in queue mode with Redis and multiple worker containers to horizontally scale execution:

    `bash
    docker run -d
    -e EXECUTIONS_MODE=queue
    -e QUEUE_BULL_REDIS_HOST=redis
    -e N8N_ENCRYPTION_KEY=$N8N_ENCRYPTION_KEY
    n8nio/n8n worker
    `

    Make's scalability is entirely dictated by your plan tier and their platform's rate limits. You can't add compute to speed up execution — you upgrade your plan or wait. For teams with unpredictable or bursty automation needs, that's a real constraint.

    Maintainability: Who's on the Hook When Something Breaks

    This is the tradeoff pricing comparisons usually skip. Make is fully managed: uptime, scaling, and platform updates are Make's responsibility, not yours. Self-hosted n8n moves that responsibility to you — you patch the Docker image, monitor the container, back up the Postgres database, and diagnose it yourself at 2am if a workflow silently stops firing. n8n Cloud sits in between: same n8n interface and self-hosting portability if you ever want to migrate off it, but Google/Make-style managed uptime.

    In practice, this means self-hosted n8n has a real ongoing time cost that a monthly Make subscription doesn't — acceptable if you (or your team) already run other Dockerized services and this is one more thing to monitor, less acceptable if automation is the only infrastructure you're maintaining.

    Common Use Cases for Each

  • Internal ops automation (Slack/email notifications, ticket routing, approval workflows): either tool works well; Make's polish wins for non-technical teams building these themselves.
  • Data sync between SaaS tools (CRM → spreadsheet → email tool): both handle this natively; n8n's Code node helps when the two tools' data models don't map cleanly.
  • Custom API integrations with unusual auth or pagination: n8n's ability to drop in raw JavaScript makes it noticeably easier when a service doesn't have a clean pre-built connector.
  • High-volume, scheduled batch jobs (thousands of executions/day): self-hosted n8n avoids Make's per-operation cost scaling; sizing your own server becomes the tradeoff instead.
  • Regulated or compliance-sensitive data: self-hosted n8n keeps data on infrastructure you control, which matters when a workflow touches data that can't leave a specific environment.
  • Which Should You Choose?

    The honest answer depends on who's running the automation:

  • Choose Make if you have a non-technical team, want zero infrastructure responsibility, and your automation volume is moderate and predictable.
  • Choose n8n if you have any DevOps or engineering capacity, want to avoid per-operation billing at scale, need custom code paths, or care about data residency and self-hosting for compliance reasons.
  • Choose n8n Cloud if you want n8n's flexibility without managing servers yourself, and you're fine paying for that convenience.
  • For most readers of a technical blog like this one — people comfortable with Docker, VPS management, and reverse proxies — self-hosted n8n is the more cost-effective and future-proof choice. You're not locked into a vendor's pricing changes, and you retain full control over your data and execution environment.

    If you're just getting started, spin up a test instance on a cheap VPS this week, connect two or three of your actual tools, and see how far the Code node takes you before deciding whether Make's polish is worth the recurring operation costs.

    Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

    FAQ

    Is n8n really free?
    Self-hosted n8n is free to run under its Sustainable Use License — you can use it for internal business automation without paying license fees. You only pay for the server it runs on. n8n Cloud (their managed hosting) is a separate paid product.

    Can I migrate workflows from Make to n8n?
    There's no automated migration tool between the two platforms since they use different scenario/workflow formats. You'll need to manually rebuild workflows, though the underlying logic (triggers, actions, conditionals) usually maps over conceptually without much friction.

    Is Make more reliable than self-hosted n8n?
    Make's infrastructure is professionally managed with high uptime SLAs on paid plans. A self-hosted n8n instance is only as reliable as the server and monitoring you set up around it — which is why pairing it with uptime monitoring is important for production use.

    Does n8n support webhooks like Make does?
    Yes. n8n has native Webhook trigger nodes that generate a unique URL per workflow, functionally equivalent to Make's webhook modules. You can test one instantly with a simple curl request:
    curl -X POST https://your-n8n-instance.com/webhook/test-id -d ‘{“key”:”value”}’`.

    Which tool is better for a solo developer?
    n8n tends to win for solo developers because it’s free to self-host, gives full code-level control, and doesn’t penalize experimentation with per-operation billing. Make’s free tier caps out quickly once you’re testing multiple workflows.

    Can I run n8n on Kubernetes instead of Docker Compose?
    Yes — n8n publishes official Helm charts, and the same queue-mode architecture used for Docker scaling applies to Kubernetes deployments, letting you run separate worker pods for execution load.

  • Complete Guide: Install n8n with Docker and HTTPS on Ubuntu 24.04

    Complete Guide: Install n8n with Docker and HTTPS on Ubuntu 24.04

    Installing n8n with Docker and HTTPS on Ubuntu 24.04 gets you a production-ready, self-hosted automation server in about 15 minutes: Docker for isolation, Postgres for persistent workflow storage, and Caddy for automatic, zero-config SSL.

    Why Use n8n with Docker on Ubuntu 24.04

    Running n8n in Docker instead of a bare-metal install keeps upgrades to a single docker compose pull && docker compose up -d, isolates n8n’s Node.js runtime from the rest of the system, and makes the whole stack reproducible if you ever need to rebuild the server. Pairing it with Postgres instead of the default SQLite avoids the file-locking issues SQLite runs into once you have more than a couple of concurrent workflow executions.

    Prerequisites Before Installing n8n

    You’ll need an Ubuntu 24.04 server with root or sudo access, a domain name pointed at the server’s IP (an A record), and ports 80 and 443 open in your firewall/security group — Caddy needs both to complete the automatic HTTPS certificate challenge.

    Install Docker on Ubuntu 24.04

    sudo apt update
    sudo apt install docker.io docker-compose-plugin -y
    sudo systemctl enable docker
    sudo systemctl start docker
    docker --version

    Create Docker Compose for n8n and Postgres

    Create a docker-compose.yml defining both services. n8n talks to Postgres over the internal Docker network, so only n8n’s port needs to be exposed to the host.

    version: "3.8"
    
    services:
      postgres:
        image: postgres:16
        restart: always
        environment:
          POSTGRES_USER: n8n
          POSTGRES_PASSWORD: strongpassword
          POSTGRES_DB: n8n
        volumes:
          - ./data/postgres:/var/lib/postgresql/data
    
      n8n:
        image: n8nio/n8n
        restart: always
        ports:
          - "5678:5678"
        environment:
          DB_TYPE: postgresdb
          DB_POSTGRESDB_HOST: postgres
          DB_POSTGRESDB_DATABASE: n8n
          DB_POSTGRESDB_USER: n8n
          DB_POSTGRESDB_PASSWORD: strongpassword
        depends_on:
          - postgres

    Replace strongpassword with a real generated password (e.g. openssl rand -base64 24) before you start the stack — don’t leave the placeholder in a production file.

    Configure HTTPS with Caddy

    Caddy issues and renews Let’s Encrypt certificates automatically the first time it sees a request for the domain, with no manual certbot step. Point your domain’s A record at the server first, then add a Caddyfile:

    automation.yourdomain.com {
        reverse_proxy localhost:5678
    }

    If n8n and Caddy are both containers on the same Docker network, use the n8n service name instead of localhost: reverse_proxy n8n:5678.

    Start n8n with Docker Compose

    docker compose up -d
    docker compose logs -f

    Verifying the Installation

    Run docker compose ps and confirm both n8n and postgres show a status of Up (or healthy if you’ve added healthchecks). Then open https://automation.yourdomain.com in a browser — you should land on n8n’s setup screen with a valid padlock/certificate, not a security warning. If the page doesn’t load, check the Troubleshooting section below before assuming the install failed; the two services almost always start correctly, and the reverse proxy or DNS record is the more common culprit.

    Quick Reference Commands

    # Check container status
    docker compose ps
    
    # Follow n8n logs only
    docker compose logs -f n8n
    
    # Restart just n8n after a config change
    docker compose restart n8n
    
    # Pull the latest n8n image and recreate
    docker compose pull n8n
    docker compose up -d n8n
    
    # Export all workflows before an update
    docker compose exec n8n n8n export:workflow --all --output=/home/node/backup.json

    Troubleshooting

    n8n container restarts in a loop: run docker compose logs n8n — this is almost always a database connection failure. Confirm DB_POSTGRESDB_PASSWORD in the n8n service matches POSTGRES_PASSWORD in the postgres service exactly, and that depends_on is giving Postgres enough time to accept connections before n8n’s first attempt.

    Browser shows a certificate warning or “connection refused”: this is a Caddy/DNS problem, not an n8n problem. Check docker compose logs caddy (or Caddy’s own log if it’s running outside Docker) — a failed ACME challenge usually means the domain’s A record isn’t pointing at this server yet, or port 80/443 is blocked by a firewall or cloud security group.

    Webhooks aren’t firing from external services: n8n needs to know its own public URL to generate correct webhook URLs. Set the WEBHOOK_URL environment variable (e.g. WEBHOOK_URL=https://automation.yourdomain.com/) on the n8n service and restart it.

    Security, Backups, and Maintenance

    Back up the ./data/postgres volume regularly — that’s where every workflow, credential, and execution history lives. A simple approach is docker compose exec postgres pg_dump -U n8n n8n > backup.sql on a cron schedule, or exporting workflows with the CLI command shown above before any update. Test upgrades on a non-production instance first: pull the new n8n image, check the release notes for breaking changes, then update production during a low-traffic window. Because Caddy terminates HTTPS in front of n8n, your login credentials and webhook payloads are encrypted in transit by default — there’s no separate TLS configuration to maintain on the n8n side.

    FAQ

    Do I need Postgres, or can I use the default SQLite?
    SQLite works for light personal use, but it locks the whole database file during writes, which causes errors once you have multiple workflows executing concurrently. Postgres is the recommended default for anything beyond a single-user test instance.

    Can I run this on a subdomain I already use for something else?
    Yes — Caddy can reverse-proxy multiple domains/subdomains from one Caddyfile, each with its own block. n8n itself doesn’t need a dedicated server.

    What Ubuntu versions besides 24.04 does this work on?
    The same Docker Compose file works on any Ubuntu LTS release with Docker installed (20.04, 22.04, 24.04) — 24.04 is used here because it’s the current LTS at time of writing.

    Final Thoughts

    Docker Compose, Postgres, and Caddy together give you a self-hosted n8n instance that’s easy to back up, easy to upgrade, and secured with HTTPS by default — a solid foundation whether you’re automating a handful of personal workflows or running production integrations. Once it’s running, the natural next steps are exploring pre-built n8n templates to speed up building your first workflows, or reading how n8n compares to hosted alternatives if you’re still deciding on a platform.