Dify 설치 가이드 2026: Proxmox에서 Docker Compose로 30분 만에 셀프호스팅 시작

3줄 요약

• 대상: Dify 설치 가이드 2026: Proxmox에서 Docker Compose로 30분 만에 셀프호스팅 시작 내용을 빠르게 파악하려는 독자
• 핵심: 설치·설정·운영 포인트를 핵심 단계 중심으로 정리
• 결과: 재현 가능한 절차와 점검 기준으로 시행착오를 줄임

트러블슈팅

• 증상이 나오면 로그·버전·포트/권한·네트워크 순서로 확인합니다.
• 설정 반영이 안 되면 서비스 재시작/캐시 비우기 후 다시 검증합니다.

결론 + 다음 단계

핵심 절차를 먼저 완료하고, 운영 단계에서는 백업·모니터링·기본 보안 설정을 함께 적용하세요.

• Homelablog 홈에서 관련 가이드 더 보기
• Self Hosting 카테고리 연계 글 보기

3줄 요약

• 대상: Dify 설치 가이드 2026: Proxmox에서 Docker Compose로 30분 만에 셀프호스팅 시작 내용을 빠르게 파악하려는 독자
• 핵심: 설치·설정·운영 포인트를 핵심 단계 중심으로 정리
• 결과: 재현 가능한 절차와 점검 기준으로 시행착오를 줄임

트러블슈팅

• 증상이 나오면 로그·버전·포트/권한·네트워크 순서로 확인합니다.
• 설정 반영이 안 되면 서비스 재시작/캐시 비우기 후 다시 검증합니다.

결론 + 다음 단계

핵심 절차를 먼저 완료하고, 운영 단계에서는 백업·모니터링·기본 보안 설정을 함께 적용하세요.

• Homelablog 홈에서 관련 가이드 더 보기
• Self Hosting 카테고리 연계 글 보기

이 글은 Dify를 Proxmox에서 Docker Compose로 셀프호스팅하는 과정을 정리한다. 설치 이후에 바로 막히는 지점이 “외부 접속/HTTPS/업그레이드/데이터 보존”이라, 운영 관점의 체크포인트를 함께 포함한다.

이 글의 목표(성공 기준)

• Dify 웹 UI가 정상 기동한다.
• 데이터/볼륨 경로가 명확히 분리되어 백업이 가능하다.
• 업데이트 시 “백업 → 업그레이드 → 검증” 순서로 안전하게 진행할 수 있다.

집에서 홈서버를 굴리다 보면, 어느 순간 이런 생각이 듭니다.

“챗봇 하나쯤은 내가 직접 호스팅할 수 있지 않나?”

그 ‘하나쯤’을 진짜로 만들어주는 대표적인 오픈소스가 Dify입니다. 이 글은 Dify 설치를 처음 해보는 분을 위해, Proxmox 환경에서 Docker Compose로 Dify를 올리고(/install 초기화까지), (선택) 외부 접속/모델 연결/백업/업데이트까지 ‘딱 홈랩에서 필요한 만큼’만 정리합니다.

처음부터 너무 거창할 필요는 없어요. 오늘 목표는 딱 하나입니다.

• “내 홈서버에서 Dify 로그인 화면이 뜨게 만들기”

그 다음부터는 옵션으로 확장합니다.

---

이 글에서 하는 것 (오늘의 체크리스트)

• Proxmox에 Dify를 올릴 위치 결정(VM 권장)
• Ubuntu에 Docker / Docker Compose 설치
• Dify 공식 Docker Compose로 기동
• `http://<서버IP>/install`에서 관리자 초기화
• (선택) Dify 포트 변경/리버스 프록시 구성
• (선택) 도메인/HTTPS로 외부 접속
• (선택) OpenAI / Ollama 같은 모델 연결
• 운영에 필요한 기본 보안 설정(UFW, 접근 제한), 백업, 업데이트

---

Dify가 정확히 뭔가요? (초보자 버전)

Dify는 한 문장으로 말하면 LLM 앱(챗봇/에이전트/워크플로우)을 만드는 ‘제작툴 + 운영 플랫폼’입니다.

• 화면에서 앱을 구성하고
• 문서를 올려 지식베이스를 만들고(RAG)
• 원하는 모델(OpenAI 같은 클라우드, Ollama 같은 로컬)을 연결해서
• 팀원에게 배포하거나 API로 서비스에 붙일 수 있어요.

예를 들어 “회사 규정 PDF를 올리고, 팀원들이 질문하면 근거와 함께 답해주는 내부 챗봇”을 내 서버 안에서 돌릴 수 있습니다. ‘외부로 문서가 나가면 곤란한’ 상황에서 특히 매력적이죠.

---

Dify를 직접 호스팅하면 뭐가 좋은가요? (직접 운영 vs 클라우드)

Dify는 클라우드(Dify Cloud)도 있지만, 홈서버로 직접 호스팅하면 장단점이 명확합니다.

구분	직접 호스팅(홈서버)	클라우드(SaaS)
비용	서버 전기/장비는 들지만 사용량 과금 압박이 줄 수 있음	초기 진입 쉬움, 사용량/플랜에 따라 비용 증가 가능
데이터 통제	문서/로그/지식베이스가 내 네트워크 안에 남음	제공자 정책/설정에 좌우
운영 난이도	설치/업데이트/백업을 내가 해야 함	운영 부담이 적음
성능	내 하드웨어/네트워크에 맞춰 튜닝 가능	제공자 환경에 의존

정리하면:

• “데이터는 밖으로 나가기 싫다, 오래 굴릴 거다” → 직접 호스팅이 잘 맞습니다.
• “빨리 써보고 싶다, 운영은 하기 싫다” → 클라우드가 편합니다.

---

Proxmox에서는 VM이 편할까요, LXC가 편할까요?

Dify는 컨테이너가 여러 개(nginx, postgres, redis, weaviate 등) 뜹니다. 그래서 초보자에게는 Ubuntu VM이 압도적으로 쉽습니다.

선택지	추천도	장점	단점
Ubuntu VM (권장)	★★★★★	Docker 공식 문서 그대로 따라가기 쉬움, 트러블슈팅 단순	VM 오버헤드(대부분 체감 적음)
Ubuntu/Debian LXC	★★★☆☆	가볍고 빠름	nesting/cgroup/AppArmor 변수가 많아 초보자에게 어려움

이 글은 Ubuntu VM 기준으로 설명하고, 마지막에 “LXC로 가고 싶을 때 체크할 것”만 짧게 붙여둘게요.

---

준비물 (권장 사양)

공식 최소 사양은 CPU 2코어, RAM 4GB입니다. 다만 실제로는 여유가 있는 편이 훨씬 안정적입니다.

• CPU: 2 vCPU 이상 (4 vCPU면 더 쾌적)
• RAM: 8GB 권장(최소 4GB)
• 디스크: 40GB 이상(문서/RAG를 많이 넣으면 더 필요)
• OS: Ubuntu 22.04 LTS(또는 24.04)

제가 실제로 겪은(?) 흔한 흐름을 그대로 적어보면 이렇습니다.

1. “일단 4GB로 시작하자(절약)”
2. 설치는 성공
3. 문서 몇 개 올리고 RAG 돌려보는 순간, 갑자기 시스템이 ‘숨이 차 보임’
4. docker logs에 뜬금없는 재시작/타임아웃이 보이기 시작
5. 결국 메모리를 올리며… “처음부터 8GB 할걸”

가능하면 처음부터 8GB로 가는 편이 스트레스를 줄여줍니다.

---

0) 설치 전에 해두면 좋은 것(진짜 도움 되는 5가지)

1. Proxmox 스냅샷 하나 찍어두기

• 설치 중 꼬였을 때 ‘되돌리기 버튼’이 생깁니다.

1. VM에 고정 IP 잡아두기

• 나중에 도메인/리버스 프록시 붙일 때 편합니다.

1. 포트 계획 세우기

• 같은 VM에서 이미 80/443을 쓰는 서비스가 있다면, Dify는 다른 VM으로 분리하거나, Dify 포트를 변경해야 합니다.

1. 저장소 계획 세우기(중요)

• Dify는 DB/캐시/벡터DB 등 데이터가 쌓입니다.
• 가능하면 SSD 저장소에 두고, 백업도 함께 생각해두세요.

1. “이 VM은 Dify 전용이다”라고 마음 먹기

• 한 VM에 이것저것 다 올리면 처음엔 뿌듯하지만, 장애가 나면 디버깅이 지옥이 됩니다.

---

1) Proxmox에 Ubuntu VM 만들기 (요약)

이미 Ubuntu가 준비돼 있으면 이 단계는 건너뛰어도 됩니다.

1. Proxmox에서 Create VM 2. CPU 2~4코어, 메모리 8GB 3. 디스크 40GB 이상 (가능하면 SSD) 4. 네트워크는 브리지(vmbr0)로 붙이고, VM에 고정 IP를 잡아두면 이후가 편합니다.

VM에 접속한 뒤, 먼저 업데이트부터 해주세요.

sudo apt update
sudo apt -y upgrade
sudo reboot

• 무엇을 하는지: 패키지 최신화 + 재부팅
• 왜 필요한지: Docker 설치 시 의존성 충돌을 줄입니다.
• 실행 후 확인: 재부팅 후 SSH로 다시 접속되는지

(선택) 시간이 있다면 ‘게스트 에이전트’도 켜두기

Proxmox에서는 QEMU Guest Agent를 켜두면, IP 확인이나 셧다운 같은 운영이 편합니다.

---

2) Ubuntu에 Docker / Docker Compose 설치

Ubuntu에서는 Docker 공식 저장소 방식이 가장 무난합니다.

# 필수 패키지
sudo apt update
sudo apt -y install ca-certificates curl gnupg

# Docker GPG 키 등록
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Docker 저장소 추가
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Docker 설치
sudo apt update
sudo apt -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

• 무엇을 하는지: Docker Engine + Docker Compose 플러그인 설치
• 왜 필요한지: Dify는 Docker Compose로 실행하는 것이 공식 권장 경로입니다.

설치 후 버전 확인:

docker --version
docker compose version
sudo systemctl status docker --no-pager

(선택) sudo 없이 docker 쓰기

매번 sudo를 붙이기 귀찮다면, 사용자 계정을 docker 그룹에 넣을 수 있습니다.

sudo usermod -aG docker $USER
newgrp docker

• 실행 후 확인: `docker ps`가 sudo 없이 동작하는지

(선택) Docker 데이터가 디스크를 너무 먹습니다(데이터 경로 이동)

운영을 오래 하다 보면 /var/lib/docker가 은근히 커집니다.

• VM 디스크가 빡빡한 편이라면
• Docker 데이터를 별도 마운트(예: `/mnt/docker`)로 옮겨두는 것도 방법입니다.

다만 이건 운영자 취향/환경에 따라 다르니, 초보자라면 일단 기본 경로로 성공부터 하는 걸 추천합니다.

---

3) Dify 설치 (공식 Docker Compose 방식)

공식 문서의 핵심은 4줄입니다.

1. 레포지토리 클론 → 2) docker 폴더로 이동 → 3) `.env` 생성 → 4) `docker compose up -d`

# jq가 없으면 설치(최신 릴리즈 태그 자동 선택에 사용)
sudo apt -y install jq

# 최신 릴리즈 태그로 클론(공식 문서 방식)
git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" \
  https://github.com/langgenius/dify.git

cd dify/docker
cp .env.example .env

docker compose up -d

• 무엇을 하는지: Dify 관련 컨테이너를 한 번에 띄웁니다.
• 왜 필요한지: web/api/worker + postgres/redis/weaviate/nginx 등 구성요소가 함께 돌아야 합니다.

3-1) 컨테이너 상태 확인(여기서 80% 결정납니다)

docker compose ps

여기서 모든 컨테이너가 Up 또는 healthy여야 합니다.

• `db_postgres`가 healthy가 아니면: DB 초기화가 아직 끝나지 않았거나, 디스크/메모리 부족일 가능성이 큽니다.
• `weaviate`가 자주 재시작하면: 메모리가 부족한 경우가 많습니다.

추가로, “진짜로 뭔가가 살아 있나?”를 확인할 때는 아래처럼도 확인합니다.

# 컨테이너 리소스 사용량 확인
docker stats --no-stream

# nginx 로그 확인(에러가 여기로 모이는 경우가 많습니다)
docker compose logs -n 200 --no-log-prefix nginx

3-2) 접속 확인

브라우저에서 아래 주소로 들어갑니다.

• 초기화(관리자 생성): `http://<서버IP>/install`
• 로그인 화면(초기화 후): `http://<서버IP>/`

팁: /install은 관리자 계정 생성 후 자동으로 닫히는 편이라, 초기화가 끝나면 더 이상 보이지 않는 게 정상일 수 있습니다.

---

3-3) `.env`에서 꼭 바꿔야 할 값 (필수 보안 설정)

Dify의 Docker Compose는 .env 파일을 많이 참고합니다. 기본값으로도 설치는 되지만, 그대로 외부에 노출하면 위험할 수 있는 값이 포함될 수 있어요.

처음 설치할 때 최소한 아래 항목은 확인/수정하는 것을 권장합니다.

• `SECRET_KEY`: 세션/토큰 관련에 쓰이는 핵심 키
• `DB_PASSWORD`: Postgres 비밀번호
• `REDIS_PASSWORD`: Redis 비밀번호

(버전에 따라 변수 이름/구성이 바뀔 수 있으니, .env.example에 있는 항목을 기준으로 확인하세요.)

SECRET_KEY 만들기 예시

# 32바이트 랜덤 키 생성 예시
openssl rand -hex 32

생성된 값을 .env에 넣고, 파일 권한/백업에 주의합니다.

• 무엇을 하는지: 추측하기 어려운 랜덤 키를 생성
• 왜 필요한지: 기본값/짧은 키는 탈취 시 피해가 커질 수 있습니다.
• 실행 후 확인: `.env`를 수정한 뒤 컨테이너 재기동했는지

docker compose down
docker compose up -d

외부 접속(도메인)에서 가끔 필요한 값

도메인으로 프론트/백을 나눠서 운영하거나, 리버스 프록시를 앞에 두는 경우엔 쿠키/URL 관련 변수를 만질 때가 있습니다.

• `TRIGGER_URL`
• `COOKIE_DOMAIN`, `NEXT_PUBLIC_COOKIE_DOMAIN`

처음부터 이걸 건드리기 시작하면 경우의 수가 늘어나므로, 초보자라면 “단일 호스트/단일 도메인”으로 성공 경험을 먼저 쌓는 것을 추천합니다.

---

3-4) Dify가 띄우는 컨테이너 구성 한눈에 보기

Dify를 띄우면 생각보다 많은 컨테이너가 올라옵니다. 처음엔 “이거 맞나?” 싶지만, 정상입니다.

대략 이런 구성으로 움직인다고 이해하면 트러블슈팅이 쉬워집니다.

구성 요소	역할(쉽게 말하면)	자주 보는 포인트
nginx	웹 진입점(80/443), 라우팅	502/접속 불가 시 로그 먼저 확인
web	콘솔 UI(관리 화면)	화면이 안 뜨면 여기 상태 확인
api / worker	백엔드/API/작업 처리	모델 호출/워크플로우 실행 문제는 여기서 많이 발생
db_postgres	설정/사용자/데이터 저장	healthy 아니면 전체가 흔들림
redis	큐/캐시	worker가 멈춘 듯 보이면 redis도 확인
weaviate(또는 다른 벡터DB)	RAG 검색용 벡터 저장/검색	메모리/디스크 자주 사용
sandbox/ssrf_proxy 등	안전한 실행/프록시 보조	외부 호출 관련 이슈 때 힌트가 됨

“웹이 안 뜬다” → nginx/web → “로그인이 안 된다” → api/db → “RAG가 느리다/죽는다” → weaviate/메모리

이 순서로 보면 삽질을 많이 줄일 수 있어요.

---

3-5) 설치 직후 10분 점검 루틴 (운영자 모드 ON)

Dify를 처음 띄운 직후, 아래를 10분만 점검해두면 이후 운영이 훨씬 편해집니다.

1. 컨테이너 상태

docker compose ps

1. 포트가 실제로 열렸는지

sudo ss -lntp | egrep ':80|:443|:8081|:8443' || true

1. HTTP 응답 확인(서버에서 직접)

curl -I http://127.0.0.1/ | head
# 포트 변경했으면 예: curl -I http://127.0.0.1:8081/

1. 에러 로그 확인(최소한 nginx)

docker compose logs -n 200 --no-log-prefix nginx

1. Proxmox 스냅샷(업데이트 전에도 같은 방식으로)

• 설치가 ‘정상 동작’하는 시점에 스냅샷을 하나 찍어두면, 업데이트/실험이 훨씬 편해집니다.

---

공식 이미지: Dify가 어떤 화면인지 한눈에 보기

Dify를 처음 보는 분이라면, “아, 이런 화면에서 앱과 지식베이스를 만드는구나”가 한 번에 들어오는 게 중요합니다. 아래 이미지는 모두 공식 페이지/공식 문서에서 가져온 캡처입니다.

---

4) 처음 막히는 지점 7가지 (트러블슈팅)

4-1. 포트 충돌: 80/443이 이미 사용 중이에요

Dify 기본 구성은 호스트의 80/443 포트를 씁니다. 같은 VM에서 이미 Nginx/Caddy/다른 서비스가 80/443을 잡고 있으면 충돌이 납니다.

먼저 포트 점유를 확인합니다.

sudo ss -lntp | egrep ':80|:443' || true

해결 방법은 보통 아래 중 하나입니다.

• (가장 깔끔) Dify는 별도 VM으로 분리
• (한 VM에 몰아넣기) Dify 포트 매핑을 바꿔서 8081/8443으로 띄운 뒤, 기존 리버스 프록시로 라우팅

“한 VM에 몰아넣기”는 처음에는 멋있어 보이지만, 장애가 나면 디버깅 난이도가 급상승합니다. 가능한 분리 운영을 추천합니다.

4-2. Dify 포트 변경은 어떻게 하나요?

(버전/구성에 따라 파일 구조가 조금씩 다를 수 있지만) 보통 dify/docker/docker-compose.yaml(또는 yml) 안에서 nginx 서비스의 포트 매핑을 바꿉니다.

예를 들어 기본이 80:80, 443:443라면, 아래처럼 바꿔서 호스트 포트를 8081/8443으로 바꿀 수 있어요.

# 예시입니다. 실제 파일에서 nginx 서비스의 ports를 찾으세요.
services:
  nginx:
    ports:
      - "8081:80"
      - "8443:443"

• 무엇을 하는지: “호스트 포트”만 바꾸고, 컨테이너 내부 포트는 그대로 둡니다.
• 실행 후 확인: `http://<서버IP>:8081/install`로 접속되는지

포트 변경 후에는 재기동이 필요합니다.

docker compose down
docker compose up -d

4-3. /install이 안 열려요 (흰 화면/무한 로딩)

대부분은 컨테이너가 아직 준비 중이거나, DB가 healthy 상태가 아니라서 생깁니다.

docker compose ps

docker compose logs -n 200 --no-log-prefix nginx

• 확인 포인트: `db_postgres`가 healthy인지, `nginx`가 에러 없이 뜨는지

4-4. jq가 없어서 클론이 안 돼요

공식 문서의 “최신 릴리즈 태그” 클론 명령은 jq가 필요합니다.

• 해결: `sudo apt -y install jq`
• 또는 그냥 `git clone https://github.com/langgenius/dify.git`로 클론 후 안내대로 진행해도 됩니다.

4-5. 컨테이너가 ‘계속 재시작’해요

docker compose ps

docker compose logs -n 200 --no-log-prefix weaviate

• 흔한 원인: 메모리 부족(특히 4GB)
• 해결: VM 메모리 증설, 스왑 추가, 또는 사용하지 않는 서비스 정리

4-6. 502 Bad Gateway가 떠요

Dify 앞단의 nginx는 살아 있는데, 내부 웹/백엔드가 아직 준비가 안 됐거나 죽어 있을 때 502가 뜰 수 있습니다.

# nginx 쪽 에러 확인
docker compose logs -n 200 --no-log-prefix nginx

# web/api 쪽 에러 확인
docker compose logs -n 200 --no-log-prefix web
# 또는 api
# docker compose logs -n 200 --no-log-prefix api

제가 겪은 한 번의 경우는, 설치 직후 DB가 healthy 되기 전에 브라우저를 너무 빨리 새로고침하다가 502를 봤습니다. 몇 분 기다린 뒤 다시 접속하니 정상으로 올라오더라고요.

4-7. 디스크가 갑자기 꽉 찼어요

RAG를 쓰거나 로그가 쌓이면, 디스크가 예상보다 빨리 찰 수 있습니다.

# 용량 확인
df -h

# 큰 폴더 찾기(대략적인 감)
sudo du -h /var/lib/docker 2>/dev/null | tail -n 20

• 해결: VM 디스크 확장, 오래된 이미지/컨테이너 정리, 로그 관리

---

5) (선택) 외부에서 접속하기: 도메인 + HTTPS

집 밖에서 접속하려면 크게 두 가지 방식이 있습니다.

1. Cloudflare Tunnel 같은 터널 방식
2. 리버스 프록시(Caddy/Nginx) + 포트포워딩 + 인증서

여기서는 가장 단순한 리버스 프록시 예시만 소개합니다.

5-1. 같은 VM에서 80/443을 이미 쓰는 경우(포트 변경 + 프록시)

• Dify는 8081로 띄우고
• Caddy에서 `dify.example.com` → `http://127.0.0.1:8081`로 프록시

Caddy 예시:

dify.example.com {
  reverse_proxy 127.0.0.1:8081
}

• 무엇을 하는지: 도메인으로 들어오는 요청을 Dify로 전달합니다.
• 왜 필요한지: 홈서버에서 여러 서비스를 운영할 때, 서비스별 도메인 분리가 관리/인증서 면에서 편합니다.
• 실행 후 확인: 브라우저에서 `https://dify.example.com` 접속되는지

5-2. 접근 제어(기본 보안 설정)

외부에 공개한다면 최소한 아래 중 하나는 권장합니다.

• 도메인을 Cloudflare Access 같은 추가 인증으로 감싸기
• 리버스 프록시에서 Basic Auth 적용
• 관리자 페이지(또는 전체 서비스)를 특정 IP만 접근 가능하게 제한

“내가 쓰니까 괜찮겠지”는 홈서버에서 제일 자주 하는 착각입니다. 인터넷은 생각보다 친절하지 않아요.

---

6) (선택) 모델 연결: OpenAI도 되고, Ollama도 됩니다

Dify의 장점은 모델을 바꿔 끼우기가 쉽다는 점입니다.

• 상용: OpenAI, Anthropic 등
• 로컬: Ollama, OpenAI 호환 API 서버(vLLM 등)

6-1. 로컬 LLM에서 제일 흔한 실수: localhost 착각

로컬 LLM을 붙일 때 가장 흔한 실수는 “서버에서 보는 localhost”와 “내 노트북에서 보는 localhost”를 헷갈리는 겁니다.

• Dify 컨테이너 입장에서 `localhost`는 컨테이너 자신입니다.
• 같은 호스트의 Ollama를 바라보려면, 환경에 따라 `host.docker.internal` 또는 호스트 IP를 써야 합니다.

예를 들어 Ollama가 Dify와 같은 VM 호스트에서 돌아간다면:

• Ollama가 11434 포트로 떠 있다면
• Dify에서 base URL을 `http://<호스트IP>:11434` 같은 식으로 맞춰야 하는 경우가 많습니다.

로컬 LLM 연동이 꼬였을 때는 아래 글도 같이 보면 도움이 됩니다.

• (내부 링크) OpenClaw 로컬 LLM 연동 트러블슈팅: https://homelablog.com/openclaw-local-llm-ollama-troubleshooting-2026/

6-2. 모델 연결 전에 꼭 확인할 것

• 내 Dify가 외부로 나가는 트래픽을 허용하는지(방화벽/프록시)
• API 키/토큰은 안전한 곳에 저장하는지
• 서비스 계정이 있다면 ‘개인 키’ 대신 서비스 키를 쓰는지

---

7) Dify vs Flowise vs LangFlow (간단 비교)

“뭐가 제일 좋나요?”라는 질문엔 늘 ‘상황’이 답이지만, 시작할 때 기준은 잡아둘 수 있습니다.

항목	Dify	Flowise	LangFlow
성격	제품형 플랫폼(운영/권한/관측 포함)	가벼운 워크플로우 빌더	시각적 파이프라인 빌더(실험/학습 친화)
RAG/지식베이스	기능이 비교적 풍부	구성/확장 위주	구성/확장 위주
멀티유저/권한	비교적 강함	상대적으로 약함	프로젝트 성격에 따라 다름
운영 난이도	중간(구성 요소 많음)	낮음~중간	낮음~중간
추천 상황	팀/서비스 운영, ‘오래 굴릴’ 앱	개인 프로젝트/빠른 POC	학습/실험, 흐름을 시각화

정리하면:

• “팀에서 쓰고, 계속 굴릴 거다” → Dify
• “가볍게 자동화/흐름만” → Flowise
• “실험하면서 흐름을 눈으로 보고 싶다” → LangFlow

참고로 n8n은 ‘LLM 앱 제작툴’보다는 자동화 플랫폼에 가깝습니다. 다만 둘을 조합하면 재미있어요.

• n8n에서 이벤트/데이터를 모으고 → Dify로 질의/요약을 시키는 식입니다.

---

8) 운영을 위한 기본 보안 설정 체크리스트

Dify는 ‘내 서버에 올렸다’는 순간부터 기본 보안 설정을 신경 써야 합니다.

• 관리자 계정 비밀번호는 길고 복잡하게(패스워드 매니저 권장)
• 외부 공개 시 HTTPS 적용
• (가능하면) 관리자 페이지 접근에 추가 인증/접근 제한
• OS 방화벽(UFW)로 불필요한 포트는 닫기

예시(UFW가 처음이라면 “필요한 것만 열고, 나머지는 닫는다”가 원칙입니다):

sudo ufw allow OpenSSH
# 외부 공개를 한다면
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

• 무엇을 하는지: 기본 방화벽 규칙 적용
• 실행 후 확인: SSH가 끊기지 않는지(제일 중요), 그리고 필요한 포트만 열렸는지

---

9) 백업/업데이트 요령 (최소 단위)

9-1. 백업(가장 작은 단위)

Dify는 크게 3가지만 살리면 복구가 쉬워집니다.

1. `.env` 파일
2. Postgres 데이터
3. 업로드/스토리지 관련 볼륨(환경에 따라)

Postgres 덤프 예시

# db_postgres 컨테이너 ID를 얻어서 덤프
DB_CONTAINER=$(docker compose ps -q db_postgres)

docker exec -t "$DB_CONTAINER" pg_dump -U postgres -d dify | gzip > dify_pg_$(date +%F).sql.gz

• 무엇을 하는지: DB를 덤프해서 파일로 저장
• 왜 필요한지: 설정/사용자/지식베이스 메타데이터가 DB에 들어갑니다.
• 실행 후 확인: 생성된 `dify_pg_YYYY-MM-DD.sql.gz` 파일 크기가 0이 아닌지

추가로 Proxmox 스냅샷을 주기적으로 찍어두면(특히 업데이트 전) 복구가 훨씬 편합니다.

9-2. 업데이트

업그레이드는 릴리즈마다 절차가 달라질 수 있으니, GitHub Releases의 가이드를 따르는 게 가장 안전합니다.

공통적으로는 아래 흐름입니다.

cd ~/dify

git fetch --tags
# 원하는 태그로 체크아웃
# git checkout vX.Y.Z

cd docker
# .env.example 변경 여부 확인 후 .env 반영

docker compose down
# 새 이미지 pull이 필요할 수 있음
# docker compose pull

docker compose up -d

• 실행 후 확인: `docker compose ps`에서 모두 Up/healthy인지, 그리고 웹 접속이 되는지

---

10) (선택) LXC로 설치하고 싶다면 체크할 것

정말로 LXC에 올리고 싶다면, 최소한 아래를 확인하세요.

• LXC에 nesting 허용
• cgroup v2 / AppArmor 이슈
• privileged 컨테이너 여부(권장하진 않지만, 초반에는 이슈가 줄기도 합니다)

초보자라면 “일단 VM으로 성공 경험 → 그 다음 최적화(LXC)” 순서를 추천합니다.

---

11) 같이 보면 좋은 홈랩 글(내부 링크)

• https://homelablog.com/proxmox-%ec%84%a4%ec%b9%98-guide-n100/
• https://homelablog.com/dockge-install-guide-2026/

---

FAQ: Dify 설치 전에 가장 많이 묻는 질문

Q1. Dify 설치는 꼭 Proxmox에서 해야 하나요?

아닙니다. Proxmox가 홈서버에서 VM/LXC로 서비스를 분리 운영하기 좋아서 예시로 든 거예요. 원리는 “Linux + Docker Compose”면 거의 같습니다.

Q2. Dify 설치 후 /install이 사라졌어요. 문제인가요?

대개 정상입니다. 관리자 초기화가 끝나면 /install 페이지 접근이 제한되는 경우가 많습니다.

Q3. 4GB 메모리로도 되나요?

‘켜지긴’ 할 수 있지만, 문서/RAG를 쓰기 시작하면 체감이 급격히 나빠질 수 있습니다. 가능하면 8GB를 권장합니다.

Q4. Dify 설치에 GPU가 꼭 필요한가요?

아닙니다. Dify 자체는 GPU 없이도 잘 돌아갑니다. GPU는 로컬 LLM을 직접 돌릴 때(예: vLLM, llama.cpp 등) 성능에 도움이 되는 영역이에요.

---

마무리

Dify는 ‘AI 앱을 만든다’에서 끝나지 않고, 운영까지 생각한 형태로 묶여 있다는 점이 강점입니다. 그래서 홈서버에서도 “한 번 올려두고 오래 쓰는” 서비스로 만들기 좋아요.

오늘은 Proxmox 위에 Docker Compose로 Dify 설치를 완료하고, 접속/초기화부터 외부 접속과 모델 연결의 길까지 열어뒀습니다. 다음 글에서는 Dify에서 실제로 RAG 지식베이스를 만들고(문서 업로드), 워크플로우를 구성해 ‘쓸만한 앱’으로 다듬는 과정을 다뤄볼게요.

---

참고(공식)

• Dify 공식 사이트: https://dify.ai
• Dify 공식 문서(Docker Compose 배포): https://docs.dify.ai/en/self-host/quick-start/docker-compose.md
• Dify GitHub: https://github.com/langgenius/dify

dify 운영 팁 요약

처음에는 앱을 여러 개 만들기보다 “테스트용 챗봇 1개 + 문서 1개”만 올려서, 응답 속도/로그 패턴/리소스 사용량을 먼저 익히는 게 운영 스트레스를 크게 줄여줍니다.

dify 업데이트 체크 포인트

dify 업데이트 전에는 .env와 DB 덤프를 먼저 남기고, 업데이트 후에는 /install이 아닌 기본 로그인 화면(루트)이 뜨는지와 주요 컨테이너(nginx, api, db_postgres)가 healthy인지 5분만 확인해도 대부분의 회귀 문제를 빠르게 잡을 수 있습니다.