SSD Nodes Learn
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-07-24

VPS에 n8n Docker 설치 및 HTTPS 설정 방법

Docker Compose와 Postgres를 사용하여 n8n을 구축합니다. Webhook URL 설정 오류와 encryption-key 관련 문제 등 설치 시 발생하는 주요 에러를 해결하고 HTTPS 환경을 완벽하게 구성하는 방법을 상세히 설명합니다.

구축 목표

n8n은 워크플로우 자동화 도구입니다. Webhook, Schedule, Form submission과 같은 Trigger가 발생하면, API를 호출하고 데이터를 변환하며 다른 시스템에 기록하는 Node 체인을 실행하는 Visual Editor를 제공합니다. n8n은 별도의 서비스 작성 없이도 모든 모델 제공업체 및 데이터베이스와 통신할 수 있어, AI Agent 워크플로우를 위한 표준 도구로 자리 잡았습니다. docker run을 사용하면 2분 안에 편집기를 사용할 수 있습니다. 본 가이드는 나머지 90%의 과정에 집중합니다. 기본 SQLite 파일 대신 Postgres를 사용하여 안정성을 확보하고, HTTPS를 통해 접속 가능하게 하며, 많은 사용자가 실수하는 부분인 Webhook이 외부에서 접근 가능한 URL을 반환하도록 설정하는 방법을 다룹니다.

완성된 스택은 하나의 Docker network 위에 있는 두 개의 Container로 구성됩니다. n8n 본체와 워크플로우 및 자격 증명을 저장하는 Postgres 데이터베이스입니다. Host의 Reverse Proxy가 TLS를 종료하고 localhost의 n8n으로 요청을 전달하므로, Proxy를 통하지 않고 인터넷에 직접 노출되는 서비스는 없습니다. 이 구성은 2026 self-hosting shortlist에 포함된 다른 서비스들과 함께 사용될 수 있습니다.

Prerequisites, and the honest limits

최소 1 GB RAM을 가진 VPS가 필요합니다. 워크플로우가 본격적으로 작동하면 2 GB를 권장합니다. 실행 프로세스와 Node.js 런타임이 메모리를 많이 사용하기 때문입니다. 메모리 부족으로 실행 중 컨테이너가 강제 종료되는 상황을 방지해야 합니다. 시작 단계에서는 단일 vCPU로도 충분합니다.

도메인 또는 서브도메인(예: n8n.example.com)이 필요합니다. 인증서를 요청하기 전에 해당 도메인의 A record가 VPS의 public IP를 가리키도록 설정해야 합니다. 프록시를 위해 80 및 443 포트가 열려 있어야 합니다. n8n의 5678 포트는 인터넷에 직접 노출되지 않아야 합니다. Docker Engine과 Compose plugin이 필요합니다. 만약 docker compose version 실행 시 docker: 'compose' is not a docker command 오류가 발생하면 구형 standalone binary를 사용 중인 것이며, plugin은 sudo apt install docker-compose-plugin입니다.

SQLite는 테스트용으로 적합하며, 신뢰할 수 있는 환경에는 Postgres를 사용하십시오

n8n의 기본 데이터베이스는 /home/node/.n8n/database.sqlite에 위치한 SQLite 파일입니다. 단순 테스트용으로는 적합합니다. 볼륨을 마운트하지 않으면 첫 번째 컨테이너 재생성 시 데이터가 삭제됩니다. Postgres로 전환해야 하는 이유는 단순한 속도 때문이 아닙니다. SQLite는 단일 쓰기 잠금(single writer lock)을 사용합니다. 따라서 여러 워크플로우를 동시에 실행하거나 향후 사용할 큐 모드(queue mode) 환경에서는 동시성 문제로 인해 SQLITE_BUSY: database is locked 오류가 발생합니다. Postgres는 이러한 제한이 없으며, pg_dump를 통해 안정적으로 백업할 수 있습니다. 또한 n8n 공식 문서는 운영 서버 환경으로 Postgres를 가정합니다. 나중에 전환하려면 데이터를 수동으로 마이그레이션해야 합니다. 따라서 중요한 서버라면 처음부터 Postgres를 사용하십시오.

DNS 및 firewall

나중에 인증서 단계에서 이름 해석(resolve) 실패로 인한 오류가 발생하지 않도록, 먼저 레코드를 지정하고 포트를 개방하십시오.

dig +short n8n.example.com
curl -s ifconfig.me
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

5678 포트는 개방하지 마십시오. compose file이 n8n을 127.0.0.1:5678에 바인딩하므로 호스트의 reverse proxy만 접근할 수 있습니다. ufw allow 5678을 사용하면 이러한 격리가 해제됩니다.

The Compose file

작업 디렉터리와 docker-compose.yml을(를) 생성합니다. 이 파일은 전체 스택을 정의합니다. 두 개의 service, 하나의 private network, 두 개의 named volume이 포함됩니다.

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.29.10
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_PROXY_HOPS=1
      - GENERIC_TIMEZONE=Europe/London
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n_net
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n_net:

명시해야 할 몇 가지 결정 사항이 있습니다. DB_POSTGRESDB_HOST=postgres은(는) Docker가 공유 network에서 식별하는 service name입니다. n8n container 내부에서 n8n 자체를 의미하는 localhost이(가) 아닙니다. condition: service_healthy이(가) 설정된 depends_on은(는) 부팅 시 n8n이 Postgres보다 먼저 실행되는 것을 방지합니다. 이 설정이 없으면 n8n이 실행된 후 데이터베이스를 찾지 못해 종료됩니다. /home/node/.n8n에 위치한 named volume n8n_data은(는) encryption key와 SQLite의 경우 database를 저장합니다. 이 디렉터리는 반드시 보존해야 합니다. image는 latest 대신 정확한 version으로 고정하십시오. 이유는 아래 upgrade 섹션에 설명되어 있습니다.

The secrets file

Compose file에 비밀번호를 절대 입력하지 마십시오. Compose가 자동으로 읽을 수 있도록 옆에 .env 파일을 생성하고, 실제 무작위 값이 생성되도록 구성하십시오.

printf 'POSTGRES_PASSWORD=%s\n'  "$(openssl rand -hex 24)" >  .env
printf 'N8N_ENCRYPTION_KEY=%s\n' "$(openssl rand -hex 32)" >> .env
chmod 600 .env

N8N_ENCRYPTION_KEY은 여기서 가장 중요한 문자열입니다. 모든 저장된 자격 증명은 이 키로 암호화됩니다. n8n이 자동으로 생성하게 두지 말고 명시적으로 설정하십시오. 직접 생성한 값은 기록하여 복구할 수 있기 때문입니다. n8n이 이 키로 첫 번째 자격 증명을 암호화하고 나면, 키를 변경할 경우 모든 자격 증명을 복호화할 수 없게 됩니다. 따라서 지금 한 번만 설정하고 해당 라인은 다시 수정하지 마십시오.

Webhook 작동 여부를 결정하는 env vars

n8n이 외부 세계에 자신을 알리는 방식은 네 가지 변수에 의해 제어됩니다. 이 변수들을 잘못 설정하는 것은 n8n 지원 문의 중 가장 빈번한 사례입니다.

  • N8N_HOST은 공개 hostname인 n8n.example.com입니다. 프록시 환경에서 이를 기본값인 localhost로 두면, 에디터가 사용자의 브라우저에서 localhost을 통해 자체 API를 로드하려고 시도하며 이 과정에서 오류가 발생합니다.
  • N8N_PROTOCOL=https은 n8n이 TLS를 통해 서비스됨을 나타냅니다. 이 설정이 활성화되면 세션 쿠키 Secure에 표시를 하고 https:// URL을 생성합니다.
  • N8N_PORT=5678은 컨테이너 내부에서 n8n이 리스닝하는 port입니다. 이는 공개 port가 아닙니다. 443 port는 프록시가 사용합니다.
  • WEBHOOK_URL=https://n8n.example.com/ 설정이 가장 중요합니다. n8n은 이 값들을 조합하여 Stripe, GitHub 또는 기타 외부 호출자에 붙여넣을 webhook 주소를 생성합니다. 이 값이 설정되지 않았거나 잘못되었다면, n8n은 N8N_HOST:N8N_PORT으로 대체하여 https://n8n.example.com:5678/webhook/... 또는 더 심각하게는 http://localhost:5678/webhook/...을 제공합니다. 이 주소들은 오류 없이 출력되어 그럴싸해 보이지만 인터넷에서 접속할 수 없으므로, 호출자의 요청이 전달되지 않고 무시됩니다. 이 값을 마지막에 슬래시(/)가 포함된 정확한 공개 base URL로 설정하십시오. 그 후 webhook node에 포트 번호가 없는 URL이 표시되는지 확인하십시오.

N8N_PROXY_HOPS=1은 n8n의 Express server가 앞단의 프록시 하나를 신뢰하도록 설정합니다. 이를 통해 rate-limiting 및 클라이언트 IP를 읽는 기능들이 프록시 주소가 아닌 실제 주소를 인식할 수 있습니다. 여기서 의도적으로 설정하지 않는 변수는 N8N_RUNNERS_ENABLED입니다. Code-node 로직을 별도의 sandboxed process에서 실행하는 task runners는 1.69 버전부터 기본값이며, 이 가이드에서 다루는 2.x 버전부터는 필수 사항입니다. 따라서 이전의 opt-in 방식은 deprecated되었습니다. 지금 이 값을 설정하면 n8n은 해당 설정을 제거하라는 알림 로그를 출력합니다.

First start

docker compose up -d
docker compose ps
docker compose logs -f n8n

정상적인 첫 부팅은 Editor is now accessible via: 라인으로 종료되며, 그 바로 위에 n8n ready on ..., port 5678 라인이 나타납니다. docker compose ps은 두 컨테이너의 Up 상태를 보여주어야 하며, postgres은 (healthy) 상태로 표시되어야 합니다. 만약 n8n이 Restarting 루프에 빠진다면 로그를 확인하십시오. 대부분의 경우 아래에서 설명하는 database connection 또는 volume permissions 문제입니다.

TLS with a reverse proxy

n8n은 5678 포트에서 일반 HTTP를 사용합니다. HTTPS를 종료하려면 앞에 별도의 프록시가 필요합니다. 두 가지 방법이 있습니다.

이미 여러 개의 컨테이너를 실행 중이라면, n8n을 TLS 인증서를 자동으로 발급하는 Traefik reverse proxy 뒤에 배치하십시오. 몇 개의 label을 추가하면 Traefik이 인증서를 요청하고 갱신합니다.

서버에서 이 앱만 실행 중이라면, Let's Encrypt 인증서를 사용하는 nginx virtual host가 더 간단합니다. Ubuntu 24.04용 Certbot 및 nginx TLS 설정을 사용하여 인증서를 발급받은 후, 아래의 server block을 사용하십시오:

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate     /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600;
        client_max_body_size 16m;
    }
}

Upgrade 및 Connection "upgrade" 헤더는 필수입니다. n8n은 WebSocket을 통해 에디터로 실시간 실행 업데이트를 전송합니다. 이 두 줄이 없으면 로그인 페이지가 로드된 후 연결 끊김 배너와 함께 멈춥니다. proxy_read_timeout 3600은 실행 시간이 긴 작업이 nginx의 기본값인 60초 후에 끊기는 것을 방지합니다. X-Forwarded-Proto $scheme 헤더는 N8N_PROXY_HOPS=1와 함께 사용됩니다. 이 헤더는 프록시가 일반 HTTP로 접속하더라도 원래 요청이 HTTPS였음을 n8n에 알립니다. 이를 통해 n8n이 연결을 안전하지 않다고 판단하여 쿠키를 거부하는 것을 방지합니다.

실제 워크플로우를 처음으로 구축하기

https://n8n.example.com/를 실행하고, 소유자 계정을 생성한 뒤(다음 섹션 참조), 경로가 정상 작동하는지 확인하기 위한 가장 간단한 워크플로우를 구축합니다. 구성은 Webhook 수신, HTTP 호출, 응답 전송입니다.

  1. Webhook 노드를 추가합니다. Method를 POST로 설정하고, Path를 hello와 같이 지정합니다. Test URL과 Production URL 두 가지 URL이 표시됩니다. "Webhook이 작동하지 않는다"는 문제 보고의 절반은 이 두 URL의 차이에서 발생합니다. Test URL은 Listen for test event를 클릭했을 때 한 번의 호출에만 응답하며, 이후 만료됩니다. Production URL은 워크플로우가 Active 상태일 때 항상 응답합니다.
  2. 그 뒤에 HTTP Request 노드를 추가합니다. 공개 JSON API를 대상으로 설정합니다. https://api.github.com/zen로 GET 요청을 보내면 한 줄의 문자열이 반환되며, 이는 테스트용으로 충분합니다.
  3. Respond to Webhook 노드를 추가합니다. Webhook 노드의 Respond 옵션을 "Using Respond to Webhook node"로 설정합니다. 이렇게 하면 호출자에게 HTTP 노드의 출력값이 반환됩니다.
  4. 워크플로우를 Active 상태로 전환(우측 상단)한 후, curl -X POST https://n8n.example.com/webhook/hello로 호출합니다. POST 요청, API 호출, 응답 전송이 이루어지며, 이는 대부분의 실제 자동화 구조와 동일합니다.

스케줄링 방식은 Webhook 노드 대신 Schedule Trigger를 사용하며, 모델 엔드포인트를 호출합니다. Ollama running on the same VPS를 사용하여 자체 호스팅된 엔드포인트를 호출하는 방식은 야간 요약기(nightly summariser)를 구축하는 효율적인 방법입니다.

User management, not basic auth

이전 n8n 가이드에서는 N8N_BASIC_AUTH_ACTIVE=true 설정을 권장합니다. 해당 변수들은 n8n 1.0 버전에서 제거되었으며 현재는 아무런 동작을 하지 않습니다. 현재 인증 방식은 owner account를 기반으로 합니다. 에디터를 처음 실행하면 n8n은 이메일과 비밀번호를 사용하는 owner 계정 생성을 요구합니다. 이 단계는 필수이며 익명 모드는 제공되지 않습니다. URL을 타인에게 전달하기 전, 첫 부팅 직후에 계정을 생성하십시오. docker compose up 단계와 첫 양식 제출 사이에는 해당 인스턴스에 접속하는 누구나 소유권을 가져갈 수 있습니다. Reverse-proxy의 basic-auth 계층을 추가하는 것은 유용한 보안 조치이지만, 이는 2차 인증일 뿐 실제 인증 방식은 아닙니다.

Backups: 암호화 키를 먼저 백업한 후 데이터베이스를 백업하십시오

백업해야 할 대상은 두 가지이며, 두 대상의 중요도는 동일하지 않습니다.

N8N_ENCRYPTION_KEY. n8n에 저장된 모든 자격 증명(API tokens, database passwords, OAuth secrets)은 이 키를 사용하여 저장 시 암호화됩니다. Postgres 내의 workflow는 이 키가 없으면 사용할 수 없습니다. 다른 키가 설정된 새 서버에 데이터베이스를 복구하면 n8n은 자격 증명을 하나도 복호화할 수 없습니다. 복구하거나 재설정할 방법이 없습니다. .env 파일에 키가 저장됩니다. 파일을 생성하는 즉시 서버 외부의 안전한 곳(password-manager 권장)에 복사해 두십시오. 이것이 가장 중요한 백업입니다.

Postgres database: workflow, 실행 이력(execution history), 암호화된 자격 증명 자체를 백업합니다.

docker compose exec -T postgres pg_dump -U n8n -d n8n \
  | gzip > n8n-db-$(date +%F).sql.gz

이 명령어를 스케줄에 따라 실행하고 dump 파일을 서버 외부로 복사하십시오. 새 VPS에 복구하는 방법은 다음과 같습니다: stack을 한 번 실행하여 데이터베이스를 생성합니다. n8n을 중지합니다. psql를 사용하여 dump 파일을 다시 로드합니다. 동일한 N8N_ENCRYPTION_KEY를 .env에 넣습니다. n8n을 시작합니다. 동일한 키와 dump 파일이 있으면 정상적인 인스턴스가 됩니다. 키가 다르면 workflow가 있어도 자격 증명을 전혀 사용할 수 없습니다.

Upgrades: pin the tag

compose file는 의도적으로 latest 대신 n8nio/n8n:2.29.10를 사용합니다. n8n은 거의 매주 새로운 minor 버전을 출시하며, 이 과정에서 데이터베이스 스키마나 node 동작을 변경하기도 합니다. 따라서 latest를 사용하면 자동 pull 시 실행 즉시 데이터베이스 마이그레이션이 수행되는 빌드가 설치될 수 있습니다. 버전을 고정(pin)하십시오. 버전을 올리기 전에 release notes를 읽으십시오. n8n은 해당 문서에 breaking changes를 명시합니다. 업그레이드는 신중하게 진행하십시오.

docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > pre-upgrade.sql.gz
# edit the image tag in docker-compose.yml, then:
docker compose pull n8n
docker compose up -d n8n
docker compose logs -f n8n

Major-version 변경 시 이 사항이 가장 중요합니다. 예를 들어, 2.0 버전은 기본값을 N8N_BLOCK_ENV_ACCESS_IN_NODE에서 true로 변경했습니다. 따라서 process.env를 읽던 모든 Code node는 false로 다시 설정하기 전까지 액세스 권한을 상실합니다. 또한 동일한 릴리스부터 settings file에 대한 엄격한 권한 적용이 시작되었습니다. Major 버전을 넘어가기 전에 2.0 breaking-changes page를 읽으십시오. n8n은 시작 시 필요한 모든 데이터베이스 마이그레이션을 자동으로 실행합니다. 이것이 업그레이드 전 pg_dump가 필수적인 이유입니다. credentials는 .env 내의 키로 암호화되어 저장되고 데이터는 Postgres에 저장되므로, 컨테이너는 교체 가능한(disposable) 상태입니다. 컨테이너를 교체하여 업그레이드를 수행하고, 이전 태그를 고정하고 dump를 복구하여 롤백을 수행하십시오.

Failure modes, with the strings you will see

The requested webhook "POST hello" is not registered. workflow가 Active 상태가 아닌 webhook을 호출하거나, 대기 중인 프로세스가 없는 상태에서 test path를 호출할 때 발생하는 404 오류입니다. Test paths (/webhook-test/...)는 "Listen for test event"를 클릭했을 때만 응답합니다. production paths (/webhook/...)는 workflow toggle이 켜져 있을 때만 응답합니다. 인접한 This webhook is not registered for GET requests. Did you mean to make a POST request? 오류는 HTTP method가 잘못되었음을 의미합니다. 노드는 POST를 기다리지만 GET를 보낸 경우입니다.

webhook URL에 :5678 또는 localhost이 표시됩니다. 노드에 https://n8n.example.com:5678/webhook/... 또는 http://localhost:5678/...이 표시됩니다. WEBHOOK_URL가 설정되지 않았거나 잘못되어 n8n이 public base 대신 N8N_HOST:N8N_PORT을 사용하여 주소를 생성했습니다. WEBHOOK_URL=https://n8n.example.com/를 설정하고 docker compose up -d를 사용하여 컨테이너를 다시 생성하면 포트 문제가 해결됩니다.

브라우저에 There was a problem loading init data이 표시됩니다. 에디터는 로드되었으나 자체 backend API에 도달할 수 없는 상태입니다. 프록시 환경에서는 대부분 N8N_HOST 또는 WEBHOOK_URL 설정 오류, WebSocket Upgrade 헤더 누락, 또는 N8N_PROTOCOL과 접속 방식의 불일치로 인해 발생합니다. 4개의 public-facing 변수 설정과 프록시가 Upgrade 및 Connection를 전달하는지 확인하십시오.

로그에 password authentication failed for user "n8n"이 발생하며 컨테이너가 재시작됩니다. n8n이 전송하는 비밀번호가 데이터베이스 초기화 시 사용된 비밀번호와 일치하지 않습니다. 주의할 점은 Postgres가 비어 있는 data directory를 초기화할 때만 POSTGRES_PASSWORD를 읽는다는 것입니다. 스택을 한 번 실행한 후, .env에서 POSTGRES_PASSWORD를 변경하면 기존 postgres_data volume에는 이전 비밀번호가 남아 있습니다. 원래 비밀번호로 되돌리거나, 보존할 데이터가 없다면 postgres volume을 docker compose down 및 docker volume rm한 후 새로 실행하십시오.

시작 시 EACCES: permission denied, open '/home/node/.n8n/config' 오류가 발생합니다. n8n이 node user (UID 1000)로 실행되어 config directory에 쓰기 권한이 없습니다. 이는 root 소유의 호스트 폴더 (./n8n_data:/home/node/.n8n)를 bind-mount할 때 발생합니다. 위에 설명된 named volume을 사용하거나, bind mount를 반드시 사용해야 한다면 먼저 sudo chown -R 1000:1000 ./n8n_data을 수행하십시오.

Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide. Changing permissions to 0600.. n8n 2.x 버전부터는 기본적으로 해당 settings file에 0600을 적용하며 부팅 시 이를 스스로 수정합니다. 이 로그 라인은 이미 모드가 수정되었음을 의미합니다. 주로 bind mount를 사용하거나 복구 과정에서 권한이 느슨한 상태로 파일이 복사된 경우에 발생합니다. 별도의 조치는 필요하지 않습니다. 파일 시스템이 권한 설정을 지원할 수 없는 경우에만 N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false을 설정하십시오.

Mismatching encryption keys — 전체 로그를 보면 settings file의 encryption key (/home/node/.n8n/config)가 환경 변수의 N8N_ENCRYPTION_KEY와 일치하지 않는다고 나옵니다. 환경 변수의 키가 n8n이 이전 실행에서 data volume에 기록한 키와 다를 때 발생합니다. 대개 변수가 설정되지 않은 상태에서 n8n이 무작위 키를 생성한 후, 나중에 다른 키를 설정했을 때 발생합니다. 원래 키를 .env에 다시 입력하십시오. 보존할 자격 증명이 전혀 없는 경우에만 config 파일을 n8n_data volume 내부에서 삭제하여 n8n이 재생성하도록 하십시오. 이 경우 기존 자격 증명은 읽을 수 없게 됩니다.

보안 쿠키 관련 로그인 배너: Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari. N8N_PROTOCOL=https를 설정했지만 HTTPS 프록시 대신 IP와 포트로 직접 접속하여 plain HTTP를 통해 n8n에 도달한 경우입니다. https://n8n.example.com/를 통해 접속하십시오. HTTPS를 정말로 사용할 수 없는 경우에만 N8N_SECURE_COOKIE=false을 설정하십시오. 인터넷에 노출된 서버에서는 절대 설정하지 마십시오.

workflow 내에 언어 모델을 포함하려면 building AI workflows with Claude and n8n을 참조하십시오.

FAQ

n8n에 SQLite를 사용해야 합니까, 아니면 Postgres를 사용해야 합니까?

n8n을 테스트하거나 한 번에 하나의 workflow만 실행하는 개인용 인스턴스라면 SQLite(기본값)로 충분합니다. 중요한 작업을 수행한다면 Postgres로 전환하십시오. SQLite는 단일 writer lock 방식이므로 동시성 발생 시 database is locked 오류가 발생합니다. 반면 Postgres는 pg_dump을 사용하여 백업이 안정적입니다. 나중에 마이그레이션하는 과정은 수동으로 이루어지므로, 데이터가 중요하다면 처음부터 Postgres를 사용하십시오.

n8n webhook이 실행되지 않는 이유는 무엇입니까?

대부분 WEBHOOK_URL 때문입니다. N8N_HOST:N8N_PORT이 설정되지 않았거나 잘못 설정된 경우, n8n은 :5678 또는 localhost이 포함된 webhook 주소를 생성합니다. 이 주소는 형식상으로는 유효해 보이지만 인터넷에서 접속할 수 없으므로 호출자의 요청이 전달되지 않습니다. WEBHOOK_URL=https://n8n.example.com/을 설정하고 노드에 포트 번호가 없는 URL이 표시되는지 확인하십시오. 두 번째 원인은 workflow가 Active 상태가 아닌 webhook을 호출하는 것이며, 이 경우 The requested webhook ... is not registered.를 반환합니다.

n8n에서 무엇을 백업해야 합니까?

두 가지가 필요합니다. 첫째, .env 파일의 N8N_ENCRYPTION_KEY입니다. 모든 저장된 credential은 이 키로 암호화되므로, 키를 분실하면 영구적으로 복호화할 수 없습니다. 파일을 생성한 당일에 서버 외부로 복사해 두십시오. 둘째, workflow, history, credentials를 위해 Postgres 데이터베이스의 pg_dump이 필요합니다. 복구하려면 동일한 키와 dump 파일이 모두 있어야 합니다.

n8n에 HTTPS를 어떻게 적용합니까?

n8n은 5678 포트에서 plain HTTP를 제공합니다. 앞에 reverse proxy를 배치하여 TLS를 종료하십시오. n8n을 127.0.0.1:5678에 바인딩하여 proxy만 접근할 수 있도록 설정한 뒤, automatic certificates 기능이 있는 Traefik을 사용하거나 Let's Encrypt 인증서가 있는 nginx를 사용하십시오. N8N_PROTOCOL=https 및 WEBHOOK_URL=https://your-host/을 설정하고, proxy가 WebSocket Upgrade 헤더를 전달하도록 설정해야 합니다. 그렇지 않으면 editor가 멈출 수 있습니다.

n8n을 안전하게 업그레이드하는 방법은 무엇입니까?

latest 대신 특정 image tag를 고정하십시오. n8n은 시작 시 자동으로 migration을 수행하므로 먼저 pg_dump을 수행해야 합니다. breaking changes에 대한 release notes를 읽은 후, tag를 변경하고 docker compose pull n8n && docker compose up -d n8n를 실행하십시오. 컨테이너는 삭제 가능한 구조이므로, 이전 tag를 고정하고 업그레이드 전의 dump를 복원하여 롤백할 수 있습니다.

#n8n#automation#docker#self-hosting#https