n8n 셀프호스팅 설치 방법, 도커로 따라하기
- n8n 셀프호스팅은 도커 컨테이너 하나만 실행하면 5분 안에 시작할 수 있습니다.
- 실무에서는 데이터 유실을 막기 위해 docker-compose와 PostgreSQL 연동이 필요합니다.
- 웹훅을 외부 서비스와 연동하려면 반드시 HTTPS 도메인과 리버스 프록시 설정이 필요합니다.
- n8n은 완전한 오픈소스가 아닌 Sustainable Use License이므로 상업적 재판매 조건을 확인해야 합니다.
n8n 셀프호스팅이란? 클라우드와 뭐가 다를까

n8n(엔에이트엔)은 노드(작업 단위)를 드래그로 연결해 반복 업무를 자동화하는 워크플로 자동화 도구입니다. n8n 셀프호스팅은 이 도구를 n8n이 제공하는 클라우드가 아니라 내 서버·개인 PC에 직접 설치해 운영하는 방식을 말합니다. 결론부터 말하면 가장 빠른 설치 방법은 도커(Docker, 애플리케이션을 격리된 컨테이너 단위로 실행하는 기술) 명령어 한 줄이면 충분하고, 실무 운영까지 고려한다면 docker-compose와 데이터베이스 연동까지 30분 정도면 마칠 수 있습니다.
클라우드 버전과 가장 큰 차이는 월 사용료가 없고 데이터가 외부로 나가지 않는다는 점입니다. 대신 서버 관리, 업데이트, 백업을 직접 책임져야 합니다. 개인정보나 사내 시스템 API 키를 다루는 워크플로를 만든다면 셀프호스팅 쪽이 유리하고, 서버 관리 인력이 없다면 클라우드가 더 안전한 선택입니다.
설치 전 확인해야 할 최소 사양과 준비물
서버 최소 사양
n8n 공식 안내 기준으로 워크플로 몇 개를 가볍게 돌리는 개인 프로젝트라면 RAM 1GB, CPU 1코어로도 구동은 됩니다. 다만 여러 워크플로를 동시에 실행하거나 대용량 데이터를 처리하는 업무 자동화라면 RAM 2GB 이상, 디스크 10GB 이상을 권장합니다. 클라우드 VM 기준으로는 오라클 클라우드 프리티어(무료)나 AWS Lightsail 최소 인스턴스로도 테스트 환경을 만들 수 있습니다.
필수 설치 프로그램
도커 방식으로 설치한다면 별도의 Node.js 설치 없이 Docker Engine(또는 Docker Desktop) 하나만 있으면 됩니다. 리눅스 서버라면 다음 항목을 미리 준비하세요.
- Docker Engine 최신 버전 (공식 설치 스크립트 또는 배포판 패키지 매니저 사용)
- 외부 접속이 필요하면 도메인 1개 (서브도메인도 가능)
- HTTPS 인증서 발급을 위한 80/443 포트 개방
- 워크플로 데이터를 저장할 도커 볼륨 (예:
n8n_data,docker volume create n8n_data명령으로 미리 생성)
n8n은 npm으로 직접 설치할 수도 있지만, 버전 충돌과 의존성 문제를 피하려면 도커 기반 설치를 우선 권장합니다. 공식 문서 역시 도커 설치를 표준 경로로 안내하고 있습니다.
n8n 셀프호스팅 설치 방법 (4단계)

가장 널리 쓰이는 단일 컨테이너 방식 기준으로 설치 절차를 단계별로 정리했습니다. 각 단계를 순서대로 따라 하면 됩니다.
1단계: 도커 설치 및 확인
리눅스 기준 아래 명령으로 도커를 설치합니다.
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker
설치 후 docker --version으로 정상 설치를 확인합니다.
2단계: n8n 컨테이너 실행
먼저 데이터를 저장할 도커 볼륨을 만듭니다. n8n 공식 문서는 파일 권한 문제를 피하기 위해 호스트 디렉토리를 직접 연결하는 방식 대신 도커 named volume 사용을 권장합니다.
docker volume create n8n_data
이후 다음 명령으로 n8n 컨테이너를 실행하면 데이터가 이 볼륨에 영구 저장됩니다.
docker run -d --name n8n --restart unless-stopped \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
-e GENERIC_TIMEZONE="Asia/Seoul" \
-e TZ="Asia/Seoul" \
n8nio/n8n
--restart unless-stopped 옵션을 넣어야 서버 재부팅 후에도 컨테이너가 자동으로 다시 실행됩니다. 이 옵션을 빼먹는 실수가 실무에서 가장 흔합니다. 다만 n8n 공식 문서는 이 단일 컨테이너 명령 방식 페이지 자체를 outdated로 표시하고 docker-compose 방식을 표준 경로로 안내하므로, 운영 환경이라면 뒤에서 다룰 docker-compose 구성으로 바로 넘어가는 편이 낫습니다.
3단계: 접속 및 초기 계정 생성
브라우저에서 http://서버IP:5678로 접속하면 최초 1회 관리자 계정(이메일·비밀번호) 생성 화면이 나옵니다. 이 계정 정보는 워크플로 내 자격 증명 암호화와도 연결되므로 분실하지 않도록 별도로 기록해 두세요.
4단계: 외부 서비스 연동을 위한 HTTPS 설정
Slack, Gmail, 결제 서비스 등 외부에서 웹훅(Webhook, 이벤트 발생 시 지정된 URL로 자동 호출되는 콜백)을 호출하게 하려면 반드시 HTTPS 도메인이 필요합니다. Nginx나 Caddy를 리버스 프록시(외부 요청을 받아 내부 서비스로 전달하는 중계 서버)로 두고 Let’s Encrypt 인증서를 발급한 뒤, 컨테이너 실행 시 다음 환경변수를 추가합니다.
N8N_HOST=자신의도메인.comN8N_PROTOCOL=httpsWEBHOOK_URL=https://자신의도메인.com/
테스트 단계에서 도메인 없이 외부 웹훅을 임시로 열고 싶다면 ngrok 같은 터널링 도구로 로컬 5678 포트를 임시 URL에 연결하는 방법도 있습니다. 다만 ngrok 무료 플랜은 URL이 재시작마다 바뀌므로 운영 환경에는 적합하지 않습니다.
데이터 유실 없이 안정적으로 운영하는 법
docker-compose + PostgreSQL 연동
기본 설치는 SQLite(파일 기반 경량 데이터베이스)를 사용하는데, 워크플로가 많아지고 실행 이력이 쌓이면 성능이 떨어집니다. 실무 운영에서는 PostgreSQL을 별도 컨테이너로 함께 띄우는 docker-compose 구성을 권장합니다. 핵심은 n8n 서비스에 DB_TYPE=postgresdb와 접속 정보 환경변수를 지정하고, n8n과 postgres 두 컨테이너를 같은 네트워크로 묶는 것입니다. 이렇게 구성하면 컨테이너를 삭제하고 새로 만들어도 워크플로 데이터가 데이터베이스 볼륨에 남아있어 안전합니다.
백업과 환경변수 보안
백업 대상은 두 가지입니다. 하나는 워크플로·자격증명 데이터가 담긴 볼륨(SQLite 사용 시 n8n_data 도커 볼륨, PostgreSQL 사용 시 DB 볼륨)이고, 다른 하나는 N8N_ENCRYPTION_KEY 환경변수입니다. 이 암호화 키를 잃어버리면 저장된 API 키·비밀번호 자격증명을 복호화할 수 없어 모든 연동을 처음부터 다시 등록해야 합니다. 서버 이전이나 재설치 전에는 반드시 이 키와 볼륨을 함께 백업하세요.
n8n_data는 named volume이라 호스트 파일시스템 경로가 바로 보이지 않으므로, 임시 컨테이너를 하나 띄워 볼륨 내용을 복사하는 방식으로 백업합니다.
docker run --rm -v n8n_data:/from -v $(pwd):/to alpine cp -a /from/. /to/
이 명령을 실행하면 n8n_data 볼륨의 내용이 현재 디렉토리로 복사됩니다. 복원할 때는 새 서버에 동일한 이름의 볼륨을 만든 뒤, 같은 방식으로 이 백업 파일을 볼륨 안에 다시 복사해 넣으면 됩니다.
n8n은 완전한 오픈소스(MIT)가 아니라 Sustainable Use License(SUL, 공정 코드 라이선스) 방식입니다. 소스 코드는 공개되어 있고 내부 업무 자동화용으로 무제한 셀프호스팅이 가능하지만, n8n 자체를 재판매하거나 경쟁 SaaS 상품으로 제공하는 것은 제한됩니다. 사내 자동화 목적이라면 문제없지만, n8n을 상품화해 판매할 계획이라면 라이선스 조건을 반드시 확인해야 합니다.
설치 후 자주 겪는 문제와 해결

웹훅이 외부에서 호출되지 않을 때
로컬에서는 워크플로가 정상 작동하는데 외부 서비스가 웹훅을 못 찾는다면, 대부분 WEBHOOK_URL 환경변수가 실제 접근 가능한 HTTPS 주소로 설정되지 않았기 때문입니다. 방화벽에서 443 포트가 막혀 있거나, 리버스 프록시 설정에서 /webhook 경로가 제대로 전달되지 않는 경우도 흔한 원인입니다.
Code 노드나 Execute Command 노드가 갑자기 막힐 때 (n8n 2.0 이상)
2025년 12월 출시된 n8n 2.0부터는 보안 강화를 위해 기본값이 대거 바뀌었습니다. Code 노드 실행이 격리된 Task Runner에서 기본 실행되어 노드 안에서 환경변수(process.env)에 바로 접근하던 방식이 기본 차단되고, Execute Command·Local File Trigger 노드는 보안상 기본 비활성화됩니다. 옛 버전 습관대로 만든 워크플로를 그대로 옮기면 이 단계에서 막힐 수 있으니, 기존 동작이 꼭 필요하다면 N8N_BLOCK_ENV_ACCESS_IN_NODE=false나 NODES_EXCLUDE 같은 환경변수로 예전 동작을 되살릴 수 있다는 점을 참고하세요. 자세한 변경 내역은 n8n 공식 2.0 Breaking Changes 문서에서 확인할 수 있습니다.
버전 업그레이드 시 워크플로가 깨질 때
n8n은 업데이트 주기가 빠른 편이라 노드 사양이 바뀌면서 기존 워크플로가 오류를 내는 경우가 있습니다. 운영 환경에서는 n8nio/n8n:latest 대신 버전을 고정한 태그(예: n8nio/n8n:2.3x.x)를 사용하고, 업그레이드 전 테스트 서버에서 먼저 검증하는 방식이 안전합니다. 2026년 8월 현재 n8n 2.x대가 안정 버전이며(1.x는 이미 지난 메이저 버전), 정확한 최신 버전은 n8n 공식 체인지로그에서 확인해 고정할 것을 권장합니다.
| 구분 | n8n 클라우드 | 셀프호스팅 |
|---|---|---|
| 비용 | 월 구독료 발생 | 서버 비용만 발생(무료 가능) |
| 데이터 위치 | n8n 서버(해외) | 내 서버(국내 선택 가능) |
| 관리 부담 | 없음(자동 관리) | 업데이트·백업 직접 관리 |
| 커스텀 노드 | 제한적 | 자유롭게 개발·설치 가능 |
실전 활용을 위한 다음 단계
기본 설치가 끝났다면 트리거 노드(스케줄러, 웹훅 등)와 액션 노드(HTTP 요청, 이메일 발송, DB 저장 등)를 연결해 실제 업무 워크플로를 만들어보는 단계로 넘어갑니다. 컨테이너 여러 개를 나눠 운영하거나 트래픽이 커지는 조직 규모라면 단일 서버보다 오케스트레이션 환경을 검토할 시점인데, 이때는 쿠버네티스 클러스터 구축하는 법을 참고해 컨테이너 확장 전략을 함께 설계하면 도움이 됩니다.
자주 묻는 질문
Q. n8n 셀프호스팅은 완전히 무료인가요?
소프트웨어 자체 사용료는 없습니다. 다만 서버 호스팅 비용(클라우드 VM 또는 자체 장비 전기·인터넷 비용)과 도메인·SSL 인증서 비용은 별도로 발생할 수 있습니다. 오라클 클라우드 프리티어처럼 무료 인스턴스를 활용하면 서버 비용도 없앨 수 있습니다.
Q. Windows에서도 셀프호스팅이 가능한가요?
가능합니다. Docker Desktop을 설치하면 WSL2(Windows에서 리눅스 환경을 실행하는 기능) 위에서 동일한 도커 명령으로 n8n을 실행할 수 있습니다. 다만 24시간 상시 운영이 필요하다면 PC를 계속 켜두거나 별도의 클라우드 서버를 쓰는 것이 안정적입니다.
Q. 도커 없이 npm으로 직접 설치해도 되나요?
가능하지만 권장하지 않습니다. Node.js 버전 호환성 문제, 전역 패키지 충돌 등으로 트러블슈팅이 잦고, n8n 공식 문서도 프로덕션 환경에는 도커 설치를 우선 안내합니다. 학습 목적의 단기 테스트라면 npm 설치도 나쁘지 않은 선택입니다.
Q. 설치한 n8n 데이터를 다른 서버로 옮길 수 있나요?
가능합니다. SQLite를 사용 중이라면 앞서 소개한 방식으로 n8n_data 도커 볼륨 내용을 백업해 새 서버에 만든 동일한 이름의 볼륨으로 복사하고, PostgreSQL을 사용 중이라면 데이터베이스 덤프 파일을 새 서버로 옮기면 됩니다. 어느 경우든 동일한 N8N_ENCRYPTION_KEY 값을 그대로 설정해야 기존 워크플로와 자격증명이 정상적으로 복원됩니다.
Q. 셀프호스팅 후 보안은 어떻게 관리해야 하나요?
기본적으로 로그인 화면에 관리자 계정 인증이 걸리지만, 서버 자체 방화벽에서 5678 포트를 외부에 직접 노출하지 않고 리버스 프록시를 통해서만 접근하도록 제한하는 것이 안전합니다. 또한 정기적으로 컨테이너 이미지를 최신 보안 패치 버전으로 갱신하는 것이 좋습니다.
