SSD Nodes Learn Hosting plans →
How to do am Matt ConnorBy Matt Connor · Updated 2026-08-28

How to self-host Dify for VPS with Docker Compose

Dify run six Docker containers, so get 4 GB RAM. Replace every .env secret before boot, then open /install to create admin before stranger do am.

Wetín Dify be, and wetin you agree to run

Dify na platform wey you fit host by yourself to build applications on top large language models. E give you web interface to design chat apps, agents, and retrieval pipelines, API to call dem from your own code, and one place to manage prompts, datasets, and model keys. Na the kind tool small team dey set up so everybody fit build on one shared private base, instead make dem scatter API keys across scripts.

You dey run am by yourself means say you dey manage plenty parts wey dey work together. Dify dey release as Docker containers: an API server, a background worker, a web frontend, a Postgres database, a Redis cache, and a vector database. Docker Compose connect all of dem together. E no be just one binary, but Compose handle the connections. VPS wey get some extra gigabytes of RAM fit run am comfortably. If the same VPS go run another thing too, size am based on numbers wey you measure, no be numbers wey dem advertise. This na because the actual RAM minimums for PhotoPrism and Immich dey far above the minimums wey dem publish. If a photo server dey share the same machine, e go first use up the resources wey Dify database and vector store need. CPU contention dey cause the same problem. a Jellyfin library wey you style like 90s video store need almost no resources while person dey only browse artwork. But as soon as person start transcode, Dify worker queues behind am. The good side be say Dify container count no change, no matter how many apps you build on top of am. This one produce more predictable cost than OpenBot, where every AI coworker get its own container and its own browser. Every new hire dey push the minimum RAM requirement up again.

Because Dify dey hold your model API keys and, many times, private documents wey you load for retrieval, treat the box wey e dey run on as sensitive from the first minute. This guide go install am, then harden am the way you go harden any service wey dey hold secrets.

Prerequisites

You need VPS wey dey run Ubuntu 24.04, with Docker and Docker Compose plugin installed. You also need user wey get sudo or membership for docker group. If Docker new to you, the Docker Compose basics for VPS explain the installation and the main commands wey this guide assume. E good make you get domain name wey point to the server, because you go want TLS for front of Dify instead of bare IP address.

Step 1: Download Dify and e Docker Compose files

Dify dey keep e Docker setup inside the main repository. Clone am, then enter the docker directory:

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

The .env file na the full configuration. Read am before you start anything. The values wey matter first na the ones wey set passwords and secrets: SECRET_KEY, the Postgres password, and the Redis password. The example file come with placeholder values, and if you leave dem as dem come, na the most common way self-hosted Dify dey end up breached. Generate a real secret key:

openssl rand -base64 42

Paste am inside SECRET_KEY, and set strong, unique value for every password field inside the file.

Step 2: Start am

Bring the stack up:

docker compose up -d

First run go pull plenty images and initialise the database, so give am one minute. Check say the containers dey healthy:

docker compose ps

Every service suppose read running. Dify dey serve its web interface through bundled nginx container for port 80 by default. When you first visit http://YOUR_SERVER/install, you go create the admin account. Do am immediately, before anything else fit reach the port, because until that account dey exist, anybody wey load the page fit claim am and own your instance.

Step 3: Make you no expose am raw. Put TLS and firewall for front

Na here most quick installs dey stop, and na where most incidents dey start. Dify own nginx dey listen for port 80 without encryption, for every interface. You no want your admin login and model keys dey travel through plain HTTP, and you no want internal services reachable from outside.

Lock the box down with default-deny firewall wey go allow only SSH and 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

Remember say firewall wey only cover IPv4 fit leave the same ports open for IPv6. Na the IPv6 firewall gap dey catch plenty self-hosters. Confirm say both stacks dey filtered.

For TLS, the cleanest path na bind Dify web port to loopback, then run reverse proxy with Let's Encrypt certificate in front, so na only the proxy wey dey speak HTTPS dey public internet. Dify .env let you change the exposed port; set am make e bind for 127.0.0.1, then point your proxy go there. The agent-hardening ideas for running an AI agent safely on a VPS still apply here: keep the moving parts for loopback, expose only wetin must dey public, and make one hardened front door speak TLS. If na only you go use a tool interface and e no need certificate at all, skip the proxy and reach am through SSH tunnel, the same way self-hosting the open-kritt security scanner keep its dashboard bound to loopback and forward am go your laptop instead of publishing am. If whole team need Dify but public internet no need access, overlay network fit extend this idea pass one laptop: advertising the server's private subnet to your tailnet let every approved device reach the builder through private address while firewall remain closed to everything except SSH. If you dey administer this box through coding agent instead of by hand, decide how much work e fit do without supervision before you give am the keys, because the permission mode you leave Claude Code in decide whether e go stop to ask before e rewrite .env or restart the stack. If one session dey tail container logs while another dey edit proxy config, those two sessions can pass text to each other on the same box, and this better pass copying output between terminals every time you restart the stack.

Step 4: Keep am patched

Dify dey move fast, and updates dey include security fixes. To update am, na pull and restart from the docker directory:

git pull
docker compose pull
docker compose up -d

Read the release notes before you jump to major version, because sometimes Dify dey change the .env schema between releases, and new variable wey you never set fit stop container from starting.

Step 5: Backup wetin you no fit regenerate

Two things for Dify box no fit replace: the Postgres database, wey hold your apps, users, and settings, and the volume wey store uploaded documents and the vector index. Both dey under Docker volumes inside the docker directory. Make snapshot dem on schedule, then copy the snapshots comot from the server. You fit issue another model API key; but you no fit replace the app wey you spend one week to build. Na the same reason apply to any agent wey state suppose outlive the machine wey dey run am: keeping KiroCrew running as an always-on container mean say you snapshot the memory and schedules wey for disappear when system reboot next time.

When you want the agents wey you build here to reach beyond your own datasets and search the live web, pointing them at a self-hosted SearXNG instance keep the query stream for hardware wey you control. But e good make you read about the prompt injection surface wey this one open before you switch am on. For agent wey fit run code more independently, see self-hosting Agent Zero, and building your own AI agent on a VPS cover the foundation wey all of dem dey use.

FAQ

Wetin be the system requirements to self-host Dify?

Dify dey run as Docker Compose stack wey get about six containers, so plan for VPS wey get at least 2 GB RAM free, ideally 4 GB, plus small CPU cores and enough disk space for the documents wey you upload and the vector index. Na the database and vector store dey use plenty memory, no be Dify itself.

E safe to expose Dify directly for port 80?

No. Dify bundled web server dey listen for plain HTTP, and e dey handle your admin login and model API keys. Put reverse proxy wey get Let's Encrypt certificate in front, bind Dify own port to loopback, and make only the HTTPS proxy face internet. Join am with default-deny firewall wey cover both IPv4 and IPv6.

How I fit update self-hosted Dify?

From the docker directory, run git pull, then docker compose pull and docker compose up -d to fetch new images and restart. Read the release notes first, because Dify sometimes dey add new .env variables between versions, and if one dey miss, e fit stop container from starting.

Wetin be the first thing to do after you install Dify?

Visit /install and create the admin account immediately. Until that account dey exist, anybody wey fit reach the page fit claim am. Set am up as soon as the containers dey healthy, and before you open the firewall to everybody.