Cara Self-Host Dify di VPS dengan Docker Compose

Apa itu Dify dan apa yang akan Anda jalankan

Dify adalah platform yang dapat di-hosting sendiri untuk membangun aplikasi di atas large language model. Anda mendapatkan antarmuka web untuk merancang aplikasi chat, agent, dan pipeline retrieval, API untuk memanggilnya dari kode Anda sendiri, serta satu tempat untuk mengelola prompt, dataset, dan key model. Tool ini cocok digunakan oleh tim kecil agar semua orang membangun aplikasi di atas satu basis privat yang sama, bukan menyebarkan key API di berbagai script. Jika istilah seperti agent, tool call, dan pipeline retrieval masih belum jelas, mempelajari konsep tersebut dari dasar terlebih dahulu akan membuat layar builder Dify terasa seperti kumpulan kontrol yang mudah dipahami, bukan deretan switch tanpa label.

Menjalankannya sendiri berarti menjalankan banyak komponen. Per Oktober 2026, stack default Dify yang didokumentasikan memulai 15 container yang berjalan terus-menerus, ditambah satu task satu kali yang mengatur permission file lalu berhenti. Tujuh di antaranya adalah service milik Dify: API server, websocket server, background worker, scheduler, web frontend, plugin daemon, dan agent backend. Delapan lainnya adalah dependency: database Postgres, cache Redis, database vector Weaviate, nginx sebagai pintu masuk, dua code sandbox, dan dua proxy SSRF. Docker Compose menghubungkan semuanya, tetapi ini tetap merupakan stack yang nyata. Minimum yang didokumentasikan Dify adalah RAM 4 GiB dan dua core CPU. Jika VPS tersebut juga akan menjalankan layanan lain, tentukan ukurannya berdasarkan angka hasil pengukuran, bukan angka yang diiklankan, karena batas minimum RAM PhotoPrism dan Immich yang sebenarnya jauh lebih tinggi daripada minimum yang dipublikasikan. Server foto yang berbagi VPS tersebut akan lebih dahulu menghabiskan resource database dan vector store Dify. Perebutan resource CPU juga berdampak serupa: library Jellyfin yang diubah tampilannya menjadi toko video era 90-an hampir tidak membutuhkan resource saat hanya digunakan untuk menjelajahi artwork, tetapi begitu seseorang memulai transcoding, antrean worker Dify harus menunggu. Keuntungannya, jumlah container Dify tetap sama berapa pun jumlah aplikasi yang Anda bangun di atasnya. Pola biayanya lebih ringan daripada OpenBot, yang memberikan container dan browser sendiri untuk setiap rekan kerja AI, karena setiap penambahan rekan kerja kembali menaikkan batas minimum memory.

Karena Dify menyimpan key API model Anda dan sering kali dokumen privat yang Anda muat untuk retrieval, perlakukan server tempat Dify berjalan sebagai sistem sensitif sejak awal. Panduan ini memasang Dify, lalu mengamankannya seperti Anda mengamankan service apa pun yang menyimpan secret.

Prasyarat

Anda memerlukan VPS yang menjalankan Ubuntu 24.04 dengan RAM minimal 4 GiB dan dua core CPU, Docker dengan plugin Docker Compose yang telah terpasang (Dify memerlukan Compose 2.24.0 atau yang lebih baru), serta pengguna dengan sudo atau keanggotaan dalam grup docker. Perintah clone di bawah ini juga menggunakan git, curl, dan jq. Jika Docker masih baru bagi Anda, dasar-dasar Docker Compose pada VPS membahas instalasi dan perintah inti yang digunakan dalam panduan ini. Sebaiknya Anda memiliki nama domain yang diarahkan ke server, karena Anda akan memerlukan TLS di depan Dify, bukan alamat IP langsung.

Langkah 1: Dapatkan Dify dan file Compose-nya

Dify menyimpan konfigurasi Docker-nya di repositori utama. Clone rilis terbaru, bukan branch pengembangan, lalu masuk ke direktori docker:

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

Jika clone gagal dengan error "Remote branch null", pencarian melalui GitHub API tidak mengembalikan hasil. Pilih versi dari halaman releases, lalu teruskan versi tersebut ke --branch secara manual.

File .env adalah konfigurasi inti. Baca file ini sebelum menjalankan apa pun. Nilai yang perlu diperhatikan terlebih dahulu adalah nilai yang menetapkan password dan secret: SECRET_KEY, password Postgres, dan password Redis. SECRET_KEY disertakan dalam keadaan kosong. Jika dibiarkan, Dify akan membuat key dan menyimpannya di direktori penyimpanannya. Password berbeda. File contoh menetapkan difyai123456 yang sama untuk Postgres dan Redis, serta key yang tetap dan telah diketahui publik untuk code sandbox, plugin daemon, dan Weaviate. Membiarkan nilai bawaan tersebut adalah penyebab yang paling umum hingga Dify yang di-host sendiri mengalami kompromi. Jika Anda ingin menetapkan secret key sendiri, buat key baru:

openssl rand -base64 42

Tempelkan hasilnya ke SECRET_KEY, lalu tetapkan nilai unik dan kuat untuk setiap field password dan key di dalam file tersebut. Password Redis juga muncul di dalam CELERY_BROKER_URL. Ubah nilainya di sana agar worker dapat terhubung ke Redis.

Langkah 2: Jalankan

Jalankan stack:

docker compose up -d

Pada proses pertama, beberapa image akan diunduh dan database akan diinisialisasi, jadi tunggu selama sekitar satu menit. Periksa apakah container dalam kondisi sehat:

docker compose ps

Setiap service yang berjalan terus-menerus harus membaca running; task izin yang hanya dijalankan satu kali akan berhenti setelah tugasnya selesai. Secara default, Dify menyediakan antarmuka web melalui container nginx bawaan pada port 80. Saat pertama kali membuka http://YOUR_SERVER/install, buat akun admin. Lakukan segera, sebelum hal lain dapat mengakses port tersebut, karena sebelum akun itu dibuat, siapa pun yang memuat halaman tersebut dapat mengambil alihnya dan memiliki instance Anda.

Langkah 3: Jangan mengeksposnya secara langsung. Tempatkan TLS dan firewall di depannya

Di sinilah sebagian besar instalasi cepat berhenti dan sebagian besar insiden bermula. nginx milik Dify mendengarkan pada port 80 tanpa enkripsi di semua interface, serta memublikasikan port 443. Anda tidak ingin login admin dan key model dikirim melalui HTTP biasa. Anda juga tidak ingin service internal dapat dijangkau dari luar.

Amankan server dengan firewall default-deny yang hanya mengizinkan SSH dan trafik web:

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

Ingat bahwa firewall yang hanya mencakup IPv4 dapat membiarkan port yang sama tetap terbuka pada IPv6. Inilah celah firewall IPv6 yang sering luput dari perhatian pengguna self-hosting. Pastikan kedua stack difilter. Perlu diketahui juga bahwa port yang dipublikasikan Docker ditangani oleh aturan firewall milik Docker, bukan oleh ufw. Stack default memublikasikan port debugging daemon plugin, 5003, pada setiap interface. Atur EXPOSE_PLUGIN_DEBUGGING_PORT di .env menjadi 127.0.0.1:5003, kecuali Anda memang perlu men-debug plugin dari mesin lain.

Untuk TLS, cara yang paling bersih adalah mengikat port web Dify ke loopback, lalu menjalankan reverse proxy dengan sertifikat Let's Encrypt di depannya. Dengan demikian, satu-satunya komponen yang terekspos ke Internet publik adalah proxy yang menggunakan HTTPS. .env milik Dify memungkinkan Anda mengubah port yang diekspos. Atur agar terikat pada 127.0.0.1, lalu arahkan proxy ke port tersebut. Lakukan hal yang sama untuk EXPOSE_NGINX_SSL_PORT, karena nginx milik Dify secara default menggunakan host port 443 dan proxy Anda memerlukan port tersebut. Gagasan penguatan keamanan agent dalam menjalankan AI agent dengan aman pada VPS juga berlaku di sini: pertahankan komponen yang berubah-ubah pada loopback, ekspos hanya yang harus bersifat publik, dan biarkan satu pintu masuk yang diperkuat menangani TLS. Jika interface sebuah tool hanya digunakan oleh Anda dan sama sekali tidak memerlukan sertifikat, lewati proxy dan akses tool tersebut melalui SSH tunnel. Pendekatan ini digunakan oleh self-hosting pemindai keamanan open-kritt, yang mengikat dashboard-nya ke loopback dan meneruskannya ke laptop Anda, bukan memublikasikannya. Jika seluruh tim memerlukan Dify tetapi tidak memerlukan akses dari Internet publik, overlay network dapat memperluas pendekatan tersebut ke lebih dari satu laptop: mengiklankan subnet privat server ke tailnet Anda memungkinkan setiap perangkat yang disetujui mengakses builder melalui alamat privat, sementara firewall tetap menutup semua akses selain SSH. Jika Anda mengelola server ini melalui coding agent, bukan secara manual, tentukan terlebih dahulu sejauh mana agent tersebut boleh bekerja tanpa pengawasan sebelum memberikan akses kepadanya. Hal ini penting karena mode izin yang Anda tetapkan untuk Claude Code menentukan apakah agent akan berhenti untuk meminta konfirmasi sebelum menulis ulang .env atau me-restart stack. Jika satu session sedang memantau log container sementara session lain mengedit konfigurasi proxy, kedua session tersebut dapat saling mengirim teks pada server yang sama. Cara ini lebih praktis daripada menyalin output antar-terminal setiap kali Anda me-restart stack.

Langkah 4: Selalu terapkan patch

Dify berkembang cepat, dan pembaruan mencakup perbaikan keamanan. Karena Anda melakukan clone pada release tag, pembaruan berarti melakukan checkout ke tag berikutnya, bukan melakukan pull pada branch. Cadangkan database terlebih dahulu, lalu dari direktori docker:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Migrasi database berjalan otomatis saat startup, dan beberapa migrasi tidak dapat dibatalkan. Karena itu, pencadangan dilakukan terlebih dahulu. Baca catatan rilis sebelum setiap upgrade, bukan hanya upgrade mayor: Dify menyatakan bahwa langkah upgrade berbeda antar-rilis. Misalnya, catatan rilis 1.17.1 (September 2026) memberi tahu siapa pun yang menjalankan Weaviate bawaan dengan data yang sudah ada agar tidak langsung beralih ke versi tersebut, tetapi menjalani setiap rilis minor secara bertahap. Dify juga mengubah skema .env antar-rilis. Karena itu, bandingkan .env.example dengan .env setelah melakukan checkout ke tag baru dan terapkan perubahan Anda pada konfigurasi tersebut, karena variabel baru yang belum Anda tetapkan dapat menyebabkan container gagal start.

Langkah 5: Cadangkan data yang tidak dapat dibuat ulang

Ada dua hal pada server Dify yang tidak dapat digantikan: database Postgres, yang menyimpan aplikasi, pengguna, dan pengaturan Anda, serta volume yang menyimpan dokumen yang diunggah dan indeks vektor. Keduanya berada dalam Docker volumes di direktori docker. Buat snapshot secara terjadwal, lalu salin snapshot tersebut ke luar server. Snapshot itu berisi setiap model key dan dokumen yang diunggah dalam satu file. Karena itu, enkripsi snapshot sebelum meninggalkan server, dengan alasan yang sama seperti backup Vaultwarden dapat menjadi titik lemah pada server kata sandi yang secara keseluruhan kuat. Model API key dapat diterbitkan ulang. Aplikasi yang Anda bangun selama seminggu tidak dapat dibuat ulang dengan mudah. Alasan yang sama berlaku untuk agent yang statusnya harus tetap tersedia meskipun mesin tempatnya berjalan sudah tidak ada: menjalankan KiroCrew sebagai container yang selalu aktif pada dasarnya berarti membuat snapshot memori dan jadwal yang jika tidak akan hilang pada reboot berikutnya.

Jika Anda ingin agent yang dibuat di sini mengakses data di luar dataset Anda sendiri dan mencari di web secara langsung, mengarahkan agent ke instance SearXNG yang di-host sendiri menjaga aliran query tetap berada pada hardware yang Anda kendalikan. Namun, pelajari terlebih dahulu permukaan serangan prompt injection yang terbuka sebelum mengaktifkannya. Untuk agent yang lebih otonom dan dapat menjalankan kode, lihat meng-host Agent Zero sendiri. Sementara itu, membangun AI agent sendiri pada VPS membahas dasar-dasar yang mendukung semuanya.

FAQ

Apa persyaratan sistem untuk melakukan self-hosting Dify?

Dify mendokumentasikan kebutuhan minimum RAM 4 GiB dan 2 core CPU, serta Docker Compose 2.24.0 atau yang lebih baru. Batas minimum tersebut mencerminkan ukuran stack default: 15 container yang berjalan terus-menerus dan satu tugas inisialisasi satu kali, per Oktober 2026. Sediakan ruang disk yang cukup untuk dokumen yang diunggah dan indeks vektor, serta memori tambahan jika server juga menjalankan layanan lain.

Apakah aman mengekspos Dify secara langsung pada port 80?

Tidak. Web server bawaan Dify menggunakan HTTP biasa dan menjadi lapisan depan untuk login admin serta API key model Anda. Tempatkan reverse proxy dengan sertifikat Let’s Encrypt di depannya, bind port Dify sendiri ke loopback, dan biarkan hanya proxy HTTPS yang menghadap Internet. Terapkan juga firewall default-deny yang mencakup IPv4 dan IPv6.

Bagaimana cara memperbarui Dify yang di-self-host?

Cadangkan database, lalu dari direktori docker jalankan docker compose down, git fetch --tags, git checkout tag rilis baru, docker compose pull, dan docker compose up -d. Baca catatan rilis terlebih dahulu karena langkah upgrade berbeda antar-rilis, migrasi dapat bersifat tidak dapat dibatalkan, dan Dify terkadang menambahkan variabel .env baru. Variabel yang tidak ada dapat menyebabkan container gagal berjalan.

Apa hal pertama yang harus dilakukan setelah menginstal Dify?

Buka /install dan segera buat akun admin. Sebelum akun tersebut dibuat, siapa pun yang dapat mengakses halaman itu dapat mengambil alihnya. Selesaikan penyiapan segera setelah container dalam kondisi sehat, sebelum membuka firewall ke Internet.