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-mcp --skill n8n-self-hosting -g -a claude-code -y- Repository
- czlonkowski/n8n-mcp23.2k
- Category
- AI and agents
- Updated
- 8d ago
- License
- MIT
- Context cost
- Mediumabout 2,773 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, set up, provision, or deploy n8n on their own server/VPS/box (Hetzner, DigitalOcean, AWS EC2, bare metal, etc.), in either single/regular mode or queue mode with workers, or to update, back up, restore, or harden such an instance. This is for SELF-HOSTED n8n (Docker), not n8n Cloud and not building workflows. The skill makes the agent ask single-vs-queue first, collect the domain/SSH/timezone inputs, generate fresh secrets on the box, and bring the stack up with TLS. Trigger on "deploy n8n", "self-host n8n", "install n8n on my server", "n8n docker compose", "n8n queue mode / workers / scaling", "n8n reverse proxy / SSL", "back up / update my n8n", or "we don't want to give every user the OAuth client secret" / "enable the Sign in with Google button" (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:
