Dify sizing and capacity planning

Dify sizing and capacity planning starts from the minimum, not the load

The documented floor for a Docker Compose Dify host is 2 CPU cores and 4 GB of RAM, with Docker Compose 2.24.0 or later, according to the Dify Docker Compose docs. That floor starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, the code sandbox and the SSRF proxy on one machine. It says nothing about how many knowledge documents you will index, how many workflows will run at once or how many users will open chat sessions. Those drivers decide the real capacity, so treat the minimum as a starting point for a test, not a production estimate. Community edition is free and limited to a single workspace, so a multi-team rollout on it is a licensing question as well as a sizing one. Enterprise is custom priced and quoted from written scope, so ask the vendor for the sizing assumptions behind any quote.

Indexing and workflow concurrency load different parts of the stack. Document ingestion and embedding runs through the worker, while retrieval hits the vector store and the metadata database, so a team that imports large document sets will feel pressure on the worker and storage before the web tier. Concurrent workflows and agent runs put sustained load on the api and worker processes and on outbound model calls. Measure the peak number of documents per indexing job, the number of simultaneous workflow runs at your busiest hour and the size of your largest knowledge base, then run that workload against a staging host and watch CPU, memory, queue depth and PostgreSQL connections. Confirm the vector store choice before you test, because the default Weaviate container and an external vector store such as Qdrant put very different demands on the host.

Move beyond Compose when the test shows the single host cannot hold your peak, when you need high availability or when uptime targets require the database, Redis and vector store to fail independently. The Enterprise resources checklist describes a Kubernetes production example with six worker nodes, each with 8 CPUs and 32 GB of RAM, plus a three-node Qdrant cluster, and it requires PostgreSQL 14 or later, Redis 6 or later and object storage. Treat that example as the vendor's reference point for scale, not as your target, and ask your team to confirm which components move out of Compose first. Write the test results into the capacity decision record so the next upgrade or model change starts from measured numbers.

Which sizing profile applies to each deployment

The Docker Compose deployment is the smallest documented starting point. The self-hosting docs require at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later. That single host runs the api, worker, web, plugin daemon and other core services, along with PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Every one of those containers draws from the same CPU and memory pool, so the minimum describes a host that can start and run a small evaluation, not a host sized for concurrent users or large document sets.

Shared host resources: The bundled database, cache and vector store compete with the application workers for the same 2 cores and 4 GB, so memory pressure shows up first as slow indexing or failed jobs.
Compose version floor: Hosts with an older Compose release fail the 2.24.0 requirement, so confirm the version with the command you use to run the stack before you install.
Bundled services: The default Weaviate and PostgreSQL containers store data on the same disk as the application, which means backup and recovery depend on that host.
Single failure point: One node means one restart or disk fault stops every workflow and API endpoint.
Version drift: Minor releases arrive roughly monthly, and each upgrade can add variables or services that increase resource needs.

Before relying on this profile for anything beyond evaluation, check the current requirements in the Compose guide and measure your own workload against the host.

Sizing options and when each fits

This table compares five Dify deployment profiles, from a single Compose host to an Enterprise production layout, with the documented starting figures for each. Read it to pick the smallest profile that matches your user load and data sensitivity, then confirm current requirements for the version you plan to run. The main takeaway is that the documented minimums are for evaluation, and production sizing depends on indexing and workflow load.

Profile	What it runs	Documented starting figures	When it fits
Compose single host	All core services, PostgreSQL, Redis, Weaviate, Nginx, code sandbox and SSRF proxy on one host	At least 2 CPU cores, 4 GB RAM, Docker Compose 2.24.0 or later (Dify self-hosting docs)	Evaluation, proof of concept and small teams with light indexing. Not a production sizing baseline.
Compose with external PostgreSQL, Redis and object storage	Same application services, with the metadata database, cache and file storage moved to services you operate	Host figures above remain the floor. Confirm the storage and database sizes for your data volume with your platform team.	Single-workspace production where you want backups, failover and storage managed separately from the app host.
Enterprise testing	Enterprise Helm deployment on Kubernetes with PostgreSQL, Redis, a Qdrant vector database and S3-compatible storage	Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later (Enterprise resources checklist)	Staging and integration testing of the Enterprise feature set, including SSO and multi-workspace setup.
Enterprise production	Enterprise services across worker nodes, a clustered vector store and managed data services	Production example in the checklist uses six worker nodes with 8 CPUs and 32 GB RAM each, plus a three-node Qdrant cluster	Organization-wide use with high availability needs. Treat the example as a reference point and size from your own indexing and concurrency measurements.
Vector store choice	Weaviate as the default, or Qdrant, Milvus, pgvector, OpenSearch or Elasticsearch	Confirm the supported options and sizing guidance for your chosen store in its own documentation	Move to a dedicated vector cluster when index size or query volume outgrows the bundled store.

How knowledge indexing and workflow concurrency drive worker and database load

Knowledge indexing and workflow runs load different parts of a self-hosted Dify, and the first thing to size is the worker. The worker process handles background jobs such as document indexing. Large uploads, chunking and embedding runs consume worker CPU and memory, and every embedding call is an outbound request to whichever model provider or self-hosted endpoint the knowledge base uses. A single bulk import can therefore keep the worker busy for far longer than the number of files suggests, and it can compete with other background jobs for the same host. Measure this by importing a representative document set with the chunk settings you plan to keep, then record worker CPU, memory, queue depth and the time each batch takes to finish indexing.

Workflow concurrency lands on the api service and on database connections rather than on the worker. Each running workflow, chat session or API call holds request handling in the api process and draws connections from the metadata database. Many users running workflows at the same moment can therefore show up first as slow responses or connection wait time, even when CPU looks idle. The metadata database, PostgreSQL by default and MySQL or OceanBase where your standard requires them, grows steadily with apps, workflow logs, conversation records and dataset records, so its storage and connection limits should be planned for growth as well as for peak load. Confirm the database version and connection settings with your database team, and check Dify's environment variable reference for the variables that control these limits in your release.

Agent and code steps add overhead that does not appear in simple chat tests. Each code execution goes through the code sandbox, and outbound requests made by tools or HTTP nodes pass through the SSRF proxy, which filters internal and private addresses. Both add latency and per-request resource use, and that overhead multiplies when many agent runs are active at once. Build a load test that mixes the workflow types your users will actually run, including tool calls and code nodes, and compare results with and without that mix. The test result, not the component list, should decide when you add api replicas, more worker capacity or a separate host for the sandbox.

Which component becomes the bottleneck first

Dify splits work across api, worker, a metadata database, a Redis broker, file storage, a vector store and external model providers. Load rarely lands on all of them at once, so the first constraint to hit depends on whether your workload is indexing documents, running workflows or serving chat traffic.

API and worker processes

The api process handles requests from the console and end users, while worker processes run indexing, workflow and other background tasks. When many documents are indexed at once or workflows queue up, the worker pool becomes the first queue to back up. Check task backlog and worker restarts under load, then add worker capacity or stagger indexing jobs before resizing the database.

PostgreSQL metadata database

PostgreSQL stores apps, workflow definitions, dataset metadata, logs and workspace records. Growth comes from conversation and workflow run history, which accumulates even when the request rate is modest. Watch connection counts, slow queries and disk growth. The first action is usually to add connection pooling and confirm your cleanup and retention settings before scaling the server.

Redis as broker and cache

Redis carries Celery task messages between the api and worker processes and caches data for the platform. A slow or memory-constrained Redis delays every background job at once, which can look like a worker problem. Check memory use, evictions and queue length first. Confirm whether the single bundled instance is holding the broker and cache, and plan a separate, monitored instance before raising worker counts.

Object storage for uploads

Uploaded documents, dataset files and extracted content are written to the configured file storage. Write volume rises with every knowledge base import, and the local disk of a single host fills quietly. Track free space, upload latency and the size of the storage bucket over time. The first action is to move file storage to an S3-compatible service so capacity can grow without resizing the application host.

Vector store capacity

The vector store holds embeddings for every indexed chunk, so its memory and disk needs grow with knowledge base size and the embedding dimension of your chosen model. The bundled Weaviate instance is suited to evaluation and small deployments. Watch query latency, memory and index rebuild time as collections grow. When retrieval slows at production volume, the first step is to test a dedicated cluster, such as Qdrant, sized against your own collection counts.

Outbound model provider limits

Embedding, rerank and chat calls go to model providers or self-hosted inference servers, each with its own rate and concurrency limits. Throttling from the provider often looks like slow workflows or failed indexing, not like a Dify fault. Check provider error responses and retry behavior in logs first. Then request a higher quota, spread load across keys or endpoints, or reduce concurrent indexing before adding Dify hardware.

When Qdrant needs its own cluster instead of the default Weaviate

The bundled Docker Compose stack runs Weaviate as the vector store, and that is the default the environment variable reference documents. Qdrant is one of several documented alternatives, along with Milvus, pgvector, OpenSearch and Elasticsearch. Switching is a configuration decision, but it is also a capacity decision, because the vector store holds the embeddings for every knowledge base and answers every retrieval call. For the Compose profile, the question is whether the single vector container on the host still fits your data. For Dify Enterprise, the answer is already set: the resources checklist requires a Qdrant vector database, and its production example uses a three-node Qdrant cluster. Plan Qdrant as a separate, sized service from the start, not as a container added to the application host.

Four questions decide whether a dedicated cluster is needed. First, dataset size: estimate the number of chunks across all datasets, multiplied by the embedding dimension of each embedding model in use, because that product drives memory and disk. Second, query volume: count retrievals per second at peak, including agent workflows that call knowledge retrieval several times per run. Third, replication and backup: if a vector store outage would stop customer-facing apps, you need replicas and a tested restore path, which a single container does not give you. Fourth, pgvector on the existing PostgreSQL: it can reduce the number of services, but it places embedding storage and similarity queries on the same database that holds Dify metadata, so the metadata database would absorb retrieval load. Confirm the storage and memory needs of your collection sizes, indexing settings and replication factor against Qdrant's own sizing guidance and its documentation before you choose a node count.

How to run a sizing exercise before buying hardware

This sequence turns guesses about Dify load into measured numbers, so the production hardware order rests on a tested staging result rather than the Compose minimum.

Confirm the Dify version and upgrade cadence
The platform team pins the Dify version you intend to run in production and records it with the release it follows. Dify minor releases arrive roughly monthly, for example 1.16.0 on July 17, 2026, and each release can change worker behavior, sandbox components and service counts, so a sizing result is only valid for the version it was measured on. Read the release notes for the target version on the GitHub releases page and note any change to services or dependencies. Done when the version, its release notes and a planned re-test trigger for each future upgrade are written down in the sizing record.
Inventory apps and expected concurrency
The application owner lists every Dify app that will run in production, its type (chatflow, workflow, agent or API-backed app), the model providers it calls and the number of users or API callers expected at peak. Ask each owner for peak concurrent requests and the longest expected run time, since streaming responses and multi-step workflows hold workers for longer than simple completions. Treat the figures as illustrative inputs until a load test confirms them. Done when every app has a row with peak concurrency, average and maximum run time, and an owner who will answer questions during the test.
Estimate knowledge base volume and re-index frequency
The knowledge owner measures the total document count, average document size and total stored text for each knowledge base, along with how often documents are added, replaced or fully re-indexed. Indexing is the heaviest background work in a RAG deployment: embedding calls, chunking and vector writes run in the worker and hit the vector store and database at the same time. Record whether changes arrive as a steady trickle or as a bulk import, because a bulk import can queue hours of indexing behind user traffic. Done when each knowledge base has volume, change rate and a documented bulk-import plan with its expected queue impact.
Pick the vector store and its topology
The architect chooses the vector store before any load test, because the default Weaviate container and the options Dify documents (Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch) have different resource profiles and failure modes. For Enterprise deployments, the Dify resources checklist expects a Qdrant vector database, and its production example uses a three-node Qdrant cluster. Decide whether the vector store shares the host with Dify or runs on its own nodes, and confirm the chosen store's supported versions with its vendor. Done when the store, its version and its topology are recorded and the staging copy runs the same store.
Run a load test on a staging copy
The platform team builds a staging copy that matches the production configuration, including external PostgreSQL, Redis, object storage and the chosen vector store, and replays the concurrency profile from the inventory. Use the same model endpoints as production, or stubs with comparable latency, because model response time changes how long workers stay busy. Run the workflows at expected peak, then at a higher level to find where latency and errors begin. Done when the test completes at the planned peak with error rates and latency recorded against the target agreed with the app owners.
Watch worker queues and database connections
During each test run, the operator watches Celery worker queue depth, worker count and utilization, the API response times and the number of open PostgreSQL connections against the configured pool limit. Dify's worker tier processes indexing and workflow tasks, so a queue that keeps growing after the load ends means the worker tier is undersized or a job is stuck. Check that connection count stays below the configured limit at peak, and that the Redis broker memory stays within its planned allocation. Done when queue depth stays flat or returns to baseline after each run, and database connection count stays below the configured limit at the highest load tested.
Size the production profile from measured results
The architect converts the measured worker, database and vector store figures into a production profile, adding headroom for the planned growth period and for the indexing bursts found in the knowledge inventory. Compare the result with the Compose minimum of 2 CPU cores and 4 GB of RAM, and with the Enterprise production example of six worker nodes with 8 CPUs and 32 GB of RAM each, to confirm whether the production profile sits above or below those references. Request written quotes from any vendor or partner based on this profile, and ask each to state the assumptions behind their hardware counts. Done when the production profile, its headroom assumptions and the re-test trigger tied to the next version upgrade are signed off by the platform and application owners.

Security and operational settings that change with capacity

Several Dify settings look like security or operations decisions, but they also shape how you test and size the platform. Get them right before the first load test, because changing some of them later forces users out or invalidates the results you measured.

Set SECRET_KEY before first use

SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials. Changing it after deployment logs out all users, and it is a poor choice to discover that during a production cutover. Generate a strong value before the first start, store it in your secrets manager, and keep it out of the sizing test environment so load tests reuse the same configuration you will run in production. Confirm the variable name against the current .env.example before you write it.

Test through the SSRF proxy path

SSRF_PROXY settings route outbound requests through a proxy that blocks internal and private IP ranges. Workflow HTTP nodes, tool calls and some model or knowledge calls will therefore take a different network path than a direct connection. A capacity test that calls internal endpoints directly will overstate throughput and miss proxy timeouts. Include the proxy in every test and measure latency on the same route your users will take.

Agent sandbox network isolation

Dify 1.16.1 added agent sandbox network isolation through a Squid proxy. Sandboxed agent code that makes network calls now passes through that isolation layer, which adds latency and can block destinations your agents previously reached. Treat the release as a change to the capacity baseline: rerun agent workflow tests after upgrading to 1.16.1 or later, and confirm which destinations your agents need before you set limits.

Token-based service authentication

Dify 1.16.1 also introduced token-based API authentication between its services. Internal calls between the api, worker and sandbox components now carry credentials, so any custom sidecar, proxy or monitoring check that calls those services directly needs a valid token. Ask your platform team to confirm how health checks authenticate, and include that overhead when you measure request paths that cross service boundaries.

Back up before every upgrade

Dify's Docker Compose guidance says to take a backup before every upgrade and follow the upgrade guide for the target version. Backups cover the metadata database, file storage and vector data. Size your backup window and storage from measured database and object store growth, not from the empty test instance. Restore a backup into a separate environment at least once so the recovery time you plan around is one you have actually measured.

Check .env.example after upgrading

After each upgrade, compare your .env file with the current .env.example because new releases can add variables that default to values unsuited to your environment. A new worker concurrency or timeout setting can change load behavior without any visible error. Record the version and any new variables in your change log, and rerun the capacity baseline after each minor release, which arrives roughly monthly.

Questions buyers ask about Dify sizing and capacity

Is the Docker Compose minimum enough to run Dify in production?

No. The documented minimum for the Docker Compose deployment is 2 CPU cores and 4 GB of RAM, with Docker Compose 2.24.0 or later, and that floor is set for starting the stack, not for serving users. The Compose stack runs the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy on one host, so those services compete for the same CPU and memory. Production sizing depends on concurrent workflow runs, document volume for knowledge indexing, and how many users query apps at once. Treat the minimum as a test baseline and ask for a load test against your own workflows before you commit to a host size.

What drives the cost of a Dify sizing engagement, and is it one-time?

The main cost driver is the number of workloads that must be measured: workflow patterns, knowledge base sizes, embedding and rerank calls, and expected concurrency. Fixed-scope work is agreed in writing before it starts, so the quote should name the environments covered, the workloads tested, and the deliverables such as a sizing report and a configuration baseline. A sizing exercise is normally one-time, but hardware growth, new model providers, larger knowledge bases and each Dify minor release can change the answer, so ask whether re-validation is included or sold as a retainer. Ongoing support and upgrades are available as retainers.

How long does a Dify sizing and load test take?

The duration depends on how many workflows, knowledge bases and model endpoints need testing, how quickly test data and access can be provided, and whether the target environment exists yet. Dify minor releases arrive roughly monthly, based on the release dates on the GitHub releases page, so the test plan should record the exact version under test. Ask for a timeline in the written scope that separates discovery, test environment preparation, test execution and reporting. Any duration you are given should trace back to those named phases rather than a generic estimate.

What does the client team need to provide for a sizing engagement?

Three inputs carry most of the work. First, usage data: the apps and workflows in use, peak concurrent users, typical document volumes and how often knowledge bases are re-indexed. Second, model contracts and endpoints: which providers or self-hosted inference servers are approved, their rate limits, and whether embedding and rerank models run inside your network. Third, network access: a non-production Dify environment, read access to logs and metrics, and approved paths from the test host to model endpoints and object storage. Confirm the data handling rules for any test documents before they are loaded, because sample knowledge base content may be sensitive.

Can an internal platform team size Dify without outside help?

Yes, if the team can run the stack, generate realistic load, and read PostgreSQL, Redis and worker metrics. The hard parts are building representative workflows, separating indexing load from query load, and recognizing when the database or Qdrant becomes the bottleneck. Internal teams often underweight the effect of model latency on worker queues, since slow external calls hold workers longer. Ask whether your team has someone who has run queue and database tuning for a production Celery-based system, and whether the schedule allows repeated test cycles after each configuration change.

When is it worth bringing in a partner for Dify capacity planning?

A partner is worth considering when the deployment has to meet a documented availability target, when several business units will share one platform, or when the team lacks time for repeated load tests. It is also worth it before moving from Compose to a Kubernetes deployment, where Dify Enterprise lists Kubernetes 1.24 or later, Helm 3.14 or later, PostgreSQL 14 or later, Redis 6 or later, and a Qdrant vector database as prerequisites. DeployOpen plans, implements, hardens and supports self-hosted platforms in infrastructure you control, so the useful question is whether the partner will hand over sizing rules and dashboards your team can maintain.

How DeployOpen scopes Dify sizing work

DeployOpen plans Dify sizing as a written engineering exercise tied to your workload, not a guess at hardware. We model worker, database, vector store and storage load against the apps, knowledge bases and concurrency you expect, inside the infrastructure you control.

How we scope

Confirm which Dify edition and deployment method you intend to run, Community Docker Compose or Enterprise on Kubernetes.
Inventory planned apps, workflows, knowledge bases, document volumes and expected concurrent users with your teams.
Agree in writing which test and production profiles, load assumptions and deliverables are included in a fixed-scope engagement.

How we build

Build a sizing model for the api, worker, PostgreSQL, Redis and object storage based on indexing and workflow concurrency.
Run load tests against a staging environment that mirrors the production layout, then compare results with the sizing model.
Decide with you when Qdrant or another vector store needs its own cluster, and document the trigger conditions.

How we hand over

Deliver a capacity report covering the chosen hardware profile, scaling levers and the assumptions behind each number.
Document monitoring thresholds for queues, database connections, memory and disk growth so your team can act on them.
Provide runbooks for scaling workers and resizing dependencies, and walk your operators through them before handover.

How we support

Offer ongoing support and capacity reviews as a retainer, including re-checks before each Dify minor upgrade.
Re-test sizing when your app portfolio, document volumes or user counts change materially.
Confirm any change to the written scope in writing before additional work starts.

Dify sizing and capacity planning