N8n Self Hosting

Romuald CzlonkowskiCommunityCreated by Romuald Czlonkowski

Skill
Workflow
Automation and integrations
MIT
Low risk
Has scripts

From the author

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).

— the description by Romuald Czlonkowski

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured procedure for deploying n8n on a fresh Linux VM via SSH. It automates the setup of Docker, Caddy for automatic HTTPS, and the necessary Docker Compose configuration. The skill supports two deployment architectures: a single-instance mode for simpler setups and a queue-based mode for horizontal scaling. It includes guidance on secret management, firewall configuration, and the integration of external task runners for Python Code nodes, ensuring a secure and functional self-hosted environment.

What it does

Deploys n8n using Docker Compose and a Caddy reverse proxy.
Configures automatic HTTPS via Let's Encrypt.
Supports both single-instance and queue-based deployment modes.
Manages fresh secret generation and environment variable security.
Integrates external task runners for Python Code node execution.
Provides procedures for updates, backups, and instance hardening.

When to use it

When you need to install n8n on your own infrastructure or VPS.
When you require a specific deployment mode like queue mode for scaling.
When you need to enable Python Code nodes using external task runners.
When you need to update, back up, or restore an existing self-hosted n8n instance.

Advantages

Ensures consistent deployment through standardized templates.
Automates complex tasks like TLS certificate management.
Promotes secure practices by enforcing fresh secret generation.
Provides clear paths for scaling from single to queue-based architectures.

Usage examples

“Deploy n8n on my new Ubuntu server.”: The agent will initiate the preflight check, ask for your deployment mode preference, and guide you through the installation of Docker and the n8n stack.
“I need to set up n8n in queue mode with workers.”: The agent will collect the necessary domain and SSH details, then configure the stack with Redis and Postgres to support horizontal scaling.
“How do I enable Python Code nodes on my self-hosted n8n?”: The agent will guide you through adding the n8nio/runners sidecar to your existing Docker Compose configuration.
“Help me back up my self-hosted n8n instance.”: The agent will provide the steps to safely export your encryption key, database, and volume data.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/czlonkowski/n8n-self-hosting/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip n8n-self-hosting.zip -d .agents/skills

Documentation by Romuald Czlonkowski

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 / regular	Queue
Processes	one n8n	main + N workers
Extra services	none (SQLite)	Redis (queue) + Postgres (DB)
Executes workflows	in the main process	on workers, in parallel
Good for	1 user, light/moderate load, simplest ops	high volume, heavy/long executions, horizontal scale
Compose	`assets/docker-compose.single.yml`	`assets/docker-compose.queue.yml`
Deep dive	`SINGLE_MODE.md`	`QUEUE_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:

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.
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.
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.
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.
.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.

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.

Files

ATTRIBUTION.mdAdded by AutoGineer889 B
CREDENTIAL_OVERWRITES.md7.9 KiB
DAY2.md8.6 KiB
LICENSELicence file added by AutoGineer1.1 KiB
QUEUE_MODE.md10.3 KiB
README.md5.2 KiB
SECURITY.md8.4 KiB
SINGLE_MODE.md3.6 KiB
SKILL.md13.7 KiB
TASK_RUNNERS.md9.5 KiB
assets/.env.queue.example1.8 KiB
assets/.env.single.example1.4 KiB
assets/Caddyfile1.1 KiB
assets/docker-compose.queue.yml6.7 KiB
assets/docker-compose.single.yml3.0 KiB
assets/init-data.shScript924 B

TASK_RUNNERS.md

Task runners & Python Code nodes

Code nodes (JavaScript and Python) execute inside task runners, not in the n8n process. This file covers switching a Docker deployment to external mode — a n8nio/runners sidecar next to n8n — which is what makes Python Code nodes work and what the docs require for real isolation. Official guide: https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners.

When you need it

Any Python Code node. The official n8nio/n8n image ships no Python 3. In the default internal mode n8n launches the runners as its own child processes, so the Python runner has nothing to start and every Python Code node fails with: Python runner unavailable: Python 3 is missing from this system. JavaScript keeps working in internal mode (Node is in the image), which is why this surprises people. There is no env var that fixes it inside the n8n container — add the sidecar.
Hardening. Internal mode runs user code as the same user, on the same host, as n8n: code that escapes the sandbox can read the database, the encryption key and stored credentials. The docs call external mode the production setup for any instance with sensitive data or more than one person editing workflows.

Ask the user during input collection: "Will workflows use Python Code nodes, or will anyone besides you edit workflows?" A yes to either means external mode.

How the pieces fit

n8n is the task broker. It listens on port 5679, inside the Docker network only — never publish it.
The sidecar (n8nio/runners) holds a launcher plus the JavaScript runner and the Python runner (Python 3.13 on n8n 2.38). The launcher connects to the broker, then starts runner processes on demand and stops them after N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT (default 15 s) idle.
The runner version must equal the n8n version. Drive both images from the same tag variable. The image lives on Docker Hub (n8nio/runners) — there is no docker.n8n.io/n8nio/runners.
External mode moves every Code node, JavaScript included, into the sidecar. JS module allowlists move with it (see "Allowlisting modules").
The launcher config is /etc/n8n-task-runners.json inside the sidecar. It decides which env vars reach each runner (allowed-env) and pins some values (env-overrides).

Single mode: what to add

.env — generate the token on the box, like every other secret (SECURITY.md):

echo "N8N_RUNNERS_AUTH_TOKEN=$(openssl rand -hex 32)" >> .env
# N8N_IMAGE_TAG must be a real version (e.g. 2.38.5) or `stable` — the same value feeds both images

docker-compose.yml — three vars on n8n, plus a new service:

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_IMAGE_TAG:-stable}
    environment:
      # ...existing vars...
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0     # default 127.0.0.1 is unreachable from the sidecar
      - N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}

  task-runners:
    image: n8nio/runners:${N8N_IMAGE_TAG:-stable}     # SAME tag as n8n
    restart: unless-stopped
    environment:
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679   # the n8n service name
      - N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
    # volumes:                                       # only when allowlisting modules (below)
    #   - ./n8n-task-runners.json:/etc/n8n-task-runners.json:ro
    depends_on:
      - n8n
    networks:
      - n8n_net

Then docker compose config -q && docker compose up -d. n8n is recreated, so expect a few seconds of downtime.

Queue mode: one sidecar per worker

Built from the docs and checked with docker compose config. Not yet exercised on a live queue cluster. Verify with the Registered runner log line on every worker before handing off.

The docs are explicit: each worker needs its own runners sidecar, and the main needs one too if OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=false (the template sets true, so the main doesn't).

A launcher connects to exactly one broker, and every worker is its own broker. That breaks the template's deploy.replicas / --scale n8n-worker=N approach. A single task-runners service pointed at http://n8n-worker:5679 attaches to whichever replica DNS returns first. The other workers have no runner, so their Code nodes wait out N8N_RUNNERS_TASK_REQUEST_TIMEOUT (60 s) and fail. Scaling the sidecar to the same count doesn't help either: the pairing is random.

Use explicit pairs instead, one per worker:

  n8n-worker-1:
    <<: *n8n
    command: worker --concurrency=5
  task-runners-1:
    image: n8nio/runners:${N8N_IMAGE_TAG:-stable}
    restart: unless-stopped
    environment:
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n-worker-1:5679
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
    depends_on: [n8n-worker-1]
    networks: [n8n_net]
  # n8n-worker-2 + task-runners-2, … — drop `deploy.replicas` from the worker definition

N8N_RUNNERS_MODE, N8N_RUNNERS_BROKER_LISTEN_ADDRESS and N8N_RUNNERS_AUTH_TOKEN are behavioural. Put them in the x-n8n-env anchor so main and workers agree (the parity rule in QUEUE_MODE.md).
Scaling now means adding a worker plus its runner, not --scale.

Allowlisting modules

Python: every import is blocked by default, even json or datetime. The image's launcher config pins N8N_RUNNERS_STDLIB_ALLOW and N8N_RUNNERS_EXTERNAL_ALLOW to empty strings. The code is rejected before it runs:

Security violations detected
Line 1: Import of standard library module 'datetime' is disallowed. Allowed stdlib modules: none

Setting those vars on the sidecar container does nothing: the env-overrides win, and the docs say to set them in the config file. The recipe:

cd <DATA_FOLDER>
# 1. copy the default from the SAME image version you run
docker run --rm --entrypoint cat n8nio/runners:<tag> /etc/n8n-task-runners.json > n8n-task-runners.json
# 2. edit the "python" runner's env-overrides, e.g.
#    "N8N_RUNNERS_STDLIB_ALLOW": "json,datetime,re,math,statistics,hashlib,base64,urllib,collections,itertools,functools,uuid,zoneinfo,decimal"
# 3. mount it read-only on the sidecar (the commented `volumes:` lines above), then:
docker compose config -q && docker compose up -d --force-recreate task-runners

A module entry includes its submodules (urllib allows import urllib.parse). * allows the whole standard library, including os, sys, subprocess and socket, so don't use it on a shared instance.
Third-party packages (pandas, numpy, …) need a custom image: FROM n8nio/runners:<tag> + RUN cd /opt/runners/task-runner-python && uv pip install pandas. Then list them in N8N_RUNNERS_EXTERNAL_ALLOW. If a package imports modules you haven't listed, set N8N_RUNNERS_ALLOW_TRANSITIVE_IMPORTS=true, but only for packages you trust.
Builtins: eval, exec, compile, open, input, breakpoint, getattr, object, type, vars, setattr, delattr, hasattr, dir, memoryview, __build_class__, globals, locals are removed by default. Code that calls one fails at runtime with name 'eval' is not defined. Dunder attribute access (x.__class__) and __import__() are rejected before execution (Security violations detected). The deny list is N8N_RUNNERS_BUILTINS_DENY.
JavaScript: in external mode NODE_FUNCTION_ALLOW_BUILTIN / NODE_FUNCTION_ALLOW_EXTERNAL are also env-overrides in this file, on the javascript runner. The image default is crypto / moment. Set them there, not on the n8n container.
Timeout: n8n warns that the default N8N_RUNNERS_TASK_TIMEOUT will drop from 300 s to 60 s in a future version. If Code nodes legitimately run long, set it explicitly on n8n and on the sidecar.

The Python language rules this imposes (only _items/_item, bracket access, return shapes) belong to workflow authors — the n8n-code-python skill covers them.

Verify

docker compose ps                                    # n8n + task-runners Up, same tag
docker compose logs n8n | grep 'Registered runner'   # → "launcher-javascript" AND "launcher-python"
docker compose logs task-runners | tail -5           # idle steady state: "Waiting for launcher's task offer to be accepted..."

Smoke test: a workflow with a Code node set to Python containing return [{"json": {"items": len(_items)}}]. The first run after the sidecar has been idle takes ~1–2 s (runner cold start); later runs take ~0.4 s.

Symptom	Cause
`Python runner unavailable: Python 3 is missing from this system`	The process that executed is still in internal mode. Queue mode: check the worker env, not just the main.
Code nodes wait ~60 s, then fail	No runner is connected to that broker: token mismatch, wrong `N8N_RUNNERS_TASK_BROKER_URI`, broker still on `127.0.0.1`, runner/n8n version mismatch, or a queue worker without its own sidecar.
`Security violations detected` / `Import of … is disallowed`	Module not in the launcher-config allowlist (see above).
`name 'open' is not defined` (or another builtin)	Builtin deny list, working as intended.

Upgrades

Bump the shared tag, then docker compose pull && docker compose up -d. n8n and the runners must move together.
If you mounted a custom n8n-task-runners.json, diff it against the new image's default before switching. A newer launcher may add allowed-env entries or runner args that your stale copy would silently drop.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs network access, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

Instructions that use the network
Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Romuald Czlonkowski

Publisher

Romuald Czlonkowski (Community)

Source

czlonkowski/n8n-skills · skills/n8n-self-hosting · commit e037563

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Romuald Czlonkowski or Romuald Czlonkowski.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download n8n-self-hosting.zip