Deploy Dify on Cloud Servers: Complete Guide from Provisioning to Docker Setup

Building scalable, enterprise-grade AI applications requires more than just calling an API in a local Jupyter notebook. As AI orchestration matures, developers and enterprise architects demand privacy, infrastructure control, low latency, and customizable visual workflows. Dify has emerged as one of the most prominent open-source Large Language Model (LLM) application development platforms. Maintained under the permissive MIT license, Dify bridges the gap between raw foundation models and production-ready software by combining Retrieval-Augmented Generation (RAG) engines, agentic workflows, prompt management, and team collaboration into a single control plane.

While cloud-managed SaaS versions of Dify offer quick onboarding, self-hosting Dify on your own Virtual Private Cloud (VPC) or cloud server ensures total data sovereignty, compliance with strict internal policies, zero per-token platform markups, and the freedom to connect local open-source LLMs or multi-provider aggregators like n1n.ai. This comprehensive guide walks you through every phase of self-hosting Dify: from hardware sizing and server selection to Docker Compose deployment, reverse proxy setup, vector database optimization, and high-availability API routing.

1. Dify Architecture Breakdown & Server Sizing

Before deploying Dify, it is essential to understand its internal microservices architecture. Dify is not a monolithic script; it is a distributed system designed for high concurrency and async workflow execution. A default Docker-based Dify deployment provisions several decoupled containers:

1. dify-web: The front-end interface built on Next.js.
2. dify-api: The core API server powered by Python (Flask/Gunicorn) handling business logic, user authentication, and workflow execution.
3. dify-worker: Celery worker processes responsible for background tasks, document indexing, chunking, and embedding generation.
4. db (PostgreSQL): Stores system metadata, user credentials, workflow specs, conversation histories, and document metadata.
5. redis: Handles session caching, distributed locks, and Celery task queuing.
6. Vector DB (weaviate / qdrant / milvus / pgvector): Stores vector embeddings generated from uploaded knowledge base documents for real-time semantic search.
7. sandbox: An isolated code execution environment for running custom Python/Node.js scripts inside workflow nodes safely.

Because vector databases and Celery worker tasks can be memory-intensive during bulk document embedding, selecting appropriate cloud server specifications is crucial to avoid Out-Of-Memory (OOM) kernel panics.

Hardware Specification Matrix

Pro Tip: If running on a 2C2G (2 Cores, 2 GB RAM) instance, you MUST configure a Linux swap file of at least 2 GB to 4 GB. Without swap space, the PostgreSQL container or Vector Database will crash during initial schema migration or document embedding.

2. Cloud Server Provisioning & Environment Preparation

Whether you use Alibaba Cloud, Tencent Cloud, AWS EC2, Google Cloud Platform, or a VPS provider like Hetzner/DigitalOcean, start by choosing an Ubuntu 22.04 LTS or Debian 12 64-bit operating system for maximum compatibility.

Step 2.1: Initial System Hardening

Log into your newly provisioned cloud server via SSH and execute basic security updates:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git ufw fail2ban htop

Ensure firewall rules permit essential traffic:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Step 2.2: Configure Linux Swap (Crucial for Low-RAM Servers)

If your cloud server has < 4 GB of RAM, execute the following commands to create a 4 GB swap file:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make swap persistent across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Verify that swap is active by running free -h.

Step 2.3: Install Modern Docker & Docker Compose Plugin

Avoid using out-of-date system package managers for Docker installation. Use the official Docker automated installation script:

# Remove legacy installations
sudo apt-get remove docker docker-engine docker.io containerd runc

# Install official Docker Engine
curl -fsSL https://get.docker.com | bash

# Enable and start Docker service
sudo systemctl enable docker
sudo systemctl start docker

# Verify Docker Compose V2 installation
docker compose version

3. Step-by-Step Dify Deployment with Docker Compose

Deploying Dify via Docker Compose is the official standard maintained by the LangGenius core team. It provides maximum stability, reproducible environments, and easy upgrades.

Step 3.1: Clone the Official Repository

Clone the official repository to your server's root directory or home workspace:

cd /opt
sudo git clone https://github.com/langgenius/dify.git
cd dify/docker

Step 3.2: Configure Environment Variables

Copy the example configuration file .env.example to .env:

cp .env.example .env

Open .env using your preferred editor (nano .env or vim .env). Pay close attention to these critical security parameters:

# Change secret key to a strong random string (32+ chars)
SECRET_KEY=sk-your-ultra-secure-random-secret-key-here

# Vector Database Choice: default is weaviate (options: qdrant, milvus, pgvector, myscale)
VECTOR_STORE=weaviate

# Default Database Settings (Change passwords for production!)
DB_USERNAME=postgres
DB_PASSWORD=YourStrongDBPassword2025!
DB_DATABASE=dify

# Enable/Disable Public Registration
ALLOW_CREATE_ACCOUNT=true

# Server HTTP Port Configuration
HTTP_PORT=80
HTTPS_PORT=443

Step 3.3: Launch Dify Containers

Start all services in detached mode:

docker compose up -d

The container engine will download all official pre-built Docker images and initialize PostgreSQL schemas, Redis channels, and Weaviate indexes. Check running container status:

docker compose ps

All services (docker-web-1, docker-api-1, docker-worker-1, docker-db-1, docker-redis-1, docker-weaviate-1, docker-sandbox-1) should show as Up or running.

# Check container startup logs if any service fails
docker compose logs -f api

4. Reverse Proxy Setup & SSL Encryption (Production Ready)

Running Dify directly on port 80 without SSL encryption exposes passwords and API keys to packet sniffing. For production environments, bind Dify internally to port 8080 and use Nginx combined with Certbot (Let's Encrypt) for TLS termination.

Step 4.1: Modify Dify Port Binding

In your dify/docker/.env file, change HTTP_PORT:

HTTP_PORT=8080

Apply the updated port configuration:

docker compose down
docker compose up -d

Step 4.2: Install and Configure Nginx

Install Nginx on your host machine:

sudo apt install -y nginx certbot python3-certbot-nginx

Create a new server block file at /etc/nginx/sites-available/dify:

server {
    listen 80;
    server_name dify.yourdomain.com;

    client_max_body_size 100M; # Essential for large document uploads in RAG

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # WebSocket support for live streaming workflow output
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Enable the site configuration and test Nginx syntax:

sudo ln -s /etc/nginx/sites-available/dify /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Step 4.3: Obtain Free SSL Certificate

Request an SSL certificate via Certbot:

sudo certbot --nginx -d dify.yourdomain.com

Certbot will auto-configure your Nginx file to enforce HTTPS. Navigate to https://dify.yourdomain.com/install in your browser to create your administrator account.

5. Integrating LLM Providers via High-Speed API Aggregators

Once Dify is installed, you must connect LLM providers to power your workflows, RAG agents, and intelligent chatbots. Dify supports major providers like OpenAI, Anthropic Claude, Google Gemini, and open-source models like DeepSeek-V3 and Qwen.

However, managing multiple platform subscriptions, handling rate limits across regional zones, and negotiating enterprise API billing can introduce friction. Integrating a high-performance API routing layer like n1n.ai simplifies model orchestrations.

By leveraging n1n.ai, developers gain access to unified endpoints for cutting-edge models like DeepSeek-V3, Claude 3.5 Sonnet, OpenAI o3, and GPT-4o with sub-hundred-millisecond routing latency and guaranteed high availability.

[ Dify Workflow Engine ] 
          │
          │ (OpenAI-Compatible REST API Request)
          ▼
   [ https://api.n1n.ai/v1 ] ──(Smart Routing)──► DeepSeek-V3 / Claude 3.5 / OpenAI o3

Step-by-Step Configuration in Dify:

1. Open your Dify dashboard (https://dify.yourdomain.com).
2. Click your profile icon at the top right and select Settings > Model Providers.
3. Scroll to OpenAI API Compatible (or standard OpenAI integration).
4. Enter the custom API details sourced from your platform dashboard:
   • Model Name: deepseek-chat (or claude-3-5-sonnet, o3-mini, gpt-4o)
   • API Base URL: https://api.n1n.ai/v1
   • API Key: sk-n1n-your-allocated-key
5. Click Save. Your Dify platform can now route agent requests, multi-step workflow logic, and document summaries through n1n.ai's global endpoint.

6. Advanced Operations & Troubleshooting Guide

Q1: What if port 80 or 443 is already occupied on my server?

If port 80 is occupied by an existing web application (e.g., Apache, Nginx, or Caddy), modify HTTP_PORT in your dify/docker/.env file to a non-conflicting port like 8080 or 8090, as demonstrated in Section 4. Avoid binding public network interfaces directly to container ports when running behind an existing proxy.

Q2: Vector Database consumes excessive RAM and crashes the server (OOM Error)

Weaviate or Qdrant vector databases can consume significant memory during large document vectorization. If container crashes occur:

1. Check kernel OOM logs: sudo dmesg -T | grep -i oom.
2. Ensure swap memory is configured (free -h).
3. Switch vector database backend to pgvector for low-memory environments by updating .env:

   VECTOR_STORE=pgvector
   

   pgvector runs inside the existing PostgreSQL container, reducing system memory footprint by eliminating a standalone vector service.

Q3: How to perform full backup and disaster recovery of Dify data?

Dify stores persistent data inside Docker volumes (dify_db-data, dify_app-data, dify_weaviate-data). Execute a safe backup script using PostgreSQL tools:

#!/bin/bash
   BACKUP_DIR="/var/backups/dify"
   TIMESTAMP=$(date +%Y%m%d_%H%M%S)
   mkdir -p ${BACKUP_DIR}

   # Backup PostgreSQL Database
   docker exec -t docker-db-1 pg_dump -U postgres dify > ${BACKUP_DIR}/dify_db_${TIMESTAMP}.sql

   # Archive uploaded files storage volume
   tar -czvf ${BACKUP_DIR}/dify_storage_${TIMESTAMP}.tar.gz /var/lib/docker/volumes/docker_app-data/_data

   echo "Backup completed: ${BACKUP_DIR}"

Store these backup archives in off-site object storage (S3/OSS).

Q4: How to safely upgrade Dify to the latest version?

To update Dify without losing user data or configuration settings:

cd /opt/dify/docker

# Stop running services
docker compose down

# Pull latest repository changes
git pull origin main

# Pull updated container images
docker compose pull

# Re-launch containers and run migrations
docker compose up -d

7. Cost Optimization & Strategic Recommendations

When scaling Dify from proof-of-concept to production, cost management requires a dual approach: infrastructure optimization and API token efficiency.

1. Infrastructure Cost Lock-in: Take advantage of long-term cloud instance discounts (such as multi-year reserved instances on AWS, Alibaba Cloud, or Tencent Cloud). Starting with a 2C4G instance covers most enterprise team requirements for up to 30 active users.
2. Managed Databases for Enterprise Scale: For high-concurrency production deployments, decouple PostgreSQL and Redis from Docker containers. Migrate to cloud-managed database services (AWS RDS, Alibaba Cloud ApsaraDB) to enable multi-AZ high availability and automated snapshots.
3. API Cost Routing: Leverage unified API gateways like n1n.ai to route routine tasks (such as document extraction or initial classification) to cost-effective models like DeepSeek-V3, while reserving heavy reasoning models like OpenAI o3 for complex workflow logic. This hybrid routing strategy reduces monthly token expenditures by up to 60%.

By following this guide, your organization gains a resilient, sovereign, and scalable AI development platform ready to handle production-grade RAG and Agentic applications.

Get a free API key at n1n.ai