Self-Host Dify with Docker Compose, HTTPS & Persistent Storage

Dify is an open-source platform for building AI apps like chatbots, agents, and RAG systems using a visual, drag-and-drop workflow builder instead of writing lots of code. It supports more than 100 LLM providers and lets you deploy to the cloud or self-host it yourself with Docker Compose.

Teams choose to self-host Dify with Docker Compose because it gives full control over data, model provider keys, and infrastructure spend, without depending on Dify's managed cloud.

This guide covers the full setup from a blank server to a fully working instance with HTTPS, persistent volumes, and external PostgreSQL.

Before you self-host Dify with Docker Compose, make sure your server and tools are ready:

• Linux server running Ubuntu LTS with at least 2 CPU cores and 4GB RAM.
• Docker Engine 19.03+ and Docker Compose 2.24.0+.
• A domain name with an A record pointing to your server's public IP.
• Ports 80 and 443 open in your firewall or cloud security group.
• API key for at least one model provider, like OpenAI, Anthropic, Azure, or a self-hosted runner like Ollama.

This stack runs 14+ containers at once, so a small VPS can struggle once you get more users. A strong dedicated server gives you dedicated CPU and RAM, so the database, vector store, and workers all have room to run smoothly.

Verify the required tools are installed correctly on your server:

Now proceed to the following steps to self-host Dify with Docker Compose.

This is the first step to self-host Dify with Docker Compose. You must pull the latest tagged release, not the unstable main branch. To do this, run the commands below:

At this point, you must copy the example file so you have a working environment file to edit:

This .env file controls every setting when you self-host Dify with Docker Compose.

Now you must generate a secret key, because Dify uses it to sign session cookies and encrypt stored credentials.

Use this command to generate the secret key:

Copy the output and keep it in a safe place.

Open the .env file with your desired text editor:

In the file, look for the line below and paste your secret key:

Also, find these lines and fill them with your domain name:

Once you are done, save and close the file. If you still need a domain name, you can check PerLod's domain service registration to register and point a domain at your server in minutes.

A production setup where you self-host Dify with Docker Compose should never run on plain HTTP long-term. The bundled Nginx supports Certbot for automated Let's Encrypt certificates.

Edit the .env file again and set:

Also, you must add these two lines anywhere in the file:

Save and close the file. Keep NGINX_HTTPS_ENABLED=false for now, because no certificate exists yet.

Start the stack with the certbot profile so Nginx can respond to the ACME challenge:

Now issue the certificate itself. Run the certbot container's helper script:

You must get:

Once the certificate is issued, go back to .env and turn on HTTPS:

Then, use the command below to reload only Nginx:

Note: If nginx or plugin_daemon keeps restarting after you self-host Dify with Docker Compose, run docker compose ps -a and check that db_postgres actually started. It can silently fail to launch on the first up. Starting it manually with docker compose up -d db_postgres before restarting the full stack usually fixes both errors at once.

Now you open your browser and visit:

You must see the setting up an admin account screen. Create your Dify admin account and click Set up.

You have now accessed Dify's Home / Templates page.

Note: Let's Encrypt certificates expire every 90 days, so keep certbot's renewal cron active, or repeat the update-cert.sh step and reload Nginx manually every few months.

With login working and the console loaded, you've confirmed the core Dify install is successful. Follow the steps below to configure Dify to use an external PostgreSQL database.

The default Compose file runs its own db_postgres container, which works fine for quick tests. But to properly self-host Dify with Docker Compose in production, using a separate and managed PostgreSQL instance is safer for backups, patching, and uptime.

First, on your external PostgreSQL server, create the two databases Dify needs. One for the app and one for the plugin daemon:

Then edit .env on your Dify server:

Update the database block:

Setting SQLALCHEMY_POOL_PRE_PING=true matters here, since external connections over a network drop more than a local Docker network link.

Next, remove the bundled db_postgres service from COMPOSE_PROFILES so it doesn't start pointlessly:

This tells Docker Compose to skip the local db_postgres container completely, since it's no longer needed. If many users will use Dify at once, also raise POSTGRES_MAX_CONNECTIONS on your external database, so it has enough space for all your workers and Celery tasks.

Every stateful service needs a volume that survives container restarts, or you lose data every time you redeploy. By default, STORAGE_TYPE=opendal with OPENDAL_SCHEME=fs and OPENDAL_FS_ROOT=storage stores uploaded files on a local Docker volume.

For a setup where you truly self-host Dify with Docker Compose in production, moving file storage off local disk to S3-compatible object storage removes a single point of failure.

Edit .env:

Set:

Weaviate (the default vector store) also saves its data to its own volume using WEAVIATE_PERSISTENCE_DATA_PATH=/var/lib/weaviate, and Redis keeps its cache and Celery data in its own volume too. It's best to leave both as Docker-managed volumes unless you have a good reason to move them.

To actually use Dify once it's running, add at least one model provider key. The cleanest way is through the console after login, not .env, but if you want a provider pre-filled at first boot, you can add it directly in .env:

Most people skip this and instead add a provider after their first login. Open the Marketplace in the left sidebar, search for your provider (OpenAI, Anthropic, Azure OpenAI, Gemini, or self-hosted runners like Ollama or vLLM), and click Install.

Once installed, go to Integrations > Model Provider in the left sidebar, where you can paste in your API key or add your model.

With your model provider connected and a default model set, Dify is fully configured. Now launch the complete stack and verify every service is running correctly:

Watch the logs to confirm every service starts cleanly and database migrations finish:

The api container runs migrations automatically on first boot since MIGRATION_ENABLED=true by default. Give it a minute or two before checking status.

Check that all containers came up correctly:

To update a server where you self-host Dify with Docker Compose, pull the newest release and rebuild:

After updating, always compare your .env.example with your live .env file. New releases often add new variables or change default values, so this helps you catch anything you need to update.

This setup is a strong Dify deployment including proper HTTPS, a database you fully control, and file storage that won't disappear on restart. Once your usage grows, go for a dedicated server, which gives the database, vector store, and background workers enough space that they need to run smoothly.

We hope you enjoy this guide. For more detailed information, check the Official Dify Docker Compose Docs.