N8n Self Hosting
Deploy a production self-hosted n8n end-to-end to a fresh Linux VM over SSH, using...
Install
npx skills add czlonkowski/n8n-skills --skill n8n-self-hosting -g -a claude-code -y- Repository
- czlonkowski/n8n-skills6.6k
- Category
- AI and agents
- Updated
- 11d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- Yes, review before use
What it does
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 / 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:
