Self-Host Dify in 2026: VPS, Security and Backups
Self-hosting Dify is an operations choice, not just a Docker command. Use this guide to decide who owns updates, secrets, storage, recovery and public access before you create a server.
For the current installation commands, use our Docker Compose guide alongside Dify's release-specific documentation.
Decision first
Know what self-hosting changes
Dify can run wherever Docker runs, including a laptop, an on-premises server or a cloud VM. Running the application yourself gives you control over its deployment and stored data. It also makes you responsible for patching, backups, recovery, TLS, availability and incident response.
Choose a VPS when
You want direct control over the Compose project, data location, upgrade timing and network policy, and someone can own routine Linux and container work.
Choose managed hosting when
You prefer a provider to handle more of the server lifecycle. Confirm what the provider actually backs up, monitors and upgrades before assuming those tasks are included.
Use a local machine when
You are evaluating Dify without public users. A local test does not prove that your production DNS, TLS, storage and recovery design will work.
Privacy boundary: self-hosting does not automatically keep every prompt or file on your server. Model APIs, plugins, external tools, email and observability services can transmit data outside the Dify host. Review each connection separately.
Capacity
Size the first server without inventing a user limit
Dify's current Docker Compose minimum is 2 CPU cores and 4 GiB RAM. Linux requires Docker 19.03 or later and Docker Compose 2.24.0 or later. Those numbers are a deployment floor, not a promise about users, documents or response time.
Memory pressure
Document ingestion, vector services, plugins and concurrent workers compete for memory. Watch the real containers before increasing worker counts.
Persistent storage
Plan enough space for PostgreSQL, the selected vector store, uploads, plugin data and backups. Disk usage grows differently from model API usage.
Local models
A Dify application can call a model running elsewhere. If the model shares this server, size its CPU, RAM or GPU separately from the Dify minimum.
Editorial recommendation: start from the documented floor only for testing. Measure memory, disk, queue depth and latency under your own workload before setting a production capacity target.
Before public access
Secure first access and the configuration boundary
1. Replace shipped secrets before launch
Generate a unique SECRET_KEY and replace the default database and Redis passwords. Dify warns that changing SECRET_KEY later invalidates sessions and file URLs and can make stored OAuth credentials unreadable.
2. Protect the installation page
Set INIT_PASSWORD if the host is reachable before you create the first administrator. Restrict inbound ports and expose the console only through the intended HTTP or HTTPS entry point.
3. Configure only the public URLs you need
The default single-domain Nginx setup can detect several addresses. Explicit values matter for OAuth callbacks, system-email links, Human Input forms, external triggers and file previews. Use Dify's current variable reference instead of old names copied from tutorials.
4. Map every external data path
Record which model providers, plugins, tools, mail servers and telemetry endpoints receive data. Self-hosting the application cannot override the policies of services you connect to it.
Deploy
Use the tagged Compose release, then verify the current stack
The official quick start checks out the latest release tag, copies docker/.env.example and starts the Compose project. The current project contains more services than older eight-container diagrams. Follow the release documentation instead of deleting containers you do not recognize.
After startup, run docker compose ps. Core and dependent containers should be Up or healthy. The one-time init_permissions task is expected to exit after setting storage permissions.
Operate
Backups and upgrades are part of the hosting decision
Back up the state Dify names
For the standard Compose deployment, Dify tells operators to back up the entire dify/docker/volumes directory before an upgrade. Keep the environment files needed to understand that state.
Test recovery separately
A completed copy job is not proof of recovery. Editorial recommendation: restore into an isolated environment and verify accounts, apps, files and knowledge indexes.
Treat upgrades as changes
Dify says steps can vary by release. Read the target notes, compare new environment templates and reapply reviewed Compose customizations to the release's current file.
Do not promise zero downtime
A single Compose host can restart services during an update. Plan a maintenance window unless you have tested redundancy, database migrations, shared storage and routing for the exact release.
Hosting path
Compare operational responsibility, not a headline price
General-purpose VPS plans give you server-level control. A managed Dify option can reduce setup and maintenance work. Compare current resources, billing terms, backup scope, support boundaries and data location on the provider's own page before purchase.
Affiliate disclosure: these links may earn us a commission at no extra cost to you. The operational guidance above is independent of placement.
Primary sources
Official references used for this guide
- Dify deployment overview
- Dify Docker Compose quick start
- Dify environment-variable reference
- Dify storage, migration, backup and recovery guidance
- Dify release notes