Dify Production Stack

You deployed Dify in 10 minutes.

Your RAG pipeline works on three example documents. The chat interface is beautiful. You feel productive.

Then you push it to production and:

• PostgreSQL runs out of shared_buffers with 50 concurrent users — queries slow to 3 seconds
• Redis loses its AOF file on restart — every queued workflow task vanishes
• Someone uses Dify's web browsing tool and discovers your internal Docker network
• The Weaviate container OOMs because nobody set memory limits
• There's no backup — and your CEO asks "what happens if this server dies?"

The official docker-compose.yaml from Dify's repo is a starting point. It's not production infrastructure.

What This Stack Adds

Every Dify deployment has the same nine services. The difference is in the tuning:

| Component | Official Compose | This Stack | |-----------|----------------|------------| | PostgreSQL | shared_buffers=128MB, default autovacuum | Tuned for RAG: shared_buffers=2GB, aggressive autovacuum, WAL compression | | Redis | No persistence, no memory limit | AOF persistence + RDB, maxmemory 1gb, allkeys-lru eviction | | Weaviate | No resource limits | Memory-capped, graceful degradation under load | | Nginx | Not included | TLS termination, /api routing, WebSocket upgrade, security headers | | SSRF Proxy | Mentioned in docs, not configured | Sandbox service with egress rules isolating outbound requests | | Sandbox | SQLite (not production-safe) | Configured with proper isolation and resource limits | | Health checks | Not included | Automated verification of all 9 services + inter-service connectivity | | Backups | Not included | Hot backup: PostgreSQL pg_dump, Redis RDB, Weaviate snapshot | | Upgrade path | Not documented | Step-by-step migration commands per Dify version |

What You're Actually Buying

Not the files. You can write a compose file. You're buying the tuning decisions that took months of production incidents to discover:

• Why shared_buffers should be 25% of RAM on RAG workloads (not the default 128MB)
• Why Redis needs appendonly yes because Celery tasks are lost without it
• Why the SSRF proxy matters and how to verify it's working
• Why Weaviate needs a memory cap or it consumes everything on a 4GB VM
• Why backup scripts must freeze Weaviate before snapshotting

These are the things you learn by running Dify in production and watching it break. This stack encodes those lessons so you don't have to.

Architecture

                    ┌──────────┐
  HTTPS :443       │   Nginx  │
  ─────────────────►  :80    ├──────────► Dify Web :3000
                    └──────────┘
                         │
                    ┌────┴────┐
                    │  Dify   │
                    │  API    │──► PostgreSQL :5432 (tuned)
                    │  :5001  ├──► Redis :6379 (AOF persisted)
                    └─────────┘├──► Weaviate :8080 (memory-capped)
                         │
                    ┌────┴────┐
                    │  Dify   │
                    │  Worker │──► Sandbox :8194 (SSRF-isolated)
                    └─────────┘

What You'll Be Able To Do

• Deploy Dify with confidence — nine services, health-checked, backed up, TLS-terminated
• Handle 50+ concurrent users — PostgreSQL and Redis tuned for real RAG query patterns
• Sleep at night — automated backups capture all state, restore scripts tested
• Upgrade safely — step-by-step upgrade commands for each Dify release
• Debug fast — health check script tells you exactly which service is broken

Requirements

• Docker Engine 24+ with Docker Compose v2
• 4GB RAM minimum, 8GB recommended (Dify + PostgreSQL + Redis + Weaviate)
• 10GB free disk space (for Weaviate vectors and embeddings)
• Domain name with DNS pointing to your server (for TLS via Let's Encrypt)

Quick Start

unzip dify-stack.zip
cd dify-stack
cp .env.example .env
# Edit: domain, DB password, secret keys
docker compose up -d
./health-check.sh

Dify is live at https://your-domain.com. Create an admin account and start building.

The Security Email You Don't Want to Write

"Hey team, someone found our internal Docker network through Dify's web browsing tool. They downloaded /etc/shadow and posted it to a forum."

If you deployed Dify without the SSRF proxy, this is a real incident waiting to happen. With this stack, the Sandbox service isolates outbound requests to approved destinations. The internal Docker network is invisible to Dify's web browsing tool.

The Alternative

The Alternative

You can piece this together yourself from Dify's docs, PostgreSQL docs, Redis docs, Weaviate docs, Nginx docs, and SSRF prevention guides. Budget 2–3 full days for a senior engineer to configure, test, and document. At €600/day, that's €1,200–1,800 of engineering time.

Or download this stack, edit one .env file, and have it running in 20 minutes. €12.99.

Upgrade Path

Running Dify alone? Add Ollama for local LLM inference, n8n for workflow automation, Qdrant as an alternative vector store, Prometheus/Grafana for monitoring, MinIO for backups, and Traefik as your reverse proxy — AI Infrastructure Mastery includes this stack plus six more components for €29.