Paano I-self-host ang Dify sa VPS gamit ang Docker Compose

Ano ang Dify, at ano ang ise-set up mong patakbuhin

Ang Dify ay isang self-hostable platform para gumawa ng mga application na gumagamit ng large language models. May web interface ito para magdisenyo ng chat apps, agents, at retrieval pipelines; API para tawagin ang mga ito mula sa sarili mong code; at isang lugar para pamahalaan ang prompts, datasets, at model keys. Ito ang uri ng tool na ise-set up ng isang maliit na team para lahat ay gumamit ng iisang shared private base, sa halip na ikalat ang API keys sa iba’t ibang script. Kung hindi pa malinaw sa iyo ang mga terminong agent, tool call, at retrieval pipeline, ang pag-aaral muna sa mga konseptong ito mula sa simula ay makatutulong para maging pamilyar na controls ang mga screen ng Dify builder sa halip na isang hanay ng mga switch na walang label.

Ang pagpapatakbo nito nang sarili mo ang nangangahulugang magpapatakbo ka ng ilang magkakaugnay na bahagi. Ang Dify ay inilalabas bilang isang set ng Docker containers: isang API server, background worker, web frontend, Postgres database, Redis cache, at vector database, na magkakaugnay gamit ang Docker Compose. Higit ito sa isang single binary, pero ang Compose ang nangangasiwa sa pagkakawiring ng mga ito, at kayang patakbuhin ito nang maayos ng isang VPS na may ilang gigabytes ng ekstrang RAM. Kung may iba pang serbisyo ring tatakbo sa VPS na iyon, sukatin ang kapasidad batay sa nasusukat na paggamit, hindi sa mga ipinapakitang requirement, dahil ang tunay na RAM floor ng PhotoPrism at Immich ay mas mataas kaysa sa kanilang published minimums, at ang photo server na kahati ng box ay unang magpapabigat sa database at vector store ng Dify. Ganito rin ang epekto ng CPU contention: ang Jellyfin library na ginawang parang 90s video store ay halos walang gastos sa pag-serve habang nagba-browse lang ng artwork, pero kapag may nagsimulang mag-transcode, mauuna sa pila ang worker ng Dify. Ang maganda rito, hindi nagbabago ang bilang ng Dify containers gaano man karaming app ang buuin mo rito. Mas banayad ang pagtaas ng resource requirement nito kaysa sa OpenBot, kung saan bawat AI coworker ay may sariling container at sariling browser, at bawat bagong idagdag ay muling nagtataas ng memory floor.

Dahil naglalaman ang Dify ng iyong model API keys at, madalas, ng mga pribadong dokumentong ni-load mo para sa retrieval, ituring na sensitibo ang server na pinapatakbuhan nito mula sa unang minuto. I-i-install ng gabay na ito ang Dify, pagkatapos ay ise-secure ito gaya ng pagse-secure sa anumang serbisyong naglalaman ng mga secret.

Mga Kinakailangan

Kailangan mo ng VPS na nagpapatakbo ng Ubuntu 24.04 na may naka-install na Docker at Docker Compose plugin, pati ng user na may sudo o kabilang sa docker group. Kung bago sa iyo ang Docker, saklaw ng mga pangunahing kaalaman sa Docker Compose sa isang VPS ang installation at mga pangunahing command na ipinapalagay ng gabay na ito. Mainam ding may domain name na nakaturo sa server, dahil gugustuhin mong gumamit ng TLS sa harap ng Dify sa halip na bare IP address.

Hakbang 1: Kunin ang Dify at ang mga Compose file nito

Nasa pangunahing repository ang Docker setup ng Dify. I-clone ito at pumunta sa docker directory:

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

Ang .env file ang naglalaman ng buong configuration. Basahin ito bago ka magsimula. Ang mga unang dapat tingnan ay ang nagtatakda ng mga password at secret: SECRET_KEY, ang Postgres password, at ang Redis password. May placeholder value ang example file, at ang pag-iwan sa mga ito gaya ng pagkakapadala sa file ang pinakakaraniwang dahilan kung bakit nabre-breach ang isang self-hosted Dify. Bumuo ng totoong secret key:

openssl rand -base64 42

I-paste ito sa SECRET_KEY, at magtakda ng malakas at natatanging value para sa bawat password field sa file.

Hakbang 2: Simulan ito

I-start ang stack:

docker compose up -d

Sa unang pag-run, kumukuha ito ng ilang image at ini-initialize ang database, kaya maghintay nang isang minuto. Tiyaking healthy ang mga container:

docker compose ps

Dapat basahin ng bawat serbisyo ang running. Inihahatid ng Dify ang web interface nito sa pamamagitan ng bundled na nginx container sa port 80 bilang default. Sa unang pagbisita mo sa http://YOUR_SERVER/install, gagawin mo ang admin account. Gawin ito agad, bago pa maabot ng iba ang port, dahil hanggang wala ang account na iyon, maaaring i-load ng sinuman ang page, kunin ang account, at mapasakanila ang instance mo.

Hakbang 3: Huwag itong ilantad nang direkta. Maglagay ng TLS at firewall sa unahan

Dito karaniwang nagtatapos ang karamihan sa mabilisang installation, at dito rin nagsisimula ang karamihan sa mga insidente. Nakikinig ang sariling nginx ng Dify sa port 80, nang walang encryption, sa lahat ng interface. Hindi mo gustong dumaan sa plain HTTP ang admin login at mga model key mo. Hindi mo rin gustong maabot mula sa labas ang mga internal service.

I-lock down ang server gamit ang default-deny firewall na nagpapahintulot lamang sa SSH at web traffic:

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

Tandaan na maaaring maiwang bukas sa IPv6 ang parehong mga port kapag IPv4 lamang ang saklaw ng firewall. Ito ang puwang sa IPv6 firewall na madalas nakalulusot sa mga self-hoster. Kumpirmahing naka-filter ang parehong protocol stack.

Para sa TLS, pinakamalinis na paraan ang pag-bind sa web port ng Dify sa loopback at pagpapatakbo ng reverse proxy na may Let's Encrypt certificate sa unahan nito. Sa ganitong setup, ang proxy lamang ang nakikipag-ugnayan sa public internet gamit ang HTTPS. Pinapayagan ka ng .env ng Dify na baguhin ang exposed port. Itakda itong mag-bind sa 127.0.0.1 at ituro roon ang proxy. Nalalapat din dito ang mga ideya sa pag-hardening ng agent sa ligtas na pagpapatakbo ng AI agent sa isang VPS: panatilihin sa loopback ang mga gumagalaw na bahagi, ilantad lamang ang kailangang maging public, at hayaang isang hardened front door ang humawak ng TLS. Kung para sa iyo lamang ang interface ng isang tool at hindi nito kailanman kailangan ng certificate, laktawan ang proxy at maabot ito gamit ang SSH tunnel. Ganiyan pinananatiling naka-bind sa loopback ang dashboard ng self-hosting ng open-kritt security scanner at ipinapasa sa laptop mo sa halip na i-publish. Kung kailangan ng buong team ang Dify ngunit hindi naman dapat maabot ng public internet, maaaring palawakin ng overlay network ang ideyang ito lampas sa isang laptop: sa pag-anunsyo ng private subnet ng server sa iyong tailnet, maaabot ng bawat aprubadong device ang builder gamit ang private address habang sarado ang firewall sa lahat maliban sa SSH. Kung nangangasiwa ka sa server na ito gamit ang coding agent sa halip na mano-mano, itakda muna kung gaano karami ang maaari nitong gawin nang walang supervision bago mo ito bigyan ng mga key. Tinutukoy ng permission mode na iniwan mo sa Claude Code kung hihinto ito upang magtanong bago muling isulat ang .env o i-restart ang stack. Kung may isang session na sumusubaybay sa container logs habang ine-edit ng isa pa ang proxy config, maaaring magpasa ng text sa isa't isa ang dalawang session sa parehong server, kaya hindi mo kailangang paulit-ulit na kumopya ng output sa pagitan ng mga terminal tuwing nire-restart mo ang stack.

Hakbang 4: Panatilihing updated

Mabilis maglabas ng mga update ang Dify, at kasama rito ang mga security fix. Ang pag-update ay isang pull at restart mula sa docker directory:

git pull
docker compose pull
docker compose up -d

Basahin ang release notes bago lumipat sa mas bagong major version. Paminsan-minsan, binabago ng Dify ang .env schema sa pagitan ng mga release. Maaari ring maging sanhi ng hindi pagsisimula ng container ang bagong variable na hindi mo na-set.

Hakbang 5: I-back up ang hindi mo kayang muling buuin

Dalawang bagay sa isang Dify box ang hindi maaaring palitan: ang Postgres database, na naglalaman ng iyong mga app, user, at setting, at ang volume na nag-iimbak ng mga uploaded document at vector index. Pareho silang nasa Docker volumes sa ilalim ng docker directory. Gumawa ng snapshot ayon sa iskedyul, at kopyahin ang mga snapshot sa labas ng server. Nasa iisang file ang lahat ng model key at uploaded document sa mga snapshot na ito, kaya i-encrypt ang mga ito bago ilabas sa box, sa parehong dahilan kung bakit nagiging mahinang punto ang backup ng Vaultwarden sa isang password server na maayos naman ang seguridad. Maaaring mag-issue ulit ng model API key, pero hindi ang app na isang linggo mong binuo. Ganoon din ang batayan sa anumang agent na kailangang manatili ang state kahit magpalit ng machine na nagpapatakbo rito: ang pagpapanatiling tumatakbo sa KiroCrew bilang always-on container ay nakasalalay sa pag-snapshot ng memory at schedule na kung hindi, mawawala sa susunod na reboot.

Kapag gusto mong maabot ng mga agent na binuo mo rito ang lampas sa sarili mong dataset at makapag-search sa live web, ang pagkonekta sa mga ito sa isang self-hosted na SearXNG instance ay nagpapanatili ng query stream sa hardware na kontrolado mo. Gayunman, basahin muna ang prompt injection surface na nalilikha bago ito i-enable. Para sa mas autonomous na agent na nagpapatakbo ng code, tingnan ang self-hosting ng Agent Zero, at tinatalakay ng pagbuo ng sarili mong AI agent sa isang VPS ang mga pundasyong ginagamit ng lahat ng ito.

FAQ

Ano ang mga system requirement para sa self-hosted Dify?

Tumatakbo ang Dify bilang Docker Compose stack na may humigit-kumulang kalahating dosenang container. Kaya gumamit ng VPS na may hindi bababa sa 2 GB na libreng RAM, at mas mainam kung 4 GB. Kailangan din ng ilang CPU core at sapat na disk space para sa mga ina-upload na dokumento at vector index. Ang memory pressure ay pangunahing nagmumula sa database at vector store, hindi sa Dify mismo.

Ligtas bang direktang ilantad ang Dify sa port 80?

Hindi. Nakikinig ang bundled web server ng Dify sa plain HTTP, at pinapadaan dito ang admin login at mga model API key mo. Maglagay ng reverse proxy na may Let's Encrypt certificate sa unahan nito, i-bind ang sariling port ng Dify sa loopback, at ang HTTPS proxy lamang ang dapat direktang ma-access mula sa internet. Isama rito ang default-deny firewall na sumasaklaw sa IPv4 at IPv6.

Paano ko ia-update ang self-hosted Dify?

Mula sa docker directory, patakbuhin ang git pull, pagkatapos ay ang docker compose pull at docker compose up -d upang kunin ang mga bagong image at i-restart ang mga ito. Basahin muna ang release notes, dahil kung minsan ay nagdaragdag ang Dify ng mga bagong .env variable sa pagitan ng mga version. Kapag may nawawalang variable, maaaring hindi magsimula ang isang container.

Ano ang unang dapat gawin pagkatapos i-install ang Dify?

Bisitahin ang /install at agad na likhain ang admin account. Hangga't wala pa ang account na iyon, maaaring angkinin ito ng sinumang makaka-access sa page. I-set up ito sa sandaling healthy na ang mga container, at bago mo buksan ang firewall para sa buong internet.