Docker Container Security#

Dify's container security posture relies on a combination of non-root process execution, network segmentation, and kernel-level syscall filtering (for the sandbox service). Explicit Docker runtime hardening directives — cap_drop, read_only, security_opt for seccomp/AppArmor, per-service CPU/memory limits — are largely absent from the generated docker-compose.yaml. Production operators should layer these on top.

The canonical compose file is auto-generated from docker/docker-compose-template.yaml and must not be edited directly 1.

Non-Root User (API, Web, Agent Runtime)#

All three first-party application containers enforce non-root execution at image-build time — no compose-level user: override is needed.

API container creates a system group/user dify with UID/GID 1001, chowns /app, and drops to that user via USER dify. Pinned versions of security-sensitive packages (expat, libldap, zlib1g, libsqlite3-0) are installed explicitly 2 — see api/Dockerfile.

Web container mirrors the pattern: UID 1001 is configurable via the dify_uid build arg, all /app files are chown-ed, and the final USER dify directive is set 3. The entrypoint script is copied --chmod=755 to remain executable under the non-root user 4 — see web/Dockerfile.

dify-agent-runtime (langgenius/dify-agent-local-sandbox) also creates a dify user (uid 1001) in its Dockerfile's runtime stage 5.

Volume permission bootstrap: An init_permissions service runs before api and worker, chown-ing ./volumes/app/storage to 1001:1001 so the non-root user can write to the host-mounted volume 6.

Network Isolation (Sandbox SSRF Containment)#

The default compose stack implements two distinct SSRF containment architectures:

Workflow Sandbox (sandbox service)#

• ssrf_proxy_network is an internal bridge network (internal: true) with no direct external egress 7.
• sandbox joins only ssrf_proxy_network, making the Squid proxy at ssrf_proxy:3128 the sole path for outbound traffic 8.
• The sandbox is pre-configured with HTTP_PROXY/HTTPS_PROXY pointing to the Squid proxy 9.
• The Squid proxy enforces a deny-by-default policy blocking all RFC-1918 ranges; only .marketplace.dify.ai is allowed by default 10.

Agent Sandbox (local_sandbox service)#

The local_sandbox service (Dify Agent V2) has no direct network route to the api service or default network — only two dedicated internal networks:

• agent_sandbox_network (internal): Shared with agent_backend to allow control-plane access via shellctl on port 5004. Code running in local_sandbox can also reach agent_backend through this network — a known limitation acknowledged in the compose file comments. Arbitrary code execution remains possible through the shellctl channel, though the agent runtime respects HTTP(S)_PROXY.

• local_sandbox_proxy_network (internal): Shared only with agent_ssrf_proxy. All egress traffic (except localhost/127.0.0.1) is forced through the dedicated Squid proxy at agent_ssrf_proxy:3128 via HTTP_PROXY/HTTPS_PROXY environment variables.

agent_ssrf_proxy Service#

A dedicated Squid-based forward proxy enforcing path-level ACLs:

• Configuration: docker/ssrf_proxy/squid-agent.conf.template, docker/ssrf_proxy/squid-common.conf.template, docker/ssrf_proxy/docker-agent-entrypoint.sh
• Network membership: Both default (to reach api and agent_backend as proxy destinations) and local_sandbox_proxy_network (to serve local_sandbox)
• Access control rules:
  • ALLOW: agent_backend domain with /agent-stub/* path only
  • ALLOW: api domain with /files/* path only (signed upload/download URLs)
  • ALLOW: Selected private IPs/domains (when SSRF_PROXY_ALLOW_PRIVATE_IPS or SSRF_PROXY_ALLOW_PRIVATE_DOMAINS are configured)
  • DENY: All other private network destinations
  • ALLOW: External internet traffic

Security benefits: Even if arbitrary code executes in the agent sandbox, it cannot directly access internal services beyond the explicitly allowed endpoints. The path-based ACLs ensure only agent-stub endpoints (agent runtime) and files endpoints (signed URLs) are reachable. External API calls (e.g., to LLM providers) pass through the proxy. The private network restriction can be conditionally relaxed via SSRF_PROXY_ALLOW_PRIVATE_IPS and SSRF_PROXY_ALLOW_PRIVATE_DOMAINS environment variables, which allow operators to explicitly permit agent sandbox access to specific internal services when needed.

General Network Topology#

Services that need both inter-service and external access (api, worker, plugin_daemon) join both ssrf_proxy_network and default networks 11.

Seccomp BPF Filtering (dify-sandbox)#

The sandbox service (langgenius/dify-sandbox) applies a kernel-level seccomp BPF filter to each code-execution child process — separate from and in addition to Docker's container isolation:

• Default action is ActKillProcess; any syscall not on the whitelist delivers SIGSYS 12.
• The Python/amd64 whitelist lives in internal/static/python_syscall/syscalls_amd64.go in the dify-sandbox repo 12.
• Network syscalls (ALLOW_NETWORK_SYSCALLS) are only added when ENABLE_NETWORK: true 12.
• Operators can extend — but not replace — the built-in whitelist via ALLOWED_SYSCALLS env var or allowed_syscalls in docker/volumes/sandbox/conf/config.yaml 12.
• The filter uses SECCOMP_FILTER_FLAG_TSYNC to cover all threads of the child process 12.

Note: The sandbox healthcheck only hits the parent process /health endpoint, which is unaffected by seccomp filter failures — seccomp-related outages are silent at the infrastructure layer 12.

Filesystem Isolation (dify-agent-runtime / Landlock)#

The local_sandbox service (Agent V2 shell execution) uses Linux Landlock for per-workspace path restrictions — independent of Docker volume mounts:

Requires Linux ≥ 5.13; disable via SHELLCTL_ENABLE_PATH_ISOLATION=false. Custom paths can be added via SHELLCTL_LANDLOCK_RW_PATHS / SHELLCTL_LANDLOCK_RO_PATHS 5.

Resource Limits (Partial)#

Explicit resource constraints are applied only to select services in the default compose configuration:

• Elasticsearch has deploy.resources.limits.memory: 2g 13.
• OpenSearch sets ulimits.memlock to unlimited (soft/hard: -1) and nofile to 65536 14 — required for memory-mapped I/O, not a security hardening.
• OpenGauss runs with privileged: true 15 — a significant trust exception required by that database engine.

CPU limits and per-service memory caps for core services (api, worker, web, sandbox) are absent and should be added by operators for production deployments.

Key Source Files#