How to Self-Host Dify with Docker in 2026


Dify is an open-source LLM app platform for building chatbots and apps with agents, workflows, and model management. This guide covers a copy-paste Docker install, first-boot verification, troubleshooting, upgrades, and the license for an install you run. Dify’s deployment overview says it runs anywhere Docker runs: a laptop, an on-prem server, or a cloud VM.

Self-hosting suits an AI-automation business that wants $0 software cost, data ownership, and no per-workspace subscription, and that accepts responsibility for the server. For the product-level verdict, see our Dify review; this post is the install guide.

Before you start: what Dify needs to run

Dify’s documented minimum is 2 CPU cores and 4 GiB of RAM, with Docker 19.03+ and Compose 2.24.0+ on Linux, or Docker Desktop with Compose 2.24.0+ on macOS 10.14+ and Windows WSL 2, according to Dify’s Docker Compose quick start.

  • Hardware: At least 2 CPU cores and 4 GiB RAM. On a Mac, the Docker VM needs at least 2 vCPUs and 8 GiB of memory, per the same quick start.
  • Compose: Version 2.24.0 or later is the documented floor. Check it with docker compose version.
  • Installation method: Docker Desktop includes Compose and is the recommended route. Linux users can install the Compose plugin; standalone Compose is legacy. See Docker’s Compose installation docs.

Treat these figures as the floor, not a production size. Your server bill depends on the workload, and the minimum spec does not include the time you will spend operating it.

The install, step by step

The install takes five steps: clone the latest release, enter the Docker directory, copy the environment file, start the stack, then open the console and create an admin account. The quick start says the stack starts seven core services, which Dify’s quick start lists by name.

  1. Clone the repository. This command looks up the latest release tag and clones that version rather than the main branch. It needs git, curl, and jq installed. The Dify repository is the source.

    git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
  2. Enter the Compose project directory. The Compose project lives in docker, not the repository root.

    cd dify/docker
  3. Create your local configuration file. This gives you a local settings layer to maintain across upgrades. Before step 4, open .env and replace the development secrets listed in the security note below.

    cp .env.example .env
  4. Start the stack. Compose pulls the required images and starts the services in the background.

    docker compose up -d
  5. Open the console and create the admin account. Visit the console in a browser (on a local install, the setup page is at http://localhost/install) and follow the first-visit account setup. If you later lose the admin password, docker exec -it docker-api-1 flask reset-password is the recovery command, not a routine setup step. See Dify’s common-issues guide.

What a healthy first boot looks like

A healthy first boot means the seven core services are running: api, api_websocket, worker, worker_beat, web, plugin_daemon, and agent_backend. The quick start also lists eight dependent components: weaviate, db_postgres, redis, nginx, ssrf_proxy, agent_ssrf_proxy, sandbox, and local_sandbox. Run docker compose ps in the docker directory and confirm every container shows Up or healthy. A one-time init_permissions task is expected to show Exited, so do not read that row as a failure. Then check that the console is reachable, create the admin account, and create a test app or chat. If you edit configuration after startup, restart with docker compose down followed by docker compose up -d, as the quick start directs.

Customize without breaking upgrades

Essential values belong in docker/.env. Optional settings have templates under docker/envs/; copy a template without the .example suffix when you need it. docker/.env takes precedence over those templates, so your local changes win. The environment reference and the Docker README both describe that order: Compose reads envs/*.env first, then .env last.

To change the web port, set EXPOSE_NGINX_PORT in .env. The shipped .env.example sets the Nginx ports to 80 and 443 by default. For single-domain Nginx setups, the URL variables can be left empty, according to the environment reference.

Security warning: The .env.example ships development values for DB_PASSWORD, REDIS_PASSWORD, WEAVIATE_API_KEY, CODE_EXECUTION_API_KEY, DIFY_AGENT_API_TOKEN, and DIFY_AGENT_SERVER_SECRET_KEY. Replace them before the server is reachable from anywhere beyond localhost. INIT_PASSWORD ships empty; set it on an exposed server. A publicly exposed server with default credentials puts your clients’ data at risk. The shipped file carries a “replace this development default” comment only for the two DIFY_AGENT secrets; the rest of the list is our advice.

Other defaults worth knowing, listed in the same .env.example:

  • DB_TYPE=postgresql and VECTOR_STORE=weaviate by default. The Docker README lists other vector-store choices.
  • NGINX_CLIENT_MAX_BODY_SIZE=100M and TEXT_GENERATION_TIMEOUT_MS=60000.
  • An empty SECRET_KEY is auto-generated and persisted in storage.

For uploads, the common-issues guide says UPLOAD_FILE_SIZE_LIMIT and NGINX_CLIENT_MAX_BODY_SIZE must match to avoid issues, so if you raise any upload limit above 100 MB, raise NGINX_CLIENT_MAX_BODY_SIZE to match. The bundled Nginx overwrites X-Forwarded-For, and Compose enables RESPECT_XFORWARD_HEADERS_ENABLED for the API services; the Docker README says a directly exposed API should keep it false. Behind Cloudflare or another load balancer, configure Nginx real-IP instead, as the Docker README describes. The Certbot guide covers SSL.

Troubleshooting: three documented trouble spots

Three documented problems are: a 401 after changing domains, a clone error caused by GitHub API rate limits, and an encryption-key reset that must not be used casually. Their fixes are in Dify’s common-issues guide and FAQ.

  1. 401 errors after a domain change. Update CONSOLE_CORS_ALLOW_ORIGINS, WEB_API_CORS_ALLOW_ORIGINS, CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL, APP_API_URL, and APP_WEB_URL, then restart. CONSOLE_WEB_URL also builds the links in system emails. For split subdomains, set COOKIE_DOMAIN and NEXT_PUBLIC_COOKIE_DOMAIN, as the FAQ explains.

  2. fatal: Remote branch null not found. The FAQ says this happens when GitHub rate-limits the unauthenticated API request, so the tag lookup returns null. Choose a version from Dify’s releases page and clone it explicitly:

    git clone --branch <version> https://github.com/langgenius/dify.git

    The FAQ documents this fallback.

  3. The encryption-key reset. Treat this as a last resort for a genuinely broken key pair.

    Irreversible: docker exec -it docker-api-1 flask reset-encrypt-key-pair purges every workspace’s LLM and tool credentials. Every client’s model keys are removed and must be re-entered. Use it only when the key pair is genuinely broken. See Dify’s common-issues guide.

Upgrade without losing your data

Dify’s upgrade steps vary by release, so read the notes for your target version on the Releases page first. The sequence below follows the quick start and FAQ.

  1. Stop the stack, then back up the whole Dify directory. Copying live database files can leave an inconsistent backup.

    cd dify/docker && docker compose down && cd ..
    cp -r dify "dify.bak.$(date +%Y%m%d%H%M%S)"
  2. Fetch the new release and read its upgrade notes on the Releases page, then check out the version tag, for example git -C dify fetch --tags && git -C dify checkout <version>.

  3. Compare configuration. Check each new .env.example against your .env and carry over any new values you need.

  4. Reapply Compose customizations. If you changed docker-compose.yaml, apply those changes to the new file. The quick start warns that a release can add services Dify needs.

  5. Pull the images and restart:

    cd dify/docker
    docker compose pull
    docker compose up -d

The license decision for an install you run

A common shortcut is to call Dify MIT-licensed. It is not. Dify’s LICENSE file describes a modified Apache License 2.0 titled the “Dify Open Source License,” and the repository README says the same. Commercial use is allowed, with two extra conditions.

The pricing page describes Community Edition as free to self-deploy with Docker, with all core features and a single workspace. Under the license:

  • Own use: Commercial use and self-deployment for your own single workspace are allowed under the license.
  • Multi-tenant service: Condition 1a requires written authorization from Dify to operate a multi-tenant environment, where one tenant is one workspace. Serving several clients as separate workspaces on one install falls under that condition. Confirm with Dify before you rely on that setup. The pricing page lists Commercial License Authorization as an Enterprise feature.
  • Branding: Condition 1b does not allow removing or modifying the LOGO and copyright information in the console or app frontend. Where you use Dify’s frontend, a free self-hosted install cannot be white-labeled under this license.

Before serving clients, check each item:

  • One workspace per install?
  • Logo and copyright left intact?
  • No reselling of workspaces on one install without written authorization?
  • Default passwords changed, and client data and model keys secured?
  • Backup taken before every upgrade?

For the full license and pricing analysis, see our Dify review.

The cost math: self-host vs Dify Cloud vs n8n Cloud

Self-hosting Dify costs $0 in software plus the VPS and your operating time. The table compares published figures. Dify Cloud amounts are not listed here, so check the current price on the pricing page before budgeting.

Option Published cost What to account for
Dify self-host $0 software VPS price and your operating time
Dify Cloud Professional Per workspace; see the pricing page 5,000 message credits/month, 3 team members, 50 apps
n8n Cloud Starter 20 EUR/mo billed annually 2.5K workflow executions

Use this formula for a realistic self-host comparison:

Self-host monthly cost = VPS monthly price + (hours/month you spend operating it × your hourly rate)

Plug in your own provider’s price for an instance that meets Dify’s 2 vCPU / 4 GiB minimum; no VPS price is assumed here. Then compare the total with the Dify Cloud price for one workspace. Your operating time is not free. Every hour of upgrades, backups, and troubleshooting counts against the saving.

The Dify pricing page lists Sandbox as free with 200 message credits, 1 member, and 5 apps. Professional includes 5,000 message credits per month, 3 team members, and 50 apps. Team includes 10,000 credits, 50 members, and 200 apps. Enterprise is custom and includes Commercial License Authorization, SSO, and multiple workspaces.

For n8n, the pricing page lists Community Edition as free and self-hosted. Cloud Starter is 20 EUR/mo billed annually for 2.5K executions, Pro is 50 EUR/mo for 10K executions, and Business is 667 EUR/mo for 40K executions. Business is self-hosted only, per that page, and it includes SSO and LDAP, queue mode, and Git version control.

Dify’s and n8n’s meters differ: Dify Cloud counts message credits, while n8n counts workflow executions. Compare workloads, not list prices. For another self-hosting comparison, see our n8n vs Activepieces guide.

FAQ

Dify self-hosting can support commercial use within the license conditions, but workspace limits, branding rules, and Compose requirements still apply. The answers below summarize the relevant terms from the LICENSE and the official deployment documentation.

Is Dify free to use commercially if I self-host it?

Yes, for your own single workspace. Dify’s modified Apache 2.0 license allows commercial use, and the software is free to self-host. Operating a multi-tenant environment requires written authorization from Dify, and the logo and copyright information must remain. Read the LICENSE before serving clients.

Can I remove the Dify logo from my self-hosted console or apps?

No. License condition 1b forbids removing or modifying the LOGO and copyright information in the console or app frontend. White-labeling the Dify frontend of a self-hosted install is not permitted under the free license. Check the exact wording in Dify’s LICENSE before making branding plans.

Do I really need Docker Compose 2.24.0, or will an older version work?

Use Compose 2.24.0 or later; that is the documented minimum on Linux. Docker Desktop includes Compose and is the documented route on macOS and Windows WSL 2. Standalone Compose is legacy. See Dify’s quick start and Docker’s Compose docs.

The Bottom Line

Self-host Dify when you want one workspace, $0 software, and data on your own server, and you can absorb the operating work. Choose Dify Cloud if your time is worth more than the subscription, or if you need multiple workspaces without written authorization. Compare n8n Cloud for execution-heavy workloads, using the Dify pricing page and the n8n pricing page.

  • One workspace, one brand, comfortable with a terminal: Self-host for $0 software, license-compliant use, and data on your server.
  • Serving multiple clients on one install: The free license requires written authorization. Confirm with Dify, or consider Dify Enterprise or Dify Cloud per workspace.
  • Zero-ops preference or small volume: Dify Cloud may cost less than your operating time.
  • Execution-heavy automation: Compare n8n Cloud Pro at 50 EUR/mo for 10K executions. Business at 667 EUR/mo for 40K is self-hosted only. n8n is a different product shape, but the same self-host-versus-cloud tradeoff applies.

How This Guide Was Built

This guide is desk research based on Dify’s official self-hosting overview, the Docker Compose quick start, the FAQ, the environment reference, the troubleshooting guide, and the Dify repository, including its LICENSE and .env.example.

The author did NOT run this install hands-on. No hands-on testing is claimed. The commands and behaviors described here come from official documentation, not from a machine the author operated. Test the process on a disposable server first.

  • ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NoCode Insider.