Dify Cloud vs self-hosted Dify

On Dify Cloud, Dify's team applies platform updates to your workspace, so your team's work is reviewing release notes and testing your apps against changes. Self-hosted, your team owns every upgrade. Dify's GitHub releases show minor releases roughly monthly, for example 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Effort rises with the number of customizations, plugins and workflows that must be retested, the database migrations in each release, and how many environments you keep (development, staging, production). Ask Dify which release notes flag breaking changes for the version you run, and budget a standing test cycle for each monthly release.

• Check the Dify releases page before each planned upgrade.
• Pin the image version in your Compose file so upgrades happen on your schedule.

The Dify Docker Compose guide asks for at least 2 CPU cores and 4 GB of RAM, plus Docker Compose 2.24.0 or later. That is a starting baseline, not a production sizing. The stack starts the api, worker, web, plugin daemon and other core services alongside PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Your real footprint grows with concurrent users, document ingestion volume, the vector store you choose and how many workflows call tools or code. Cloud hides this entirely, so the sizing question is one your infrastructure team owns self-hosted. Ask Dify for its resource guidance for your expected load, and load test with your own documents before you commit to hardware.

On Dify Cloud, the platform team chooses and operates storage, and you manage data inside your workspace. Self-hosted, your team makes the choices. Dify's environment reference says the metadata database can be PostgreSQL (default), MySQL or OceanBase, file storage can use OpenDAL, S3-compatible storage, Azure Blob or Google Cloud Storage, and the vector store defaults to Weaviate with options such as Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch. Each choice adds an operational component to back up, patch and monitor. Effort rises when you pick a store your team has not run before, when you need high availability, or when you must move vectors later. Confirm which combinations Dify supports in your target release before you lock in the design.

On Cloud, Dify stores data in its managed region and encrypts it in transit and at rest, but restore scope, retention and recovery targets belong in your contract, so ask Dify for them in writing. Self-hosted, your team owns the backup of PostgreSQL, the vector store, file storage and the configuration, including the SECRET_KEY. Dify's environment reference warns that changing SECRET_KEY after deployment logs out all users, and workspace encryption keys can sit locally or in Azure Key Vault, so a backup that misses keys can leave you unable to read encrypted data. Effort rises with data volume, the number of stores that must stay consistent, and how often you test restores. Run a restore drill into a separate environment before go-live.

SSO is not part of the free self-hosted Community edition. Dify's pricing page places SSO in the self-hosted Enterprise edition, which is custom priced, and the Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2 with providers such as Microsoft Entra ID, Okta and GitHub. Separate SSO scopes cover workspace access and web app access. Confirm with Dify whether your Cloud plan includes the identity features you need, because the Cloud tiers listed on the pricing page do not name SSO. Effort rises with the number of identity providers, the group-to-role mapping you need, and whether web app access must be controlled separately from workspace access. Ask for the SSO configuration steps for your chosen edition before you plan the rollout.

On Cloud, Dify operates the sandbox and proxy layers, and you rely on its security changes. Self-hosted, your team pulls and applies the images that contain them. The Dify 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. Dify's environment reference says SSRF_PROXY routes outbound requests through a proxy that blocks internal and private IP ranges. Your team should confirm that these settings are correct in your deployment, because a misconfigured proxy or sandbox weakens the protection the release notes describe. Patch on the same schedule as core upgrades, and test that outbound rules still allow the integrations your workflows need.

On Cloud, Dify runs the platform, so your on-call covers application failures, bad model responses and credit or quota limits in your workspace. Self-hosted, your team also owns uptime for every container, disk growth, certificate expiry, queue backlogs and the health of PostgreSQL, Redis and the vector store. Effort rises with the number of services, the user count your apps serve, and whether the AI features are business-critical. Decide who answers pages at night, what counts as a severity one incident, and who contacts the model providers when an upstream API fails. Ask Dify which logs and metrics the self-hosted stack exposes so your monitoring can be wired in from day one.

Yes, within the company's scope. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and ongoing support and upgrades are available as retainers. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. To scope it, list the upgrade cadence you need, the stores and identity providers in use, the backup and restore targets, and who will be on call, then ask for a quote that separates one-time setup from recurring support. DeployOpen does not issue audit reports or certifications, so ask your auditor which evidence they will need.

Self-hosted Community Dify has no license fee, but you pay for the infrastructure, the people who run it and any Enterprise license you need. Dify Cloud is billed per workspace per year: the published Professional plan is 590 US dollars per workspace per year and Team is 1,590 US dollars per workspace per year, according to the Dify pricing page. Those figures cover the platform subscription only. Self-hosting shifts cost into servers, storage, backups, monitoring and staff time, and it recurs every month. Ask Dify for Enterprise self-hosting pricing in writing, since it is custom priced and adds SSO, multiple workspaces and professional support. Also compare the message credits and seat limits, which set the ceiling on Cloud use.

A single-node Docker Compose trial can be stood up quickly once Docker Compose 2.24.0 or later is available, but a production setup takes longer. The Docker Compose deployment starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, and the docs require at least 2 CPU cores and 4 GB of RAM. The main drivers are your choice of metadata database, file storage and vector store, the network design around the sandbox and outbound proxy, identity integration, backup and upgrade routines, and how many models and data sources you connect. Ask DeployOpen for a fixed-scope estimate built from your written requirements.

Your team needs people who can operate containers, a relational database, Redis and a vector store, and who can manage secrets and network egress. Dify's environment reference notes that changing SECRET_KEY after deployment logs out all users, so key handling belongs in your change process. Someone must own upgrades, since Dify 1.17.1 was released on September 10, 2026 and minor releases arrive roughly monthly, according to the Dify releases page. Plan for on-call coverage, backup restore tests and access reviews. Teams without this skill mix usually need a partner for the first build and a retainer for ongoing upkeep.

Yes, the Community edition is free to self-host and runs anywhere Docker runs, so an experienced platform team can deploy it alone. The harder questions are production concerns: the single-workspace limit on Community, the license conditions on multi-tenant use and console branding, and identity integration, which the Enterprise edition covers with SSO. Outside help makes sense when the team lacks container or security operations experience, or when the deadline is tight. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure, under a written, fixed scope. Confirm your license position with Dify before you go live.

A Dify-managed dedicated deployment is the middle option when you need more isolation than Cloud offers but do not want to run the platform yourself. The Dify Enterprise page describes a single-tenant cluster in your region, and the Enterprise deployment can run on Kubernetes for high availability with SSO and multi-workspace management. Consider it when your data residency, tenancy or identity requirements rule out a shared Cloud workspace, and when you lack the staff to run the stack. Ask Dify what the managed service covers in terms of uptime commitments, support windows and data location, since those terms are not in the facts we rely on here.

Moving is practical when the application logic lives in Dify's exports and your data sources are portable, but you should plan it as a migration project. Start by listing the apps, knowledge bases, model provider keys and member roles you rely on. Re-establish the vector store, file storage and SECRET_KEY in your environment, then re-enter credentials and validate retrieval results against a known test set. Ask Dify what export options exist for apps and knowledge data, and whether any Cloud-only features would need rework. Move in the reverse direction with the same checklist, and budget the migration as a fixed-scope piece of work.

Check the message credits, team members, app counts, knowledge documents, knowledge storage and log history on the plan you need. The Professional plan lists 5,000 message credits per month, 3 team members, 50 apps, 500 knowledge documents and 5 GB of knowledge storage, while Team lists 10,000 credits, 50 members, 200 apps, 1,000 documents and 20 GB, according to the Dify pricing page. The free Sandbox plan includes 200 message credits and 30 days of log history. If your usage exceeds these figures, or if your data must stay in your own region, self-hosting or the Enterprise cluster becomes the realistic comparison.

Dify Cloud's pricing page shows GDPR, AICPA SOC 2 and ISO 27001 badges and states that data is encrypted in transit and at rest in Dify's managed region. Those badges describe Dify's own program, and they do not transfer to your self-hosted environment. A self-hosted deployment gives you control over data location and controls, but you must produce your own evidence for any assessment. Ask Dify for the current reports and scope statements it can share, and ask your auditor which of your controls the self-hosted setup must evidence. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue the reports.