Agent skill

Self-Hosted n8n Deployment

by czlonkowski in czlonkowski/n8n-skills

Deploys a production n8n instance to a fresh Linux server over SSH with Docker Compose and Caddy HTTPS, in single or queue mode, and covers updates, backups and hardening.

MITAuto-check: notesDevOps & Cloud

Install Self-Hosted n8n Deployment

skills CLI
$ npx skills add czlonkowski/n8n-skills --skill n8n-self-hosting -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install czlonkowski/n8n-skills n8n-self-hosting --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/czlonkowski/n8n-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/n8n-self-hosting .claude/skills/n8n-self-hosting && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
n8n-self-hosting
GitHub stars
6.4k
Token cost
~3.5k tokens
SKILL.md length
1,716 words
Files
14 (incl. assets)
Skills in repo
15
Repo updated
First seen
Licence
MIT

At a glance

Deploys a production n8n instance to a fresh Linux server over SSH with Docker Compose and Caddy HTTPS, in single or queue mode, and covers updates, backups and hardening.

  • Works in 8 steps: Preflight (the cheapest failure is the… → Install Docker (if absent) → Lay down the project → …
  • Installing n8n on a new VPS from Hetzner, DigitalOcean or AWS EC2
  • SKILL.md covers Rule 0 — choose the mode (ask…, Rule 1 — secret hygiene…, Inputs to collect up front and The deploy flow, plus 2 more sections
  • Runs Shell scripts from its folder; calls docker, curl and ssh; needs N8N_ENCRYPTION_KEY and N8N_RUNNERS_AUTH_TOKEN

What it does

The agent first asks whether you want single mode (one n8n process on SQLite) or queue mode (a main process plus workers, with Redis and Postgres), because the two architectures differ. It then collects the domain, SSH details and timezone, runs preflight checks on the Ubuntu or Debian host, installs Docker, lays down the project from the templates in assets/, generates secrets, starts the stack and verifies TLS. It is meant for self-hosted n8n on Docker, not for n8n Cloud or for building workflows.

Secret handling is strict: every secret is generated fresh on the server, kept only in a mode 600 .env file, and the N8N_ENCRYPTION_KEY has to be backed up off the box. Only Caddy on ports 80 and 443 is public, while n8n, Postgres and Redis stay on the private Docker network. Reference files cover credential overwrites, day-two work such as update, backup and restore, and task runners for Python Code nodes.

When your agent uses it

  • Installing n8n on a new VPS from Hetzner, DigitalOcean or AWS EC2
  • Choosing between single mode and queue mode with workers
  • Putting n8n behind a reverse proxy with automatic HTTPS
  • Updating, backing up or restoring an existing Docker-based n8n
  • Making Python Code nodes work through task runners

Example prompts

  • “Deploy n8n on my new Hetzner VPS in queue mode with HTTPS on automations.example.com.”
  • “Back up my self-hosted n8n and then update it to the latest version.”
  • “My Python Code node says the runner is unavailable. Set up the task runner sidecar.”
  • “Enable Sign in with Google in n8n without handing every user the OAuth client secret.”

Requirements

  • A fresh Linux VM (Ubuntu or Debian) reachable over SSH with root or sudo
  • A domain name for the instance

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Preflight (the cheapest failure is the one you catch here)
  2. Install Docker (if absent)
  3. Lay down the project
  4. Fill .env + generate secrets
  5. Firewall
  6. Launch
  7. Verify (don't declare success without this)
  8. Hand off

What it can do on your machine

Read from SKILL.md and the folder at commit 19cd793. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships script files (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • docker
    • curl
    • ssh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • docs.n8n.io

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • N8N_ENCRYPTION_KEY
    • N8N_RUNNERS_AUTH_TOKEN
    • POSTGRES_PASSWORD
    • POSTGRES_NON_ROOT_PASSWORD

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Self-Hosted n8n Deployment loads about 3.5k tokens when it runs. Until then it costs about 255 tokens; SKILL.md has 1,716 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~255
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteRuns commands with sudoSKILL.md:8
    fresh Linux VM** (Ubuntu/Debian, root or sudo SSH) to a **running,
  • NoteMentions a .env fileSKILL.md:41
    password, or `.env` from another n8n instance into this one. See `SECURITY.md` for the
  • NoteMentions a .env fileSKILL.md:43
    2. **Secrets live only in `.env`** (mode 600), referenced by the compose as `${VAR}`. Never
  • NoteMentions a .env fileSKILL.md:52
    5. **`.env` and Caddy's `caddy_data` volume (the issued certs + ACME account key) are not
  • NoteMentions a .env fileSKILL.md:53
    u're working inside a git repo, confirm `.env` is git-ignored
  • NoteRuns commands with sudoSKILL.md:58
    the agent already has access). Root or a sudo user.
  • NoteMentions a .env fileSKILL.md:94
    `/opt/n8n`. The `DATA_FOLDER` value in `.env`
  • NoteMentions a .env fileSKILL.md:106
    - the matching `.env.*.example` → `<DATA_FOLDER>/.env`
  • NoteMentions a .env fileSKILL.md:111
    ### 4. Fill `.env` + generate secrets
  • NoteMentions a .env fileSKILL.md:114
    it into `.env`, replacing the matching `REPLACE_WITH_…` placeholder**: `N8N_ENCRYPTION_KEY`;

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from czlonkowski/n8n-skills at commit 19cd793, republished under its MIT licence (© czlonkowski). 1,716 words, ~3,470 tokens.

Download SKILL.mdSave it as .claude/skills/n8n-self-hosting/SKILL.md (or your agent's skills folder). This skill also uses 13 other files; get the full folder from GitHub.
name
n8n-self-hosting
description
Deploy a production self-hosted n8n end-to-end to a fresh Linux VM over SSH, using Docker Compose behind a Caddy reverse proxy with automatic HTTPS. Use whenever the user wants to self-host, install, provision, or deploy n8n on their own server/VPS (Hetzner, DigitalOcean, AWS EC2, bare metal) — single/regular mode or queue mode with workers — or to update, back up, restore, or harden such an instance, or make Python Code nodes run on it (task runners). For SELF-HOSTED n8n (Docker), not n8n Cloud and not building workflows. The skill makes the agent ask single-vs-queue first, collect domain/SSH/timezone inputs, generate fresh secrets on the box, and bring the stack up with TLS. Trigger on "deploy n8n", "self-host n8n", "n8n docker compose", "n8n queue mode / workers", "n8n reverse proxy / SSL", "back up / update my n8n", "Python runner unavailable" / "n8nio/runners sidecar", or "we don't want to give every user the OAuth client secret" / "enable Sign in with Google" (credential overwrites).

Deploying self-hosted n8n

This skill takes a fresh Linux VM (Ubuntu/Debian, root or sudo SSH) to a running, HTTPS, production n8n via Docker Compose behind Caddy (automatic Let's Encrypt TLS). It is for self-hosted n8n on Docker — not n8n Cloud, and not for building workflows (that's the rest of this pack).

Two deployment modes. The architectures differ, so pick the mode before doing anything.

You drive this end-to-end over SSH: preflight → install Docker → lay down the project → generate secrets → launch → verify TLS → hand off. The template files live in assets/; the per-mode and security depth live in the reference files named below.

Rule 0 — choose the mode (ask the user)

Do not guess. Ask, then commit to one:

Single / regularQueue
Processesone n8nmain + N workers
Extra servicesnone (SQLite)Redis (queue) + Postgres (DB)
Executes workflowsin the main processon workers, in parallel
Good for1 user, light/moderate load, simplest opshigh volume, heavy/long executions, horizontal scale
Composeassets/docker-compose.single.ymlassets/docker-compose.queue.yml
Deep diveSINGLE_MODE.mdQUEUE_MODE.md

If unsure, start single — it's the simplest correct thing and covers most needs. Moving to queue later means swapping the compose file and migrating SQLite→Postgres, so if the user already expects real volume, start queue.

Rule 1 — secret hygiene (non-negotiable)

A misstep here leaks client credentials. Be diligent:

  1. Generate every secret fresh, on the target box. Never copy an encryption key, DB password, or .env from another n8n instance into this one. See SECURITY.md for the openssl commands.
  2. Secrets live only in .env (mode 600), referenced by the compose as ${VAR}. Never inline a secret into docker-compose.yml, the Caddyfile, or anything you commit.
  3. The N8N_ENCRYPTION_KEY is sacred. It encrypts every stored credential. If it's lost or changes, all saved credentials become undecryptable. Set it explicitly, and tell the user to back it up off the box. Don't echo it into long-lived logs or chat history beyond what's needed to hand it over.
  4. Never expose internal services. Only Caddy (80/443) is public. n8n (5678), Postgres (5432), Redis (6379) stay on the private Docker network — the templates already omit their host port mappings. Don't add them.
  5. .env and Caddy's caddy_data volume (the issued certs + ACME account key) are not artifacts to share. If you're working inside a git repo, confirm .env is git-ignored before any commit.

Inputs to collect up front

  • SSH target — user@host and how you authenticate (key path or the user confirms the agent already has access). Root or a sudo user.
  • Domain — the full hostname n8n will live at, e.g. n8n.example.com (→ SUBDOMAIN=n8n, DOMAIN_NAME=example.com). The user must control its DNS.
  • TLS email — for Let's Encrypt (SSL_EMAIL).
  • Timezone — IANA name for Schedule/Cron nodes (e.g. Europe/Warsaw), else Etc/UTC.
  • Mode — single or queue (Rule 0). Queue → confirm the box has enough RAM (rough floor ~4 GB; each worker wants ~1–2 GB).
  • Optional modules — some features (currently Agents) are backend modules that stay off unless listed in N8N_ENABLED_MODULES. Ask only if the user brings one up; if they do, read the modules section of QUEUE_MODE.md before enabling it, because in queue mode it has to reach the workers as well.
  • Python Code nodes / who edits workflows — ask "Will workflows use Python Code nodes, or will anyone besides you edit workflows?" A yes to either means task runners in external mode: a n8nio/runners sidecar (one per worker in queue mode). The stock n8nio/n8n image has no Python 3, so in the default internal mode every Python Code node fails with Python runner unavailable: Python 3 is missing from this system. Read TASK_RUNNERS.md before step 3.

The deploy flow

Work through these in order. SINGLE_MODE.md / QUEUE_MODE.md give the mode-specific command detail; SECURITY.md covers secret generation and hardening; DAY2.md covers update/backup/restore.

1. Preflight (the cheapest failure is the one you catch here)
  • SSH in; confirm the OS is Debian/Ubuntu-like (. /etc/os-release).
  • DNS must already point at the box. Compare the box's public IP (curl -s ifconfig.me) with dig +short <fqdn> (run it from the box AND ideally your laptop). If they don't match, stop — Caddy's ACME challenge will fail. Have the user create the A record, wait for it to propagate, then continue.
  • Ports 80 and 443 must be reachable from the internet. Check the host firewall AND any cloud security group / network firewall (Hetzner Cloud, AWS SG, etc.) — these are outside the box and a common silent blocker.
2. Install Docker (if absent)
  • Check docker --version and docker compose version. If missing, install Docker Engine + the Compose plugin (Docker's official get.docker.com script on Ubuntu/Debian is fine). Re-check docker compose version before proceeding.
3. Lay down the project
  • Pick DATA_FOLDER — an absolute path, e.g. /opt/n8n. The DATA_FOLDER value in .env must equal this exact directory (the compose mounts ${DATA_FOLDER}/caddy_config/Caddyfile, and init-data.sh is mounted via a relative ./ path), so always run docker compose from here. Create it, plus caddy_config/ and local_files/ inside.
  • Get the template files onto the box. They live in this skill's assets/ on your machine, not on the server — transfer each one. Either scp them up, or (no local copy needed) write each file's contents over SSH, e.g. ssh <target> 'cat > <DATA_FOLDER>/docker-compose.yml' < assets/docker-compose.single.yml. Land them with these exact names:
    • the chosen compose → <DATA_FOLDER>/docker-compose.yml (rename it to exactly this)
    • Caddyfile → <DATA_FOLDER>/caddy_config/Caddyfile
    • queue only: init-data.sh → <DATA_FOLDER>/init-data.sh, then chmod +x it
    • the matching .env.*.example → <DATA_FOLDER>/.env
  • External task runners (Python): add the runner env vars and the task-runners sidecar to the compose now (TASK_RUNNERS.md has the snippet for each mode). Generate N8N_RUNNERS_AUTH_TOKEN in step 4 with the other secrets.
4. Fill .env + generate secrets
  • Set DATA_FOLDER, DOMAIN_NAME, SUBDOMAIN, SSL_EMAIL, GENERIC_TIMEZONE.
  • Generate each secret on the box with openssl (SECURITY.md has the commands) and write it into .env, replacing the matching REPLACE_WITH_… placeholder: N8N_ENCRYPTION_KEY; queue also POSTGRES_PASSWORD + POSTGRES_NON_ROOT_PASSWORD.
  • Before launching, confirm none are left unset: grep REPLACE_WITH_ .env must return nothing — a leftover placeholder becomes the literal password and Postgres/n8n fail to connect.
  • chmod 600 .env. Record the encryption key so the user can back it up off-box.
5. Firewall
  • ufw: allow OpenSSH + 80 + 443, then enable. Do not open 5678/5432/6379.
6. Launch
  • cd <DATA_FOLDER> && docker compose up -d.
  • Queue mode brings up Redis + Postgres + main + workers (workers via replicas). To add capacity: docker compose up -d --scale n8n-worker=N.
Show full SKILL.md (687 more words)Show less
7. Verify (don't declare success without this)
  • docker compose ps — every service Up/healthy (queue: postgres & redis healthy first).
  • n8n itself up (internal): docker compose exec n8n wget -qO- http://localhost:5678/healthz → {"status":"ok"}. This separates "n8n is running" from "TLS isn't ready yet."
  • Cert issued: docker compose logs caddy | grep -i 'certificate obtained'. First-boot ACME can take a minute or two; until it finishes, a public https:// request fails TLS — that means the cert is still pending, not that n8n is down.
  • Public reachability (with retry): curl -fsS --retry 5 --retry-delay 10 https://<fqdn>/healthz → {"status":"ok"}. (/healthz only proves the process is reachable; /healthz/readiness additionally confirms the DB is connected and migrated — use it when debugging a boot loop.)
  • Queue mode — main and workers must agree. Diff their environments: diff <(docker compose exec -T n8n env | sort) <(docker compose exec -T --index 1 n8n-worker env | sort). Only the public-URL/proxy vars should differ. Anything else means a behavioural setting reached the main but not the workers — and workers are what execute workflows, so it fails at runtime in one node rather than at boot. QUEUE_MODE.md explains the rule.
  • External task runners: docker compose logs n8n | grep 'Registered runner' must show both launcher-javascript and launcher-python (queue: check every worker). Then smoke-test a Python Code node (TASK_RUNNERS.md → Verify).
  • Open https://<fqdn> → the owner setup screen. Whoever completes that signup form first claims the instance — an exposed un-owned instance is a race, so create the owner account immediately, before sharing the URL. Enable 2FA. (Automated deploys can pre-provision the owner via env vars instead — see the owner row in SECURITY.md.)
8. Hand off
  • Give the user: the URL, where the project lives, the encryption key to store safely, and the Day-2 basics (update / backup / restore) from DAY2.md.

What NOT to do

  • Don't skip the DNS/ports preflight. A wrong A record or a closed cloud firewall is the #1 reason Caddy can't get a cert and n8n looks "broken."
  • Don't publish 5678/5432/6379 to the host. Caddy reaches n8n over the private network.
  • Don't reuse another instance's encryption key or .env. Fresh secrets per box.
  • Don't run queue mode on SQLite. Queue requires Postgres (the template already wires it).
  • Don't put secrets in docker-compose.yml or the Caddyfile. .env only.
  • Don't add a behavioural env var to the main only (queue mode). Modules, DB, queue, binary-data and encryption settings belong in the shared x-n8n-env anchor so workers get them too; only the public-URL/proxy vars are main-only. See QUEUE_MODE.md.
  • Don't use :latest blindly. Pin N8N_IMAGE_TAG; update deliberately (DAY2.md).
  • Don't promise Python Code nodes on the stock image in internal mode. They need the n8nio/runners sidecar, on exactly the n8n version, with imports allowlisted in the launcher config. By default even import json is rejected. See TASK_RUNNERS.md.
  • Don't --scale queue workers once runners are external. A sidecar serves exactly one worker. Add worker + runner pairs instead (TASK_RUNNERS.md).

Reference files

  • SINGLE_MODE.md — single-instance specifics, SQLite vs Postgres, when to graduate to queue.
  • QUEUE_MODE.md — queue architecture, workers/concurrency/scaling, shared encryption key, the main-vs-worker env-parity rule, optional backend modules (N8N_ENABLED_MODULES, e.g. Agents), binary data (database mode — filesystem is unsupported in queue mode; S3/Azure = Enterprise), webhook processors, multi-main licensing.
  • SECURITY.md — generating secrets, the encryption-key rules, the full hardening checklist (telemetry off, env-access block, public API, firewall, secure cookies).
  • CREDENTIAL_OVERWRITES.md — managed OAuth: register one OAuth app instance-wide so users never see a client ID/secret ("Sign in with Google" on self-hosted). The endpoint-vs-env choice, the mandatory endpoint auth token, parent-type inheritance, persistence and worker reload.
  • TASK_RUNNERS.md — task runners in external mode: why Python Code nodes need the n8nio/runners sidecar, the compose snippet for single mode and the one-sidecar-per-worker pattern for queue mode, allowlisting Python/JS modules via /etc/n8n-task-runners.json, the builtin deny list, verification, failure signatures, and upgrading n8n and the runners together.
  • DAY2.md — changing a setting (env var) safely, updating the image, backing up (encryption key + volume + Postgres), and restoring.
  • assets/ — the templates: docker-compose.single.yml, docker-compose.queue.yml, Caddyfile, .env.single.example, .env.queue.example, init-data.sh.

Authoritative upstream reference: the official hosting docs live at https://docs.n8n.io/deploy/host-n8n (restructured mid-2026 from the old /hosting/ paths — prefer these URLs). The env-var reference index is at https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables. When this skill and the live docs disagree, trust the docs and tell the user.

© czlonkowski, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 13 other files (assets) in skills/n8n-self-hosting of czlonkowski/n8n-skills.

  • SKILL.md
  • CREDENTIAL_OVERWRITES.md
  • DAY2.md
  • QUEUE_MODE.md
  • README.md
  • SECURITY.md
  • SINGLE_MODE.md
  • TASK_RUNNERS.md
  • assets/.env.queue.example
  • assets/.env.single.example
  • assets/Caddyfile
  • assets/docker-compose.queue.yml
  • assets/docker-compose.single.yml
  • assets/init-data.sh

Open the folder on GitHubat commit 19cd793

Compare with similar skills

Self-Hosted n8n Deployment next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Self-Hosted n8n Deployment compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Self-Hosted n8n Deployment this skillczlonkowski/n8n-skills6.4k—~3.5kAutomated safety check: NotesMIT
Investigate Production Container Restartsblotcms/blot2k—~4.7kAutomated safety check: PassAGPL-3.0
Monstermq Broker Configvogler75/monster-mq143—~2.2kAutomated safety check: PassGPL-3.0
Docker Deploymentfossasia/eventyay1.7k—~574Automated safety check: NotesApache-2.0
Frappe Ops DeploymentImpertio-Studio/Frappe_Claude_Skill_Package188—~2.4kAutomated safety check: NotesMIT
Iron Proxy Gateway for NanoClawnanocoai/nanoclaw31k—~4.6kAutomated safety check: NotesMIT

Similar skills

  • Work out why the blot-container-{blue,green,yellow} Docker containers from the most recent production deployment have restarted — distinguishing a normal deploy-triggered restart from a crash (V8…

    2k GitHub stars~4.7k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Monstermq Broker Config

    vogler75/monster-mq

    Guide for configuring, deploying, and operating the MonsterMQ broker.

    143 GitHub stars~2.2k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Docker Deployment

    fossasia/eventyay

    Docker Compose, container services, deployment. An agent skill from fossasia/eventyay.

    1.7k GitHub stars~574 tokensUpdated today
    DevOps & CloudAuto-check: notes
  • Frappe Ops Deployment

    Impertio-Studio/Frappe_Claude_Skill_Package

    A skill your agent uses when deploying Frappe/ERPNext to production, configuring Nginx or Supervisor, setting up Docker, enabling SSL, or hardening security.

    188 GitHub stars~2.4k tokensUpdated 22 days ago
    DevOps & CloudAuto-check: notes
  • Installs or refreshes Iron Proxy and its Iron Control web console for NanoClaw, with a local Docker setup, database, credentials and a human approval bridge.

    31k GitHub stars~4.6k tokensUpdated 3 days ago
    DevOps & CloudAuto-check: notes
  • LangBot Deployment Guide

    langbot-app/LangBot

    Deploys and configures a LangBot instance with Docker Compose or Kubernetes, covering config.yaml, the Box sandbox runtime, the plugin runtime and the global API key.

    18k GitHub stars~1.2k tokensUpdated yesterday
    DevOps & CloudAuto-check: notes

More from czlonkowski/n8n-skills

All 15 skills in this repo
  • n8n Binary Data Handling

    czlonkowski/n8n-skills

    Explains how n8n keeps file bytes in $binary apart from structured $json data, and how to read, write and preserve binary across nodes, agent tools and chat.

    6.4k GitHub stars~3.9k tokensUpdated 23 days ago
    Auto-check passed
  • n8n Code Node JavaScript

    czlonkowski/n8n-skills

    Guides writing JavaScript in n8n Code nodes: picking an execution mode, reading input data, returning items, using built-in helpers and avoiding common errors.

    6.4k GitHub stars~4.9k tokensUpdated 23 days ago
    Auto-check passed
  • Native Python in n8n Code Nodes

    czlonkowski/n8n-skills

    Explains how to write native Python in n8n Code nodes, including the two input variables, blocked imports and fixes for common errors.

    6.4k GitHub stars~2.8k tokensUpdated 23 days ago
    Auto-check passed
  • n8n Custom Code Tool Guide

    czlonkowski/n8n-skills

    Explains the n8n Custom Code Tool's actual runtime contract so an AI-agent-callable tool doesn't get written like a regular workflow Code node.

    6.4k GitHub stars~4k tokensUpdated 23 days ago
    Auto-check passed
  • n8n Error Handling

    czlonkowski/n8n-skills

    Wires n8n workflows so failures are visible and recoverable: per-node error outputs, retries, error workflows and correct 4xx and 5xx webhook responses.

    6.4k GitHub stars~5.1k tokensUpdated 23 days ago
    Auto-check passed
  • n8n Multi-Instance Targeting

    czlonkowski/n8n-skills

    Keeps an n8n MCP session pointed at the right n8n instance, with rules for discovering, switching and verifying the target before credential writes and for recovering from misroutes.

    6.4k GitHub stars~3.2k tokensUpdated 23 days ago
    Auto-check passed

Questions about Self-Hosted n8n Deployment

What does Self-Hosted n8n Deployment do?

Deploys a production n8n instance to a fresh Linux server over SSH with Docker Compose and Caddy HTTPS, in single or queue mode, and covers updates, backups and hardening. The agent first asks whether you want single mode (one n8n process on SQLite) or queue mode (a main process plus workers, with Redis and Postgres), because the two architectures differ. It then collects the domain, SSH details and timezone, runs preflight checks on the Ubuntu or Debian host, installs Docker, lays down the project from the templates in assets/, generates secrets, starts the stack and verifies TLS.

When should I use Self-Hosted n8n Deployment?

Self-Hosted n8n Deployment fits situations like: installing n8n on a new VPS from Hetzner, DigitalOcean or AWS EC2; choosing between single mode and queue mode with workers; putting n8n behind a reverse proxy with automatic HTTPS; updating, backing up or restoring an existing Docker-based n8n.

How do I install Self-Hosted n8n Deployment in Claude Code?

Run `npx skills add czlonkowski/n8n-skills --skill n8n-self-hosting -a claude-code`. Or copy the skill folder (skills/n8n-self-hosting in czlonkowski/n8n-skills) into .claude/skills/n8n-self-hosting in your project. Claude Code loads it when a task matches its description.

How do I install Self-Hosted n8n Deployment in Codex?

Run `npx skills add czlonkowski/n8n-skills --skill n8n-self-hosting -a codex`. Or copy the skill folder (skills/n8n-self-hosting in czlonkowski/n8n-skills) into .agents/skills/n8n-self-hosting in your project. Codex loads it when a task matches its description.

Can I use Self-Hosted n8n Deployment in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add czlonkowski/n8n-skills --skill n8n-self-hosting -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/n8n-self-hosting, .gemini/skills/n8n-self-hosting, .github/skills/n8n-self-hosting and .opencode/skills/n8n-self-hosting in your project.

What does Self-Hosted n8n Deployment need to run?

Going by SKILL.md and its folder, Self-Hosted n8n Deployment needs a shell for the scripts in its folder, the command-line tools its instructions call (docker, curl and ssh) and credentials named N8N_ENCRYPTION_KEY, N8N_RUNNERS_AUTH_TOKEN, POSTGRES_PASSWORD and POSTGRES_NON_ROOT_PASSWORD. Our summary lists: A fresh Linux VM (Ubuntu or Debian) reachable over SSH with root or sudo; A domain name for the instance.

Does Self-Hosted n8n Deployment access the network?

SKILL.md names 1 domain. As links in the text: docs.n8n.io. This is read from the text; nothing was executed.

Is Self-Hosted n8n Deployment safe to install?

Our automated static check of SKILL.md found notes only (runs commands with sudo; mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Self-Hosted n8n Deployment use?

Self-Hosted n8n Deployment is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Self-Hosted n8n Deployment use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Self-Hosted n8n Deployment?

Skills that share tags, products or a category with Self-Hosted n8n Deployment: Investigate Production Container Restarts (blotcms/blot, 2k stars), Monstermq Broker Config (vogler75/monster-mq, 143 stars), Docker Deployment (fossasia/eventyay, 1.7k stars) and Frappe Ops Deployment (Impertio-Studio/Frappe_Claude_Skill_Package, 188 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Self-Hosted n8n Deployment?

czlonkowski (a GitHub user) maintains it in czlonkowski/n8n-skills, which has 6,396 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on September 16, 2026.

Source: czlonkowski/n8n-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.