n8n Self-host 배포 — Queue mode · 백업 · Credentials
n8n Cloud 졸업하고 직접 굴리는 production 단계. 시리즈 마지막, 운영 4가지만 챙기면 된다.
2편에서 Docker 로 n8n 을 설치하면서 시작한 시리즈가 마지막 편에 도착했다. 19편까지 워크플로 작성·디버깅·AI Agent 까지 다 다뤘는데, 한 가지가 빠져 있다 — 실제로 production 에서 돌릴 때 필요한 운영 기술. n8n Cloud 가 알아서 해주던 일들을 self-host 에선 본인이 챙겨야 한다.
20편은 4 가지 — Queue mode (확장), 백업 (복구 가능성), Credentials 관리 (암호화 키 함정), Reverse Proxy (외부 노출). 이 넷만 챙기면 시리즈 완결.
1. Queue mode — Redis 워커로 처리량 7배
기본 모드 (Regular mode) 는 메인 프로세스가 모든 워크플로를 직접 실행. 동시 요청이 늘면 webhook 응답이 느려지고, 무거운 워크플로 하나가 다른 워크플로를 막는다. Queue mode 가 이 구조를 분리.
| 역할 | 구성요소 | 일 |
|---|---|---|
| 메인 | n8n main 프로세스 | webhook·schedule 받기, 큐에 job ID 푸시. 직접 실행 안 함 |
| 메시지 큐 | Redis | 대기 job 보관, 가용 워커에 분배 |
| 실행 | n8n worker N 개 | Redis 에서 job 가져와 실행. 워커 수 만큼 병렬 |
| DB | PostgreSQL (SQLite 불가) | 워크플로·실행 이력 영속. 모든 워커가 공유 |
전환 비용 — 컴포넌트가 1개 (n8n) 에서 4개 (n8n main + worker + Redis + Postgres) 로 늘어남. 18편 Postgres 설치가 선행되어야 함. 박준성님 환경처럼 wp-stack 에 Docker Compose 가 이미 있으면 같은 compose 파일에 redis · n8n-worker 서비스 추가가 가장 깔끔.
2. 백업 — 두 볼륨 동시 백업이 절대 규칙
self-host 의 가장 흔한 사고는 "백업은 매일 도는데 복구가 안 되는 상태". 원인은 거의 항상 같다 — n8n 데이터와 Postgres 데이터를 따로 백업해서 시점이 어긋남.
정공법:
- 같은 시점에 두 볼륨 동시 백업 — Docker Compose 전체를
docker compose down후 두 볼륨 tar 압축 → 재기동. 다운타임 1-2분 발생하지만 가장 확실. - 다운타임이 안 되면 — Postgres pg_dump (트랜잭션 일관성 보장) + 동시에 n8n-data 볼륨 스냅샷. 두 명령을 같은 스크립트에 묶고 timestamp 를 같게.
- 복구는 항상 둘 다 같이 — n8n-data 만 복구하지 말고, 같은 timestamp 의 Postgres 도 같이 복원.
3. Credentials — 암호화 키 1 글자 차이의 함정
n8n 의 모든 API 키·OAuth 토큰은 DB 에 저장될 때 N8N_ENCRYPTION_KEY 로 암호화된다. 이 키가 메인·워커 사이 1 글자라도 다르면 워커가 credentials 를 해독하지 못해 워크플로가 다 실패한다.
3 곳에 같은 값을 박는 게 절대 규칙:
- n8n main 컨테이너의
N8N_ENCRYPTION_KEY환경변수 - n8n worker 컨테이너들 각각의
N8N_ENCRYPTION_KEY - 최초 설치 시 자동 생성된
~/.n8n/config파일 안의 키 (있으면 우선)
Docker Compose 의 x-shared-env anchor 로 한 곳에서 정의 + 두 서비스에서 참조하면 안전:
x-shared-env: &shared-env
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
services:
n8n: { environment: *shared-env }
n8n-worker: { environment: *shared-env }
그리고 .env 파일에 N8N_ENCRYPTION_KEY 한 번만 정의. 키 회전 (rotation) 은 절대 가볍게 하지 말 것 — 회전하면 기존 credentials 전부 재입력 필요.
4. Reverse Proxy + Webhook 외부 노출
마지막 단계. n8n 컨테이너의 5678 포트를 외부에 직접 노출하지 말고 Nginx (또는 Caddy·Traefik) reverse proxy 뒤에 둔다. 박준성님의 warehouse 가 이미 junai.ai 에 Nginx 를 쓰고 있으니 같은 패턴.
핵심 설정 4 가지:
- HTTPS — Let's Encrypt 또는 기존 cert. Webhook URL 이 https 여야 외부 서비스 (Slack·Stripe 등) 가 호출 가능
- WebSocket upgrade — n8n UI 의 실시간 실행 모니터링은 ws 연결.
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"필수 - Large body — webhook 으로 파일 업로드 받을 수 있으니
client_max_body_size 50M정도 - WEBHOOK_URL 환경변수 — n8n 컨테이너에
WEBHOOK_URL=https://n8n.junai.ai/명시. 안 그러면 webhook URL 이 내부 IP 로 생성됨
여기까지 끝나면 시리즈 완결. 1편 입문부터 20편 self-host 까지 — n8n 입문자가 production 운영자가 되는 경로 전체.
n8n 교재 시리즈 완결
20편으로 시리즈 마무리. 다음은 React 교재 시리즈 또는 박준성님 워크플로 자동화 사례 (Warehouse + WP) 가 이어집니다.