SSD Nodes Learn
Guides Matt ConnorBy Matt Connor · Updated 2026-07-16

Self-host Dify on a VPS

Dify is a self-hosted LLM app platform that holds your API keys and data. Install it with Docker Compose on a VPS and harden it properly.

What Dify is, and what you are signing up to run

Dify is a self-hostable platform for building applications on top of large language models. You get a web interface for designing chat apps, agents, and retrieval pipelines, an API to call them from your own code, and one place to manage prompts, datasets, and model keys. It is the kind of tool a small team stands up so everyone builds on one shared private base, rather than scattering API keys across scripts.

Running it yourself means running several moving parts. Dify ships as a set of Docker containers: an API server, a background worker, a web frontend, a Postgres database, a Redis cache, and a vector database, all wired together with Docker Compose. That is more than a single binary, but Compose handles the wiring, and a VPS with a couple of gigabytes of RAM to spare runs it comfortably.

Because Dify holds your model API keys and, often, private documents you have loaded for retrieval, treat the box it runs on as sensitive from the first minute. This guide installs it, then hardens it the way you would harden any service that holds secrets.

Prerequisites

You need a VPS running Ubuntu 24.04 with Docker and the Docker Compose plugin installed, and a user with sudo or membership of the docker group. If Docker is new to you, the basics of Docker Compose on a VPS covers the install and the core commands this guide assumes. A domain name pointed at the server is worth having, because you will want TLS in front of Dify rather than a bare IP address.

Step 1: Get Dify and its Compose files

Dify keeps its Docker setup in the main repository. Clone it and move into the docker directory:

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

The .env file is the whole configuration. Read it before you start anything. The values that matter first are the ones that set passwords and secrets: SECRET_KEY, the Postgres password, and the Redis password. The example file ships with placeholder values, and leaving them as shipped is the single most common way a self-hosted Dify ends up compromised. Generate a real secret key:

openssl rand -base64 42

Paste that into SECRET_KEY, and set a strong, unique value for every password field in the file.

Step 2: Start it

Bring the stack up:

docker compose up -d

The first run pulls several images and initialises the database, so give it a minute. Check that the containers are healthy:

docker compose ps

Every service should read running. Dify serves its web interface through a bundled nginx container on port 80 by default. On your first visit to http://YOUR_SERVER/install you create the admin account. Do that immediately, before anything else can reach the port, because until that account exists anyone who loads the page can claim it and own your instance.

Step 3: Do not expose it raw. Put TLS and a firewall in front

Here is where most quick installs stop and most incidents begin. Dify's own nginx listens on port 80, in the clear, on every interface. You do not want your admin login and your model keys travelling over plain HTTP, and you do not want the internal services reachable from outside.

Lock the box down with a default-deny firewall that allows 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 that a firewall which only covers IPv4 can leave the same ports open on IPv6, the IPv6 firewall gap that catches so many self-hosters. Confirm both stacks are filtered.

For TLS, the cleanest path is to bind Dify's web port to loopback and run a reverse proxy with a Let's Encrypt certificate in front, so the only thing on the public internet is the proxy speaking HTTPS. Dify's .env lets you change the exposed port; set it to bind on 127.0.0.1 and point your proxy at that. The agent-hardening ideas in running an AI agent safely on a VPS apply here too: keep the moving parts on loopback, expose only what must be public, and let one hardened front door speak TLS.

Step 4: Keep it patched

Dify moves quickly, and updates include security fixes. Updating is a pull and a restart from the docker directory:

git pull
docker compose pull
docker compose up -d

Read the release notes before a major version jump, because Dify occasionally changes the .env schema between releases, and a new variable you have not set can stop a container from starting.

Step 5: Back up what you cannot regenerate

Two things on a Dify box are irreplaceable: the Postgres database, which holds your apps, users, and settings, and the volume that stores uploaded documents and the vector index. Both live under Docker volumes in the docker directory. Snapshot them on a schedule, and copy the snapshots off the server. A model API key can be reissued; the app you spent a week building cannot.

For a more autonomous, code-running agent, see self-hosting Agent Zero, and building your own AI agent on a VPS covers the foundations beneath all of them.

FAQ

What are the system requirements to self-host Dify?

Dify runs as a Docker Compose stack of about half a dozen containers, so plan for a VPS with at least 2 GB of RAM free, ideally 4 GB, plus a couple of CPU cores and enough disk for your uploaded documents and the vector index. The memory pressure comes from the database and vector store, not from Dify itself.

Is it safe to expose Dify directly on port 80?

No. Dify's bundled web server listens on plain HTTP, and it fronts your admin login and your model API keys. Put a reverse proxy with a Let's Encrypt certificate in front, bind Dify's own port to loopback, and let only the HTTPS proxy face the internet. Pair that with a default-deny firewall that covers both IPv4 and IPv6.

How do I update a 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 adds new .env variables between versions, and a missing one can stop a container from coming up.

What is the first thing to do after installing Dify?

Visit /install and create the admin account immediately. Until that account exists, anyone who can reach the page can claim it. Set it up the moment the containers are healthy, and before you open the firewall to the world.