Dify Enterprise on AWS or Azure: when a cloud layout fits
A regulated team that must run Dify Enterprise inside its own cloud account should start with AWS, the path Dify documents for managed cloud services. Azure is a proof of concept, so treat it as an option to confirm with Dify and your implementation partner, not as a documented layout. The choice matters because the Community edition and Enterprise solve different problems. The Community Docker Compose stack runs anywhere Docker runs, but it is limited to a single workspace. Dify Enterprise is deployed on Kubernetes for high availability, and it adds SSO, multiple workspaces and professional support under a custom price. A cloud layout only makes sense for the Enterprise path.
Map each requirement in the Dify Enterprise resources checklist to a cloud resource before you pick services. The checklist calls for Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Its production example uses six worker nodes with 8 CPUs and 32 GB of RAM each, plus a three-node Qdrant cluster. Decide early who operates Qdrant, since a managed PostgreSQL or Redis service does not remove the need to run the vector store. Confirm the managed service versions against the checklist minimums before you commit to them.
For Azure, ask for a written statement of which services and versions were tested, what the proof of concept did not cover and who supports the result after handover. The same questions apply to AWS, where you should confirm each managed service against Dify's current AWS guidance rather than relying on this summary. Because Enterprise pricing is custom, a quote should list the cloud resources, the Kubernetes node pools, the Qdrant topology and the licence terms as separate line items. Ask which of these are one-time build costs and which recur, such as node capacity, managed service fees and upgrade work.
Which managed service fills each checklist requirement
This table maps each Dify Enterprise resources checklist requirement to the AWS and Azure managed services a team would evaluate. Read the Azure column as proof of concept territory: confirm each option against the checklist version and your own tests before committing. The main takeaway is that the checklist sets the minimum versions and integration points, and the cloud choice must meet them with private connectivity and tested backups.
| Checklist requirement | AWS options to evaluate | Azure options to evaluate (proof of concept) |
|---|---|---|
| Kubernetes 1.24 or later | Amazon EKS on a supported Kubernetes version, with managed node groups or self-managed nodes sized for the worker profile | Azure Kubernetes Service on a supported version, tested for the same node sizing and ingress design |
| Helm 3.14 or later | Helm run from a deployment pipeline or bastion host with access to the EKS cluster and the chart registry you approve | Helm run from a pipeline with access to the AKS cluster, using the same chart version pinned in your change record |
| PostgreSQL 14 or later | Amazon RDS or Aurora PostgreSQL in private subnets, confirming the engine version, automated backups and point-in-time recovery settings | Azure Database for PostgreSQL flexible server in a private network, confirming engine version, backup retention and private access |
| Redis 6 or later | Amazon ElastiCache for Redis in private subnets, confirming the engine version, in-transit encryption and auth settings | Azure Cache for Redis in a virtual network, confirming the engine version, TLS and access keys or Entra-based access support |
| Qdrant vector database | Qdrant run on EKS as a three-node cluster with persistent volumes, since no AWS managed Qdrant service is documented for Dify | Qdrant run on AKS as a three-node cluster with persistent volumes, validated in proof of concept before any production plan |
| S3-compatible or cloud object storage | Amazon S3 with a bucket policy, encryption and a VPC endpoint so traffic stays off the public internet | Azure Blob Storage with private endpoints, confirming Dify's storage provider setting and key handling for your tenant |
How to build the cloud layout in sequence
This sequence takes the cloud layout from version confirmation to a verified Dify Enterprise installation. Each step produces a checked output that the next step depends on, so a failed check should stop the sequence until it is resolved.
Confirm the Dify Enterprise and checklist versions
The platform team agrees with Dify on the Enterprise release to install, then checks it against the resources checklist. The checklist requires Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage. Record the versions you will run and confirm that the documentation for that release still lists the same minimums. Done when a signed version matrix exists and every component meets or exceeds the checklist.
Size the node pool from the production example
The platform team sizes the Kubernetes worker pool against the production example in the resources checklist, which uses six worker nodes with 8 CPUs and 32 GB of RAM each. Treat this as a planning reference and confirm with your own indexing and workflow volume whether you need more. Add headroom for node failure and upgrades, and confirm that your cloud account quota allows the chosen instance type. Done when the pool's total CPU and memory, minus the capacity you could lose to a node failure, still covers the planned workload and the quota request is approved.
Provision PostgreSQL and Redis on private addresses
The cloud team creates a PostgreSQL 14 or later instance and a Redis 6 or later instance in the same private network as the worker nodes, with no public endpoint. Confirm with the Dify Enterprise documentation which service types it expects for each. Enable encryption at rest and backup retention on the database, and record who is responsible for restores. Check: from a test host in the worker subnet, a psql session reports server version 14 or later and redis-cli PING returns PONG, and both connections fail from outside the network.
Stand up Qdrant and object storage
Deploy the three-node Qdrant cluster shown in the production example on private nodes or a private-only service, and confirm with Qdrant whether a managed offering fits your controls. Create an S3-compatible or cloud object storage bucket for documents and files. Block public access on the bucket, enable versioning if your retention policy requires it, and create a dedicated access identity with rights only to that bucket. Check: the Qdrant peers report healthy, a test write and read from a worker pod succeed, and an anonymous request to the bucket is denied.
Configure network routes and private endpoints
The network team places the worker nodes, databases, Qdrant and storage in private subnets, adds private endpoints for the object storage and for any model provider endpoints you use, and routes outbound traffic through a controlled egress path. Ingress to the Dify web and API endpoints passes through a load balancer or gateway you control. Confirm the SSRF proxy settings in the Dify environment reference so that requests to internal and private ranges are blocked. Check: name resolution from a worker pod returns private addresses for each service, and an outbound request to an unapproved external host fails.
Install Dify Enterprise through Helm
The platform engineer installs the Dify Enterprise chart with Helm 3.14 or later into a dedicated namespace. The values file points at the external PostgreSQL, Redis, Qdrant and object storage endpoints from the previous steps. Keep secrets such as the SECRET_KEY in your cluster secret store and out of version-controlled values files, and document the key, because changing it after deployment logs out all users. Check: helm status reports deployed, all pods report ready, and the Dify console loads through the internal ingress.
Verify connectivity, backups and SSO
The platform team runs connectivity checks from inside the cluster to each dependency, uploads a test document to object storage, and runs a test knowledge base query that reaches Qdrant. It then configures SSO with your identity provider. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with providers such as Microsoft Entra ID and Okta, and separate scopes for workspace access and web app access. Run a PostgreSQL backup and restore test before go-live. Check: a user in the intended group signs in, and a user outside it is refused.
How to keep model traffic on private endpoints
Cloud model providers are reached over the public internet by default, so a private design depends on giving the Dify workloads a route to the provider that does not cross the open internet. On AWS, that usually means a private connectivity option offered by the provider or a gateway you run inside your VPC. On Azure, it usually means a private endpoint in your VNet with DNS resolution for the provider's hostname pointing at the private address. Confirm with each provider which private connection types it supports for your region and contract, because not every model API is offered through a private link.
- Private link or gateway: Decide whether the provider is reached through a private endpoint or through an internal gateway that you operate and that enforces your own allowlist.
- DNS split horizon: Make sure the provider hostname resolves to the private address from inside the VPC or VNet, and to nothing unexpected from outside it.
- Egress allowlist: Restrict outbound routes from the Dify API and worker subnets to the approved provider endpoints only.
- Credential scope: Store provider keys in your secrets service, scope them to the minimum project or deployment, and rotate them on a schedule you set.
- Proxy path: Confirm whether the SSRF proxy settings apply to these calls in your version, and test an outbound request from a Dify worker to see which route it takes.
Before go-live, ask each provider in writing which private connection options cover your model, region and data handling terms, and what they log.
Models served inside your VPC or VNet, such as an inference server running on your own GPU nodes, are the simplest case for data residency, but they still need a deliberate network design. The inference endpoint should sit in a subnet that only the Dify workloads can reach, and it should not be published to the internet. Because the endpoint is internal, the SSRF proxy behavior matters: outbound requests that Dify sends to private IP ranges may be blocked by default, so the endpoint address has to be reachable in a way your configuration allows, and the exception should be as narrow as possible.
- Dedicated subnet: Place inference servers in a subnet with security groups or network security groups that accept traffic only from the Dify API and worker sources on the serving port.
- Stable internal names: Use private DNS names for endpoints so that a model move does not require changing Dify configuration in several places.
- Narrow proxy exceptions: If the SSRF proxy blocks the private range where the endpoint lives, review the proxy and environment settings and allow only the specific host and port, not the whole subnet.
- TLS between services: Terminate TLS on the inference endpoint or its gateway and verify certificates from the Dify side.
- Health and capacity alerts: Monitor the endpoint separately, since a stalled model server looks like a Dify failure to end users.
Confirm with your inference server vendor which ports, authentication methods and health endpoints it exposes, and whether it makes any outbound calls of its own.
Embedding and rerank models are called during knowledge base indexing and retrieval, which means they run on the path that handles your document content. Teams often secure the chat model carefully and then overlook these calls, even though they receive chunks of the same source material. Decide which provider or self-hosted service performs each embedding and rerank call, and apply the same egress and DNS rules as for the chat model. Indexing jobs run in the background on worker nodes, so check their network path separately from the web and API path.
- Inventory every model call: List chat, embedding and rerank models per workspace, with the endpoint each one uses and the data it receives.
- Separate indexing and query paths: Confirm that both the worker path used during indexing and the API path used during retrieval are covered by the same rules.
- Vector store traffic: Keep the Qdrant or other vector store connection on the private network and restrict access to the Dify subnets.
- Batch and rate limits: Ask providers for their rate limits and maximum input sizes so that indexing jobs do not fail or retry outside your expected pattern.
- Logging of content: Confirm whether the provider retains request content or logs prompts, and whether that retention matches your data policy.
Ask each embedding and rerank provider for its data retention terms, its private connection options and the exact hostnames it calls.
Egress control is the layer that enforces every decision above, so it should be designed once for the whole Dify deployment. On AWS, that typically means subnet route tables, security groups, network ACLs, and optionally a managed firewall or proxy that inspects outbound traffic. On Azure, it typically means route tables, network security groups and, if you use one, an Azure Firewall or a third-party network appliance. DNS needs the same care: a private zone that overrides a public name is only effective if every workload in the VPC or VNet uses the resolver that knows about it. The Dify SSRF proxy adds an application-level control. Its settings route outbound requests through a proxy that blocks internal and private IP ranges, which protects against Dify being used to reach internal services. Those settings can interact with endpoints you intentionally keep private, so test the actual route for each destination.
- Default deny outbound: Permit only the provider endpoints, package sources and update channels you have approved.
- Resolver consistency: Point the Dify nodes at the resolver that holds your private zones, and confirm that no workload falls back to a public resolver.
- SSRF proxy review: Read the proxy-related variables in the environment reference for your version, and document which destinations are exceptions.
- Flow logs: Enable VPC flow logs or Azure network flow logs for the Dify subnets so that you can prove where traffic went.
- Change control: Treat route, DNS and proxy changes as security-relevant changes with a review step.
Before sign-off, confirm with your network team and cloud provider how the SSRF proxy exceptions and private DNS zones behave on the exact platform version you deploy.
What drives the cost of a cloud Enterprise deployment
The cost of a cloud Dify Enterprise deployment splits into two kinds of spend: a one-time implementation effort and recurring infrastructure. Dify Enterprise is custom priced, according to the Dify pricing page, so the license figure comes only from a quote built on your written scope. Implementation work, covering cloud account setup, Kubernetes and Helm installation, connecting external PostgreSQL, Redis, Qdrant and object storage, SSO configuration and testing, is a one-time cost paid to whoever delivers it, whether your team or a partner.
Infrastructure cost recurs every month and is billed by your cloud provider. It includes the worker nodes, the managed PostgreSQL and Redis services, the Qdrant cluster, object storage, load balancing, egress and backups. The Dify Enterprise resources checklist uses a production example of six worker nodes with 8 CPUs and 32 GB of RAM each, plus a three-node Qdrant cluster. Treat that as a reference point for sizing conversations, not a target. Node count, instance family, managed database tier, Qdrant replica count and storage volume all move the bill, and so do indexing volume, workflow concurrency and log retention. Confirm the current requirements for your Dify version on the Dify Enterprise resources checklist before you price anything.
Ask for a quote that separates these lines: the license fee and its term, implementation effort by phase with named deliverables, a monthly infrastructure estimate by service with the sizing assumptions written next to it, support terms, and a list of costs the quote excludes, such as model provider usage, private endpoint charges, cross-region transfer and third-party identity licenses. Ask who pays for each line and what changes if the workload doubles. A quote that cannot state its sizing assumptions is hard to compare with another.
Security controls to plan in the cloud account
Most of these controls are set once, in configuration, and then trusted for the life of the deployment. Decide them before the first production user signs in, because several are hard to change later without disrupting users or data. Each card names one control, what it protects, and what to confirm in your AWS or Azure account.
Treat SECRET_KEY as permanent
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials. Changing it after deployment logs out all users, so generate it once, store it in your cloud secrets service, and inject it at deploy time rather than writing it into a file in the repository. Confirm which secrets manager your Dify Enterprise values file reads from, who can read it, and how the key is backed up with the rest of your recovery material.
Workspace keys in local storage or Key Vault
Workspace encryption keys protect data that Dify stores on behalf of each workspace. On Azure, you can store them in Azure Key Vault. Decide this with your key management owner before go-live, since the choice determines who can rotate keys, how access is logged, and what a restore needs. Confirm the key location, access policy and rotation procedure, and test a restore that depends on them.
Single sign-on with OIDC, SAML or OAuth2
Dify Enterprise supports OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID and Okta. Set up SSO against the identity provider your organization already governs, and define separate access for workspace administration and for web app users. Confirm group mapping, session lifetime and the behavior when the identity provider is unavailable, because local fallback accounts may be needed for administrators.
SSRF proxy blocks private ranges
Workflows and tools make outbound HTTP calls, which can reach internal services, cloud metadata endpoints or private subnets. The SSRF_PROXY settings route these requests through a proxy that blocks internal and private IP ranges. In AWS or Azure, pair this with security groups and route tables that deny egress from the Dify subnets to databases and management networks. Confirm that the proxy is in the request path for every outbound call your workflows use.
Token-based service authentication
The Dify 1.16.1 release notes describe token-based API authentication between services, alongside sandbox network isolation through a Squid proxy and sandboxed Jinja2 template rendering. Keep the Dify release on a version that includes these changes and confirm that internal service calls require the token rather than trusting network location alone. Plan the release check into your monthly upgrade routine, since minor releases arrive about once a month.
Separate accounts and network segments
Place the Dify production stack, its test environment and shared tooling in separate AWS accounts or Azure subscriptions, with separate network segments for the application, data and model endpoint tiers. This limits the blast radius of a misconfiguration and keeps audit logs for each environment distinct. Confirm who holds administrative roles in each account, which private endpoints reach model services, and how cross-account access is granted and reviewed.
Questions buyers ask about Dify Enterprise on AWS or Azure
What does a Dify Enterprise cloud build cost, and what drives the price?
Price depends on the written scope, so there is no published figure for a DeployOpen engagement. The public pricing page lists the self-hosted Enterprise edition as custom priced, so the license quote comes from Dify and the build quote comes from DeployOpen. Cost drivers include the number of environments, the managed services you choose for PostgreSQL, Redis and object storage, the Qdrant topology, and how much SSO and network work is included. Ask for a quote that separates one-time build work from recurring items such as cloud service fees, Dify licensing and any support retainer.
How long does a Dify Enterprise build on AWS or Azure take?
Duration is set by the agreed scope and the state of your cloud accounts, not by a fixed number. The main drivers are how quickly network, identity and cloud account approvals arrive, whether private model endpoints need new connectivity, how many workspaces and SSO integrations are in scope, and how much load testing the production profile requires. Ask for a written timeline with dependencies listed, so each approval or access grant that gates a milestone is visible before work starts.
What must our internal team provide before the build starts?
Your team provides the cloud accounts or subscriptions, network ranges, DNS and certificate ownership, identity provider access for SSO, and decisions on encryption keys and data residency. You also need named owners for the model endpoints Dify will call and for the backup and recovery targets. The Enterprise resources checklist requires Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, a Qdrant vector database and S3-compatible or cloud object storage, so confirm that each of these has an owner and a supported version in your environment.
Can our own platform team build this without an outside partner?
Yes, if your team has Kubernetes, Helm, managed database and cloud networking experience and enough capacity for the build period. The work is not unusual in its parts, but it crosses several disciplines at once: cluster design, private connectivity to model endpoints, secrets and key handling, SSO configuration and backup testing. Teams that build in-house usually need a written checklist mapped to the resources list and a clear owner for each domain. Ask whether the partner would hand over documentation and runbooks, so the build can be operated after the engagement ends.
Is the Azure path production ready for Dify Enterprise?
The supplied Dify documentation for managed cloud services is strongest for AWS, and the Azure path is described as a proof of concept. Treat Azure as a validation exercise until Dify and your architects confirm the production controls you need, including managed database and cache choices, Qdrant topology, backup behavior and high availability. Ask Dify to confirm the supported Azure services and the version you plan to run, and request a documented production readiness review before committing to Azure for a regulated workload.
How does the Community edition compare with an Enterprise cloud build?
The Community edition is free to self-host and runs anywhere Docker runs, but the pricing page limits it to a single workspace. Enterprise adds SSO, multiple workspaces, advanced security, a commercial license and professional support, and it can run on Kubernetes for high availability. A Community deployment on a single host is simpler and cheaper to start, while Enterprise on AWS or Azure adds managed services, cluster operations and licensing. Choose based on how many workspaces, identity integrations and availability targets your organization needs.
How are Dify Enterprise upgrades handled in a cloud environment?
Plan upgrades as a tested change in a staging environment, not as an image pull. Dify ships minor releases roughly monthly, and the Docker Compose documentation advises a backup before every upgrade and a check of new environment variables after the upgrade. In a Kubernetes build, the upgrade also covers Helm chart changes, Kubernetes version support, database migrations and Qdrant compatibility. Ask for a documented upgrade procedure, rollback steps and a schedule that fits your change control, and confirm whether an upgrade retainer is included in the quote.
How DeployOpen scopes a cloud Dify Enterprise build
DeployOpen plans, implements and supports self-hosted platforms inside your own cloud accounts, so a Dify Enterprise build on AWS or Azure is provisioned in subscriptions and networks your organization controls, not in a DeployOpen-hosted environment. Engagements run under a fixed scope agreed in writing before work starts. That written scope names the cloud accounts and regions, the managed services chosen for each Dify dependency, the Kubernetes and Helm versions, the identity integration, the network design for private model endpoints, the backup and restore approach and the handover documentation. Each item is a decision your team should review, because the scope is what the quote is built from.
DeployOpen does not publish prices. The quote follows from the written scope, so the most useful preparation is an inventory of what your environment already provides: existing landing zones, network segments, identity providers, key management, logging and the model endpoints you have approved. Ask the vendor for the Dify Enterprise license terms and the components they cover, and confirm them with Dify directly. Separate one-time work (design, provisioning, migration, acceptance testing) from recurring work (upgrades, monitoring, security testing, capacity changes), and ask for each to be priced on its own line.
Ongoing work after handover is available as a retainer. Retainers typically cover upgrades that follow Dify's roughly monthly minor releases, periodic security testing and capacity reviews, which suit teams that do not want to absorb that load internally. Ask what a retainer includes, how upgrades are tested in a staging environment before production, who is on call for incidents and how changes to the written scope are handled. Confirm these terms in writing before the build starts, since they determine how the quote and the operating model fit together.
How DeployOpen delivers this feature
The sequence moves from confirming your cloud accounts and network constraints to a written scope, a built and checked Dify Enterprise environment, and optional ongoing support. Each stage closes with a document or check you can review before the next one starts.
Discover cloud accounts and network constraints
DeployOpen reviews the AWS or Azure accounts, subscriptions, regions and network boundaries you intend to use, along with your identity provider, data residency rules and the model endpoints Dify must reach. Your cloud and security teams confirm which managed services they already operate, which private connectivity routes are permitted and who approves changes. The step closes with a discovery summary listing open questions, such as whether the Enterprise resources checklist items map to services your organization already runs, and each question has a named owner.
Agree the written scope and deliverables
DeployOpen turns the discovery findings into a written scope that names the cloud platform, the managed services for PostgreSQL, Redis, object storage and the vector store, the Kubernetes and Helm versions, the network design for private model endpoints and the handover items. The scope states what is out of scope, which decisions remain with your team and what evidence will be delivered. Pricing follows from this written scope, so it is the document to compare against your internal estimate. The step closes when both parties sign the scope and the deliverables list.
Confirm versions and resource profiles
Before any build starts, DeployOpen checks the target Dify Enterprise version against the release notes and the resources checklist, and confirms the Kubernetes, Helm, PostgreSQL, Redis and Qdrant versions your environment supports. The team agrees whether the environment is a test or production profile and records the node sizing and Qdrant topology your workload needs. Your team confirms any version or sizing point the vendor documentation leaves open. The step closes with an approved version and sizing record that the build follows.
Build the network and cloud foundation
DeployOpen provisions the account structure, network segmentation, private endpoints or egress controls for model providers, and the managed data services in the agreed design, using infrastructure as code where your team wants it kept. Outbound traffic from Dify is routed through the controls you approved, and internal address ranges are kept out of reach of outbound requests. The step closes when the foundation passes connectivity tests between each component and the approved egress paths, and those test results are recorded in the handover pack.
Deploy Dify Enterprise and configure identity
DeployOpen installs Dify Enterprise on the Kubernetes cluster with the Helm chart, points it at the external database, cache, vector store and object storage, and sets the secrets and encryption key handling your policy requires. Single sign-on is configured with the identity protocol and provider you selected, with separate scopes for workspace access and web app access. The step closes when a test administrator and a test user can sign in through the chosen identity path, and the configuration is stored in version control.
Verify, back up and hand over
DeployOpen runs the verification plan agreed in scope, covering failover of the cluster components you asked to test, backup and restore of the database and object storage, sign-in and access tests, and checks that outbound requests cannot reach private ranges. Your team restores a backup into a separate environment to confirm the procedure works. Documentation covers the architecture, runbooks, upgrade steps and the list of owners. The step closes with a signed handover record and a review meeting where open items are assigned to your team.
Optional retainer for ongoing support
If your team wants continued help, DeployOpen can provide support, upgrades and continuous testing under a retainer agreed separately from the build scope. Upgrades follow the release cadence and the upgrade guide for each target version, with a backup taken before each change. Retainer terms, response expectations and the included activities are written into a separate agreement so they can be compared with your internal staffing. The step closes when the retainer agreement is signed and the first maintenance window is scheduled.
