Aggiornato Marzo 2026 8 Servizi Spiegati

Guida alla Configurazione Docker Compose di Dify

Tutto quello che devi sapere sull'architettura Docker di Dify — da cosa fa ogni container all'hardening del tuo deployment per la produzione con configurazioni personalizzate.

L'Architettura Docker di Dify

Il file docker-compose.yaml di Dify avvia otto servizi. Capire cosa fa ognuno ti aiuta a configurare, risolvere i problemi e scalare il tuo deployment.

nginx Reverse proxy / web server

Instrada le richieste HTTP in arrivo al servizio interno corretto (UI web o API). Questo è l'unico container che deve essere accessibile pubblicamente.

~50 MB

api Server API Dify

Il backend principale Python/Flask. Gestisce tutta la logica di business, le chiamate LLM, l'esecuzione della pipeline RAG e gli endpoint REST API.

~300 MB

worker Worker Celery in background

Elabora task asincroni: indicizzazione documenti, importazione dataset, catene LLM a lunga esecuzione. Condivide il codice con il container API.

~300 MB

web Frontend Next.js

L'interfaccia utente basata su React servita come app Next.js. Comunica con il container API.

~150 MB

db Database PostgreSQL

Memorizza tutti i dati persistenti: app, conversazioni, metadati dei dataset, utenti e chiavi API.

~100 MB

redis Cache e message broker

Mette in cache le query frequenti, memorizza la coda dei task Celery per il worker e gestisce i dati di rate-limiting.

~30 MB

weaviate Database vettoriale

Memorizza gli embedding dei documenti per le knowledge base RAG. Il consumer di memoria più pesante. Può essere sostituito con pgvector o Qdrant.

~500 MB

sandbox Sandbox per l'esecuzione del codice

Container isolato per eseguire nodi di codice definiti dall'utente nei workflow Dify. Viene eseguito con permessi limitati.

~100 MB

RAM totale di base: ~1,5 GB solo per i container inattivi. Su un server da 4GB, questo lascia ~2,5 GB per il sistema operativo e i carichi di lavoro effettivi. Per la produzione, si raccomandano 8GB di RAM.

Guida alle Variabili d'Ambiente

Tutta la configurazione di Dify si trova in dify/docker/.env. Copia da .env.example e personalizza queste impostazioni chiave:

Sicurezza (Obbligatorio)

# Genera con: openssl rand -base64 42
SECRET_KEY=your-very-long-random-secret-key

# Chiave di cifratura per i dati sensibili memorizzati
# Genera con: openssl rand -hex 16
ENCRYPT_IV=your-16-char-hex-value

Impostazioni del Database

# Impostazioni PostgreSQL (rete Docker interna)
DB_USERNAME=postgres
DB_PASSWORD=change-this-strong-password
DB_HOST=db
DB_PORT=5432
DB_DATABASE=dify

# Impostazioni Redis
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=change-this-redis-password
REDIS_DB=0

Impostazioni URL & CORS

# Il tuo dominio (senza slash finale)
CONSOLE_URL=https://tuo-dominio.com
APP_URL=https://tuo-dominio.com
SERVICE_API_URL=https://tuo-dominio.com

# Origini CORS (separate da virgola)
CONSOLE_CORS_ALLOW_ORIGINS=https://tuo-dominio.com
WEB_API_CORS_ALLOW_ORIGINS=https://tuo-dominio.com

Archiviazione File

# Predefinito: filesystem locale (memorizzato in ./volumes/app/storage)
STORAGE_TYPE=local

# Per lo storage compatibile S3 (consigliato per la produzione)
# STORAGE_TYPE=s3
# S3_ENDPOINT=https://s3.amazonaws.com
# S3_BUCKET_NAME=my-dify-bucket
# S3_ACCESS_KEY=your-access-key
# S3_SECRET_KEY=your-secret-key
# S3_REGION=us-east-1

Chiavi API LLM (opzionale durante la configurazione)

# Puoi anche configurare queste nella UI web di Dify
# Queste impostazioni .env pre-configurano i provider al primo avvio

OPENAI_API_KEY=sk-your-openai-key
ANTHROPIC_API_KEY=sk-ant-your-key
GOOGLE_API_KEY=your-gemini-key

# Per Ollama (LLM locali)
# Configura nell'UI: Impostazioni → Provider Modello → Ollama

Configurazioni Personalizzate

Mappatura Porte Personalizzata

Se la porta 80 è occupata, cambia la porta host a cui si collega Nginx di Dify modificando .env:

# Cambia la porta host del container Nginx
EXPOSE_NGINX_PORT=8080
EXPOSE_NGINX_SSL_PORT=8443

Disabilita Weaviate (usa pgvector invece)

Weaviate utilizza ~500MB di RAM. Sui server con poca memoria, passa a pgvector (già disponibile nel container PostgreSQL):

# In .env — passa il vector store a pgvector
VECTOR_STORE=pgvector

# Poi riavvia senza Weaviate
docker compose up -d --scale weaviate=0

Abilita Supporto GPU

Per passare attraverso una GPU NVIDIA (per i modelli di embedding locali), aggiungi il runtime GPU al tuo docker-compose.override.yaml:

services:
  api:
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Vedi la guida al GPU hosting per le istruzioni complete.

Comandi Comuni

Avvia tutti i servizi docker compose up -d

Ferma tutti i servizi docker compose down

Riavvia un singolo servizio docker compose restart api

Visualizza log (segui) docker compose logs -f api worker

Apri shell nel container API docker compose exec api bash

Controlla salute dei container docker compose ps

Utilizzo risorse per container docker stats

Rimuovi container fermati docker compose down --remove-orphans

Scarica le ultime immagini docker compose pull

Ricostruisci un servizio docker compose up -d --build api

Risoluzione dei Problemi

Il container continua a riavviarsi / CrashLoopBackOff

Controlla i log: docker compose logs api. Di solito causato da un formato SECRET_KEY errato o una variabile d'ambiente obbligatoria mancante. Assicurati che SECRET_KEY abbia almeno 32 caratteri.

Memoria esaurita — container terminati dall'OOM killer

Aggiungi spazio di swap e/o aggiorna a un server più grande. Esegui dmesg | grep -i "killed process" per confermare le terminazioni OOM. Il container weaviate è solitamente il colpevole — considera di passare a pgvector.

Errori di connessione al database

Assicurati che il container DB sia sano prima che l'API si avvii: docker compose ps db. L'API ha un depends_on con health check, ma sui server lenti il DB potrebbe non finire di inizializzarsi in tempo. Prova docker compose restart api.

Errori di permesso negato su ./volumes

La directory del volume di archiviazione necessita dei permessi corretti. Esegui: sudo chown -R 1000:1000 ./volumes dalla directory dify/docker.

Hardening per la Produzione

Prima di andare in produzione, applica queste misure di sicurezza:

1. Cambia tutte le password predefinite

Imposta valori univoci e sicuri per DB_PASSWORD, REDIS_PASSWORD e soprattutto SECRET_KEY. Non usare mai i valori predefiniti di .env.example in produzione.

2. Proteggi il file .env

chmod 600 dify/docker/.env
# Non eseguire mai il commit di .env nel controllo versione

3. Abilita i backup automatici

Aggiungi al crontab (crontab -e):

0 3 * * * cd ~/dify/docker && docker compose exec -T db pg_dump -U postgres dify > ~/backups/dify_$(date +\%Y\%m\%d).sql

4. Usa S3 per l'archiviazione dei file

Passa a STORAGE_TYPE=s3 così i documenti caricati vengono memorizzati separatamente dal tuo server e sopravvivono alle ricostruzioni dei container.

Guide Correlate

Guida

Come Fare il Self-Host di Dify

Guida completa per principianti dalla configurazione del server all'SSL.

Guida

GPU Hosting per Dify

Esegui LLM locali con Ollama su server GPU.

Provider

Hetzner per Dify

Il miglior VPS per rapporto qualità-prezzo per deployment Dify basati su Docker.