VPS에서 n8n 셀프 호스팅.
당신의 자동화 엔진, 당신의 자격 증명, 당신의 서버.

n8n은 워크플로우 자동화 엔진입니다. 트리거 — webhook, 스케줄, 데이터베이스의 새 행, 큐의 메시지 — 를 API를 호출하고, 데이터를 변형하고, 조건에 따라 분기하고, 임의의 JavaScript나 Python을 실행하고, 결과를 다음 단계로 넘기는 노드 체인에 연결하는 시각적 캔버스입니다. 수백 개의 연동 노드가 기본으로 딸려 오고, 나머지 모든 걸 커버하는 범용 HTTP Request 노드도 있습니다. 1.x 라인부터는 AI Agent와 LLM 노드도 갖추고 있어서, 2026년에 이걸 설치하는 사람들 상당수가 고전적인 ETL 배관이 아니라 에이전트를 만들고 있는 이유이기도 합니다.

명령어 한 줄 치기도 전에 중요한 부분은 라이선스입니다. n8n은 OSI가 정의하는 의미의 오픈소스가 아니고, 그 차이는 탁상공론이 아니기 때문입니다. 코어는 Sustainable Use License 하에 배포되며, 이는 내부 업무 목적이나 개인·비상업적 용도로 소프트웨어를 사용, 복사, 수정, 배포할 수 있는 비독점적·로열티 없는 전 세계 사용권입니다. 이 라이선스가 주지 않는 것은 n8n이나 그 파생물로 다른 사람에게 요금을 청구할 권리입니다 — 이 조항 때문에 그 위에 유료 "매니지드 n8n" 상품을 짓는 것이 원천적으로 막힙니다. 별개로, 이름에 .ee.가 들어가거나 경로에 .ee가 들어간 파일은 이 라이선스에서 완전히 제외되며 유료 n8n Enterprise License가 필요합니다.

쉽게 풀면 이렇습니다. VPS에서 n8n을 돌려 자기 회사를 자동화하거나, 서비스로 제공하는 자기 클라이언트의 업무를 처리하거나, 자기 개인 생활을 자동화하는 것은 이 무료 조항 안에 있고, 처음부터 그래 왔습니다. n8n을 호스팅 상품으로 파는 것은 아닙니다. 인터넷에서 벌어지는 "n8n이 정말 무료냐" 논쟁 대부분은 바로 이 경계선을 사이에 두고 두 사람이 서로 다른 얘기를 하고 있는 것입니다.

비용 쪽. n8n Cloud는 실행 횟수 기준으로 요금을 매깁니다. Starter 플랜은 연간 청구 기준 월 €20에 2,500회 실행, Pro는 월 €50에 10,000회, Business는 월 €667에 40,000회입니다. 셀프 호스팅에서는 실행 횟수가 아예 청구 항목이 아닙니다 — 그 서버가 가진 CPU와 메모리만큼만 제한을 받을 뿐입니다. 5분마다 API를 폴링하는 워크플로우 하나만 해도 한 달에 8,640회 실행을 태워 버립니다. Cloud에서는 이 워크플로우 하나만으로 이미 Pro 등급을 강제로 써야 하지만, $3.90짜리 VPS에서는 유휴 CPU 대비 오차 범위에 불과합니다.

클라우드 가격은 2026년 8월 기준 n8n.io에 게시된 연간 청구 금액이며, 월간 청구는 이보다 비쌉니다. 여기서 오가는 건 돈만이 아닙니다 — 셀프 호스팅을 선택하면 업그레이드, 백업, TLS 갱신, 가동 시간까지 모두 당신 몫이 됩니다.

패널에서: Order → VPS → Sentinel, 이미지는 Debian 12. 계정을 여는 데 이메일 주소가 필요 없고, 어느 단계에서도 신분증을 요구하지 않으며, 청구는 Monero, Bitcoin, Lightning을 비롯해 지원되는 다른 자산으로 정산됩니다. 서버는 자신과의 지연 시간이 아니라 자동화할 서비스와의 지연 시간을 기준으로 고르십시오 — 자동화 서버는 당신보다 API와 훨씬 더 많이 대화합니다.

그다음, 서버를 건드리기 전에 DNS 레코드부터 만드십시오. n8n.example.com이 VPS의 IPv4를 가리키는 A 레코드, IPv6를 쓴다면 AAAA 레코드까지. 이걸 먼저 해야 하는 이유는, 스택이 시작되는 순간 Caddy가 Let's Encrypt에 인증서를 요청하는데, 해석되지 않는 이름으로 인증서를 요청하면 실패하고 — 그다음 재시도 간격을 늘리며 물러나 버려서, 사이트가 왜 안 열리는지 20분을 고민하게 되기 때문입니다.

DNS가 전파될 시간을 1분 정도 주고, 계속하기 전에 자신의 머신에서 확인하십시오:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

공개 포트에서 뭔가가 리스닝을 시작하기 전에 첫 시간 보안 강화 체크리스트부터 실행하십시오 — 키 전용 SSH, 22, 80, 443 포트만 허용하는 방화벽, 무인 보안 업데이트. 자동화 서버는 자격 증명 금고이니, 그 한 시간을 들일 가치가 있습니다.

디렉터리를 만들고 먼저 두 개의 시크릿을 생성하십시오. 지금, 이 순서대로 생성해서 만들 때마다 .env에 붙여 넣으십시오 — 특히 암호화 키는 n8n이 처음 부팅되기 전에 반드시 존재해야지, 그 후에는 안 됩니다.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

그 파일은 즉시 잠그십시오 — 이 인스턴스가 앞으로 저장할 모든 자격 증명의 열쇠가 그 안에 들어 있습니다:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

짚고 넘어갈 만한 두 가지 설계 결정. 첫째, n8n은 포트를 외부로 공개하지 않습니다. 80과 443은 Caddy만 바인딩하고, n8n은 Compose 네트워크 내부의 5678에서만 리스닝하므로 호스트 바깥에서는 아무도 닿을 수 없습니다. 그런데도 놀랄 만큼 많은 셀프 호스팅 n8n 인스턴스가 앞단 TLS 없이 5678 포트로 공개 인터넷에 그대로 노출돼 있고, 노출된 서비스를 찾는 검색 엔진들이 이를 색인합니다. 둘째, 이제 워크플로우는 PostgreSQL이 보관하는데도 n8n 데이터 볼륨은 여전히 마운트된 채로 남습니다 — 그 디렉터리에는 여전히 인스턴스 설정, 로그 파일, 소스 컨트롤 자산이 들어 있습니다.

가동하십시오:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

부팅되고 에디터가 뜨고 수동 테스트가 도는 n8n이라고 해서 아직 제대로 작동하는 n8n은 아닙니다. 조용히 고장 나는 절반은 인바운드 webhook이며, 마치 외부 서비스 쪽 문제처럼 보이는 방식으로 고장 납니다.

WEBHOOK_URL. 이게 없으면 n8n은 N8N_HOST와 N8N_PORT를 기준으로 webhook URL을 만들어서 http://localhost:5678/webhook/abc 같은 걸 내주는데, 이걸 Stripe나 GitHub에 붙여 넣어 봤자 절대 닿을 수 없습니다. 위의 Compose 파일은 WEBHOOK_URL을 공개 HTTPS 루트로 설정해 두었으며, 이것이 에디터에 표시되고 외부 세계가 실제로 호출할 수 있는 주소입니다.

N8N_EDITOR_BASE_URL. n8n이 보내는 이메일 속 링크 — 비밀번호 재설정, 사용자 초대 — 에 쓰는 공개 URL입니다. 여기가 잘못되면 localhost를 가리키는 초대 링크가 나가는데, 연동이 깨지는 게 아니라 동료가 보내는 지원 티켓으로 나타납니다.

N8N_PROXY_HOPS. n8n은 X-Forwarded-For에서 클라이언트 IP를 읽으며, 이 숫자가 말하는 만큼의 홉만 신뢰합니다. 리버스 프록시가 하나 앞에 있으면 — 이 스택의 Caddy처럼 — 값은 1입니다. Caddy 앞에 Cloudflare까지 두면 2가 됩니다. 기본값 0으로 두면 모든 요청이 프록시 자신에게서 온 것처럼 보이게 되어, 속도 제한이나 워크플로우 안의 IP 기반 로직이 조용히 깨집니다.

N8N_SECURE_COOKIE. 기본값은 true이며, 세션 쿠키가 HTTPS로만 전송된다는 뜻입니다. 이것이 올바른 설정이고 이 스택은 이를 충족합니다. 알아 둘 가치가 있는 이유는, 순수 http로 처음 접속했을 때 나타나는 전형적인 증상을 설명해 주기 때문입니다 — 로그인 폼이 비밀번호를 받아들이고는 다시 로그인 폼으로 돌려보내기를 끝없이 반복하는 증상 말입니다. 해법은 TLS이지, 이 플래그를 꺼버리는 게 아닙니다.

제대로 테스트하십시오. Webhook 노드가 있는 워크플로우를 만들고, 워크플로우를 활성화하고, Production URL을 복사한 다음, 서버가 아닌 다른 머신에서 호출해 보십시오:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

누구나 한 번은 걸려 넘어지는 구분입니다. Test URL은 에디터를 열어 두고 "Listen for test event"를 걸어 둔 동안에만 리스닝합니다. Production URL은 워크플로우가 Active로 토글되어 있을 때만 존재합니다. 에디터에서는 되는데 프로덕션에서 404가 나는 webhook은 거의 항상 비활성 워크플로우 때문입니다.

기본적으로 n8n은 일반 모드(regular mode)로 동작합니다. 에디터를 제공하고 webhook을 받는 프로세스가 워크플로우 실행까지 도맡습니다. 단순하고 문제없이 동작하지만, 긴 워크플로우 하나가 다른 것들을 기다리게 만들기 시작하면 이야기가 달라집니다. 증상은 명확합니다 — 실행이 몇 분 동안 "running" 상태로 멈춰 있고, 에디터는 버벅이고, 200ms 안에 응답해야 할 webhook이 8초 만에 응답합니다.

큐 모드는 작업을 분리합니다. 메인 인스턴스는 에디터, 트리거, webhook 엔드포인트를 맡고 실행 ID를 Redis에 밀어 넣습니다. 별도의 워커 프로세스들이 그 ID를 꺼내어 PostgreSQL에서 워크플로우를 불러오고, 실행하고, Redis를 통해 결과를 보고합니다. 이 아키텍처에서 세 가지 규칙이 따라 나오는데, 셋 다 건너뛴 사람을 물어뜯습니다 — 모든 인스턴스는 같은 PostgreSQL 데이터베이스를 공유해야 하고, 모든 인스턴스는 같은 N8N_ENCRYPTION_KEY를 가져야 하며, SQLite는 아예 지원되지 않습니다.

Compose 파일에 추가되는 것은 Redis 서비스 하나와 워커 서비스 하나로, 워커 서비스는 같은 n8n 이미지를 worker 명령으로 실행한 것입니다:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

메인 n8n 서비스에도 EXECUTIONS_MODE=queue와 QUEUE_BULL_REDIS_HOST=redis를 추가하십시오 — 양쪽이 같은 모드를 사용해야 합니다. 처음부터 설정해 둘 만한 옵션이 두 가지 있습니다. 하나는 OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true로, 에디터에서 "Test workflow"를 눌러도 메인 프로세스가 묶이지 않게 합니다. 다른 하나는 N8N_GRACEFUL_SHUTDOWN_TIMEOUT으로, 기본값은 30초이며 재배포 중 워커가 진행 중인 작업을 마칠 때까지 허용되는 시간을 결정합니다. 워크플로우가 평소 30초를 넘겨 실행된다면 이 값을 늘리십시오. 그러지 않으면 배포할 때마다 진행 중인 작업이 강제 종료됩니다.

여기서부터 시작하지 마십시오. 큐 모드는 움직이는 부품을 두 개 더 추가하고, 일반 모드에는 아예 없는 종류의 장애까지 함께 끌고 옵니다. 큐가 쌓이거나 워크플로우 하나가 다른 것을 막는 게 눈에 보일 때까지는 일반 모드를 유지하고, 그다음에야 두 번째 서버를 늘리기 전에 같은 서버에 워커를 하나 추가하십시오. Sentinel은 일반 모드로, Garrison은 워커 하나로, Ravelin은 워커 셋으로 — 이 진행 순서면 정말로 대규모인 배포를 제외한 모든 경우를 커버합니다.