Install Dify with Docker Compose in 2026
Dify's current Compose deployment is larger than the older eight-container stack described in many tutorials. This guide follows the official August 2026 deployment and environment-variable documentation, without invented setup times or container memory estimates.
Start with Dify's official Docker Compose guide. Release-specific instructions take priority over this summary.
Before you start
Current minimum requirements
Dify currently documents at least 2 CPU cores and 4 GiB RAM. Linux needs Docker 19.03 or later, and every supported platform needs Docker Compose 2.24.0 or later. On macOS, Dify recommends assigning at least 2 virtual CPUs and 8 GiB memory to Docker Desktop.
CPU and memory
Minimum: 2 cores and 4 GiB RAM. Workload capacity depends on document processing, concurrent workflows and any local model you run separately.
Compose version
Run docker compose version and confirm version 2.24.0 or later before troubleshooting application containers.
Public access
Use a domain and HTTPS before exposing a production console. The bundled Compose project includes Nginx and Certbot configuration.
Install
Clone the latest release and start Dify
The official quick start checks out the latest release tag, not the moving main branch. The first command needs Git, curl and jq.
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
docker compose up -d
docker compose ps
In a default deployment, Dify starts seven core services, eight dependent components and a one-time init_permissions task. An Exited status for that one-time task is expected. The remaining containers should show Up or healthy before you open http://your_server_ip/install to create the first administrator.
Why old tutorials fail: the current stack includes services such as api_websocket, worker_beat, plugin_daemon and agent_backend. Do not remove an unfamiliar service just because an older diagram does not show it.
Production checklist
Review these settings before public access
1. Replace the shipped secrets
Set a unique SECRET_KEY before first launch and replace the default DB_PASSWORD and REDIS_PASSWORD. Dify warns that changing SECRET_KEY later logs out users, invalidates file URLs and can make stored OAuth credentials unreadable.
openssl rand -base64 42 2. Protect first-time setup
If the server is reachable before you create the administrator, set INIT_PASSWORD. It gates the /install page and stops another visitor from claiming the first account.
3. Set only the public URLs your setup needs
The single-domain Nginx setup can auto-detect several URLs. Set CONSOLE_API_URL for OAuth callbacks, CONSOLE_WEB_URL for links in system email, APP_WEB_URL for Human Input forms, TRIGGER_URL for external triggers and FILES_URL when file previews need an explicit public base URL.
4. Keep optional settings in their current files
Essential values live in docker/.env. Optional and provider-specific templates live under docker/envs/. Copy only the template you need, remove its .example suffix and edit the copy. Values in docker/.env take precedence.
Variable meanings change as Dify evolves. Check the official environment-variable reference before copying values from a third-party guide.
Verify and troubleshoot
Check the stack before changing configuration
docker compose ps docker compose logs -f --tail=200 docker compose down && docker compose up -d docker compose version Common checks
- If setup never opens, confirm that the Nginx container is healthy and that the host firewall allows the intended HTTP or HTTPS port.
- If OAuth returns to the wrong address, verify
CONSOLE_API_URLand the provider's registered callback URL. - If published app forms or external triggers contain localhost, check
APP_WEB_URLandTRIGGER_URL. - If file previews fail, review
FILES_URLandINTERNAL_FILES_URL; internal containers may need a different reachable address than browsers. - Use Dify's current Docker troubleshooting pages before applying old permission, health-check or container-removal snippets.
Upgrade safely
Treat every Dify release as a configuration change
Dify says upgrade steps may differ by release. Read the target release notes, back up persistent data and compare every current .env.example file with its matching local file. If you modified docker-compose.yaml, apply those changes to the release's new file instead of carrying the old Compose file forward. A release may add services that the application needs.
The official repository also includes an optional dify-env-sync.sh helper. It creates a timestamped backup and adds new variables without overwriting existing values, but its output still needs review.
Hosting path
Choose how much infrastructure you want to manage
A general-purpose VPS gives you control over the Compose project, backups and upgrade timing. A managed Dify service reduces that operational work. Check the current provider terms and resources before purchase.
Affiliate disclosure: these links may earn us a commission at no extra cost to you. Placement does not change the technical guidance above.
Primary sources
Official references used for this guide
- Dify Docker Compose quick start
- Dify environment-variable reference
- Dify common deployment issues
- Dify Docker troubleshooting
- Current Docker files in the Dify repository