n8n 설치 후 꼭 걸어야 할 설정 — 두 달 500번 재배포에서 배운 것

n8n 설치, 어디에 할까

n8n은 직접 설치(셀프호스팅)하거나 공식 클라우드를 쓰는 두 길이 있다. 우리는 공식 Docker 이미지(n8nio/n8n)를 Railway 같은 PaaS에 올려 쓴다. 설치 자체는 Dockerfile 몇 줄이면 끝난다. 막힌 곳은 설치가 아니라 설치한 다음이었다.

1. 저장소 전체 푸시마다 n8n이 재시작됐다

n8n을 앱 코드와 같은 저장소에 두었더니, 8~9월 두 달 동안 n8n이 500번 재배포됐다. 그중 n8n 폴더를 실제로 바꾼 커밋은 6개였다. 재시작할 때마다 돌던 슬랙 봇 실행이 끊겼고 메모리가 튀었다.

해결은 한 줄이다. Railway면 railway.toml에 watchPatterns = ["/n8n/**"]를 걸어 그 폴더가 바뀔 때만 다시 배포하게 한다. 주의할 점은 이 경로가 서비스 루트 설정과 무관하게 저장소 루트 기준이라는 것이다.

2. 포트와 주소를 고정한다

PaaS는 PORT를 주입하는데 n8n은 N8N_PORT를 본다. 시작 명령에서 N8N_PORT를 PORT로 넘겨준다. 그리고 N8N_LISTEN_ADDRESS=0.0.0.0으로 IPv4에서도 받게 한다. 프록시가 IPv4로 붙는데 앱이 IPv6에서만 기다리면 502가 날 수 있어서 넣어 둔 값이다.

3. 실행 기록은 보존 기한을 정한다

실패한 실행은 전부 남겨야 원인을 볼 수 있다. 대신 EXECUTIONS_DATA_MAX_AGE=336(14일)처럼 기한을 둬서 DB가 계속 커지지 않게 한다. 진단 전송과 버전 알림도 끈다.

이 경험이 답하지 못하는 것

500번이라는 숫자는 우리 저장소 구조에서 나온 것이다. n8n을 별도 저장소에 두었다면 애초에 생기지 않는 문제다. 우리는 이미지 태그를 latest로 쓰고 있어서, 업데이트가 예고 없이 들어오는 위험은 아직 그대로 지고 있다. 운영이 무거워지면 버전을 고정하는 쪽이 맞다.

설치 직후 바로 쓸 수 있는 워크플로가 없다면, 우리가 공개한 스타터 세 개(슬랙 챗봇·웹훅 LLM 응답·에러 통지)를 참고해도 된다: 자동화 서비스