VPS에 Docker Compose로 Dify 자체 호스팅하기

Dify란 무엇이며, 무엇을 실행하려고 하는가

Dify는 거대 언어 모델 기반의 애플리케이션을 구축하기 위한 자체 호스팅 가능한 플랫폼입니다. 챗봇, 에이전트, 검색 파이프라인을 설계하기 위한 웹 인터페이스와 이를 코드에서 호출할 수 있는 API를 제공하며, 프롬프트, 데이터셋, 모델 키를 한곳에서 관리할 수 있습니다. 이는 소규모 팀이 각자의 스크립트에 API 키를 흩어 놓는 대신, 하나의 공유된 비공개 기반 위에서 모두가 개발할 수 있도록 구축하는 도구입니다.

직접 운영한다는 것은 여러 구성 요소를 함께 운영한다는 뜻이다. Dify는 API 서버, 백그라운드 worker, 웹 frontend, Postgres database, Redis cache, vector database로 구성된 Docker 컨테이너 집합으로 제공되며, 모든 구성 요소는 Docker Compose로 연결된다. 단일 바이너리보다 구성 요소가 많지만, 연결 구성은 Compose가 처리한다. 여유 RAM이 수 GB인 VPS라면 무리 없이 실행할 수 있다. 해당 VPS에서 다른 서비스도 실행할 예정이라면, 광고된 수치가 아니라 실제 측정값을 기준으로 사양을 정해야 한다. PhotoPrism과 Immich의 실제 RAM 최소 요구량은 공개된 최소 요구량보다 훨씬 높기 때문이다. 같은 서버에서 photo server를 함께 실행하면 Dify의 database와 vector store가 먼저 메모리 부족을 겪는다. CPU 경합도 같은 방식으로 문제를 일으킨다. 90년대 비디오 대여점처럼 꾸민 Jellyfin library는 artwork를 탐색하는 동안에는 제공에 거의 자원을 사용하지 않는다. 그러나 누군가 transcode를 시작하는 순간 Dify의 worker queue가 그 작업 뒤에서 대기한다. 그래도 Dify에서 구축하는 app 수와 관계없이 container 수는 고정된다. 이는 각 AI coworker마다 자체 container와 자체 browser가 할당되고 새로 추가할 때마다 memory floor가 다시 올라가는 OpenBot보다 비용 증가 폭이 완만하다는 장점이다.

Dify는 사용자의 모델 API 키와 검색을 위해 업로드한 비공개 문서를 보관하는 경우가 많으므로, 실행하는 서버를 처음부터 민감한 자산으로 취급해야 합니다. 이 가이드는 Dify를 설치한 후, 비밀 정보를 다루는 모든 서비스와 동일한 수준으로 보안을 강화하는 방법을 다룹니다.

사전 요구 사항

Ubuntu 24.04가 설치된 VPS에 Docker와 Docker Compose 플러그인이 설치되어 있어야 하며, sudo 권한을 가진 사용자나 docker 그룹에 속한 사용자가 필요합니다. Docker가 처음이라면 VPS에서 Docker Compose 기초 문서를 참고하십시오. 이 가이드에서 가정하는 설치 과정과 핵심 명령어를 다룹니다. 서버를 가리키는 도메인 이름을 준비하는 것이 좋습니다. Dify 앞단에 IP 주소 대신 TLS를 적용해야 하기 때문입니다.

1단계: Dify 및 Compose 파일 가져오기

Dify는 메인 저장소에서 Docker 설정을 관리합니다. 저장소를 복제하고 docker 디렉터리로 이동합니다.

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

.env 파일은 전체 설정을 담고 있습니다. 작업을 시작하기 전에 이 파일을 읽어보아야 합니다. 가장 먼저 확인해야 할 값은 비밀번호와 보안 키를 설정하는 항목인 SECRET_KEY, Postgres 비밀번호, Redis 비밀번호입니다. 예제 파일은 기본값(placeholder)으로 제공되는데, 이를 그대로 두는 것은 자가 호스팅 Dify가 해킹당하는 가장 흔한 원인입니다. 실제 보안 키를 생성하십시오.

openssl rand -base64 42

생성된 키를 SECRET_KEY에 붙여넣고, 파일 내의 모든 비밀번호 필드에 강력하고 고유한 값을 설정하십시오.

2단계: 서비스 시작

스택을 실행합니다:

docker compose up -d

첫 실행 시 여러 이미지를 내려받고 데이터베이스를 초기화하므로 1분 정도 기다려야 합니다. 컨테이너가 정상 상태인지 확인합니다:

docker compose ps

모든 서비스는 running 상태여야 합니다. Dify는 기본적으로 80번 포트에서 번들로 제공되는 nginx 컨테이너를 통해 웹 인터페이스를 서비스합니다. http://YOUR_SERVER/install에 처음 접속하면 관리자 계정을 생성하게 됩니다. 다른 사용자가 해당 포트에 접근하여 인스턴스 소유권을 가로채지 못하도록, 다른 작업보다 먼저 관리자 계정을 생성하십시오.

3단계: 원본 그대로 노출하지 마십시오. 앞에 TLS와 방화벽을 두십시오

대부분의 빠른 설치가 여기서 멈추고, 대부분의 사고가 여기서 시작됩니다. Dify의 자체 nginx는 모든 인터페이스의 80번 포트에서 암호화되지 않은 상태로 대기합니다. 관리자 로그인 정보와 모델 키가 평문 HTTP로 전송되는 것을 원치 않을 것이며, 내부 서비스가 외부에서 직접 접근 가능한 상태가 되는 것도 원치 않을 것입니다.

SSH와 웹 트래픽만 허용하는 기본 거부(default-deny) 방화벽으로 서버를 보호하십시오:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

IPv4만 다루는 방화벽은 IPv6에서도 동일한 포트를 열어둘 수 있다는 점을 기억하십시오. 이는 많은 자가 호스팅 사용자가 겪는 IPv6 방화벽 격차 문제입니다. 두 스택 모두 필터링되는지 확인하십시오.

TLS를 설정할 때 가장 깔끔한 방법은 Dify의 웹 포트를 loopback에 바인딩하고, 앞단에서 Let's Encrypt 인증서를 사용하는 reverse proxy를 실행하는 것이다. 그러면 공용 인터넷에 노출되는 것은 HTTPS로 통신하는 proxy뿐이다. Dify의 .env로 외부에 노출할 포트를 변경할 수 있다. 이 값을 127.0.0.1에 바인딩하도록 설정하고, proxy가 해당 주소로 요청을 전달하게 한다. VPS에서 AI agent를 안전하게 실행하기에서 설명한 agent 보안 강화 원칙도 여기에 적용된다. 변경되는 구성 요소는 loopback에 두고, 공개해야 하는 항목만 노출하며, 보안이 강화된 단일 진입점에서 TLS를 처리하게 한다. 도구의 인터페이스를 본인만 사용하고 인증서가 전혀 필요하지 않다면 proxy를 생략하고 SSH tunnel로 접속한다. open-kritt 보안 스캐너를 자체 호스팅하기에서는 dashboard를 loopback에 바인딩한 뒤 공개하는 대신 노트북으로 전달한다. 팀 전체가 Dify를 사용해야 하지만 공용 인터넷에는 노출하지 않으려면 overlay network로 이 방식을 여러 장치에 확장할 수 있다. tailnet에 서버의 private subnet 광고하기를 사용하면 승인된 모든 장치가 private address로 builder에 접근할 수 있고, firewall은 SSH를 제외한 모든 연결을 차단한 상태로 유지할 수 있다. 이 장비를 직접 관리하지 않고 coding agent를 통해 관리한다면, 해당 agent에 권한을 넘기기 전에 감독 없이 수행할 작업의 범위를 정해야 한다. Claude Code에 설정해 둔 permission mode에 따라 .env를 다시 작성하거나 stack을 재시작하기 전에 확인을 요청할지 여부가 결정된다. 한 세션에서 container 로그를 계속 확인하는 동안 다른 세션에서 proxy 설정을 수정하게 된다면, 동일한 장비에서 두 세션이 서로 텍스트를 전달할 수 있다. 그러면 stack을 재시작할 때마다 terminal 사이에서 출력을 복사할 필요가 없다.

단계 4: 패치 유지

Dify는 빠르게 발전하며, 업데이트에는 보안 수정 사항이 포함됩니다. 업데이트는 docker 디렉터리에서 pull을 수행한 뒤 재시작하는 방식으로 진행합니다:

git pull
docker compose pull
docker compose up -d

메이저 버전 업그레이드 전에는 릴리스 노트를 확인하십시오. Dify는 릴리스 간에 .env 스키마를 변경하는 경우가 있으며, 설정되지 않은 새로운 변수로 인해 컨테이너가 시작되지 않을 수 있습니다.

5단계: 재생성할 수 없는 데이터 백업하기

Dify 서버에서 대체 불가능한 데이터는 두 가지입니다. 앱, 사용자, 설정을 담고 있는 Postgres 데이터베이스와 업로드된 문서 및 벡터 인덱스를 저장하는 볼륨입니다. 두 데이터 모두 docker 디렉터리 내의 Docker 볼륨에 위치합니다. 이 볼륨들을 주기적으로 스냅샷으로 생성하고 서버 외부로 복사해 두어야 합니다. 모델 API 키는 재발급받을 수 있지만, 일주일 동안 공들여 만든 앱은 그렇지 않습니다. 머신이 재부팅되어도 상태를 유지해야 하는 모든 에이전트도 같은 원칙이 적용됩니다. KiroCrew를 상시 가동 컨테이너로 유지하는 것은 재부팅 시 사라질 메모리와 스케줄을 스냅샷으로 저장하는 작업으로 귀결됩니다.

여기서 구축한 에이전트가 개인 데이터셋을 넘어 실시간 웹을 검색하게 하려면, 직접 호스팅하는 SearXNG 인스턴스를 연결하여 쿼리 스트림을 직접 제어하는 하드웨어 내에 머물게 할 수 있습니다. 다만, 이 기능을 활성화하기 전에 발생할 수 있는 프롬프트 인젝션 공격 표면에 대해 미리 숙지하는 것이 좋습니다. 더 자율적이고 코드를 실행하는 에이전트를 원한다면 Agent Zero 직접 호스팅을 참조하십시오. 또한 VPS에서 직접 AI 에이전트 구축하기에서는 이 모든 서비스의 기반이 되는 기초 지식을 다룹니다.

FAQ

Dify를 자체 호스팅하기 위한 시스템 요구 사항은 무엇입니까?

Dify는 약 6개의 컨테이너로 구성된 Docker Compose 스택으로 실행됩니다. 따라서 최소 2 GB의 여유 RAM(권장 4 GB), 2개 이상의 CPU 코어, 그리고 업로드된 문서와 벡터 인덱스를 저장할 충분한 디스크 공간을 갖춘 VPS를 준비하십시오. 메모리 부하는 Dify 자체가 아닌 데이터베이스와 벡터 저장소에서 발생합니다.

Dify를 80번 포트로 직접 노출해도 안전합니까?

아니요. Dify에 포함된 웹 서버는 일반 HTTP로 수신 대기하며, 관리자 로그인과 모델 API 키를 처리합니다. Let's Encrypt 인증서를 사용하는 리버스 프록시를 앞단에 배치하고, Dify의 포트는 루프백(loopback)에 바인딩하여 HTTPS 프록시만 인터넷에 노출하십시오. 또한 IPv4와 IPv6를 모두 차단하는 기본 거부(default-deny) 방화벽을 함께 설정하십시오.

자체 호스팅된 Dify는 어떻게 업데이트합니까?

docker 디렉터리에서 git pull를 실행한 다음, docker compose pull 및 docker compose up -d을 실행하여 새 이미지를 가져오고 재시작하십시오. Dify는 버전 간에 새로운 .env 변수가 추가되는 경우가 있으며, 누락된 변수는 컨테이너 실행을 방해할 수 있으므로 업데이트 전 릴리스 노트를 먼저 읽어보십시오.

Dify 설치 후 가장 먼저 해야 할 일은 무엇입니까?

/install에 접속하여 즉시 관리자 계정을 생성하십시오. 해당 계정이 생성되기 전까지는 페이지에 접근할 수 있는 누구라도 계정을 선점할 수 있습니다. 컨테이너가 정상적으로 실행되는 즉시, 그리고 방화벽을 외부로 개방하기 전에 설정을 완료하십시오.