Dify air-gapped and offline deployment

Running Dify in an air-gapped network: what it takes

A regulated team that must keep Dify and its data inside an isolated network should plan on one fact first: the Docker Compose stack can run offline only if every container image, plugin, Python dependency and model call is supplied from inside the boundary. Nothing in the stack is safe to assume will reach the internet at install time or at run time. Dify is an LLM application development platform for building AI workflows, RAG pipelines and agents through a visual interface, with a prompt IDE, LLMOps monitoring and backend-as-a-service APIs. The community edition is free, runs anywhere Docker runs and is limited to a single workspace. The Enterprise edition, which is custom priced, adds SSO, multiple workspaces, advanced security, a commercial license and professional support, and it deploys on Kubernetes. Both editions depend on the same kinds of external supply, so the offline design applies to either.

Two internet dependencies are the usual starting point for removal. The first is the Dify Marketplace, which distributes plugins for model providers, tools and data sources. In an isolated network the Marketplace cannot be reached, so every plugin must arrive as a reviewed .difypkg file that your team installs locally and records in an approved inventory. The second is remote model APIs. A workflow that calls a hosted provider sends prompts and retrieved documents outside the boundary, so each model job, including embeddings and reranking used by knowledge bases, must point at an endpoint you run inside the network. Confirm with your Dify version's documentation which settings disable Marketplace access and which features still attempt outbound calls, because these details change between releases.

Your first decision is an inventory of what the deployment needs to pull or contact: the images named in the Compose file, plugin dependencies, the vector store, the sandbox and any update checks. Each item needs a named source inside the boundary, such as a private image registry, a private PyPI mirror or a local file share, and an owner who signs off on each package crossing the isolated boundary. This is the control that NERC CIP-013-2 describes for verifying software integrity and authenticity before patches enter a protected environment, and it is useful as a model even outside the electric sector. Ask any implementation partner to show how each artifact is verified, how upgrades arrive as new media and how the team will test a release on a staging copy before it reaches production.

Which Dify functions reach the internet by default

A self-hosted Dify reaches out to the internet from several places: plugin discovery, plugin installs, package downloads, container pulls, model APIs and tool calls. Each one must be either removed, routed through a controlled path, or confirmed as unused before the network is isolated. Confirm every behavior against the exact Dify version you deploy, because the outbound paths change between releases.

Marketplace plugin discovery and installs

The Dify Marketplace lets administrators browse and install plugins from the console, which requires outbound access to the marketplace service. In an isolated network this feature should be disabled and plugins should be installed only from .difypkg files that your team has reviewed and stored internally. Check the environment reference for the Marketplace settings in your version, and confirm that the console shows no failed marketplace calls after the network cut.

Plugin package and Python dependency downloads

Plugins can declare Python dependencies that the plugin daemon fetches when a plugin is installed or started. Without a reachable package index, these installs fail in ways that look like plugin bugs. Plan a private package mirror for these dependencies and test each plugin in a staging instance that has no internet route, so that any hidden fetch appears before production.

Container image pulls

The Docker Compose stack pulls images for the api, worker, web, plugin daemon, sandbox, proxy and the bundled databases. Pulls on a host with no route to a public registry fail during upgrades and restarts, not only at first install. Mirror every image tag your version uses into a private registry, pin tags by digest where your process allows it, and record the exact list in your change records.

Third-party model API calls

Model providers such as cloud LLM and embedding services are called from the api and worker processes through the outbound path. In an isolated network these calls will fail unless the endpoint is reachable inside your boundary. Every model job, including embedding and rerank, needs a self-hosted endpoint that the Dify API and worker can reach, and the SSRF_PROXY settings must allow that internal address on purpose rather than by accident.

Outbound tool and HTTP calls

Agent tools, HTTP request nodes and external knowledge sources make requests to URLs chosen by workflow builders. The SSRF_PROXY setting routes these requests through a proxy that blocks internal and private IP ranges, so an internal service you need may be blocked as well. Map each tool to an approved internal destination, add only those exceptions, and review them when workflows change.

Agent sandbox network isolation

Recent Dify releases route sandboxed agent code through a Squid proxy, according to the 1.16.1 release notes. This narrows what sandboxed code can reach, but it does not replace your own egress rules. Verify in a test environment which destinations the sandbox can reach, and confirm that your firewall also blocks direct egress from the sandbox host.

Which offline pattern fits your environment

A fully isolated network has no transfer path after the initial load, so every artifact Dify needs must be inside the boundary before the network is sealed. Treat this as a one-time staging exercise backed by a complete manifest, because a missing wheel or model file cannot be fetched later.

Container images: save every Dify service image plus PostgreSQL, Redis, the vector store, Nginx, the code sandbox and the SSRF proxy, then load them into a private registry inside the enclave. Pin tags and record digests so the manifest matches what you tested.
Plugin packages: stage only the .difypkg files you have approved, and disable the Marketplace so the console does not expect outbound plugin discovery.
Python dependencies and model weights: collect every PyPI wheel your plugins need and every model file your self-hosted endpoints will load, stored on internal media with hashes recorded.
Approval: the security owner signs the image and package manifest, and the data owner approves the model list. Nothing is added after sealing without a new change record.

Before you call staging complete, confirm that a fresh install and a test plugin install both succeed with outbound traffic blocked.

A partially connected enclave keeps a network path to an internal mirror that the enclave can reach, while the mirror controls what enters from outside. Dify still runs without public internet access, so the mirror and registry become the single supply point the enclave trusts, and their sync rules matter as much as the Dify configuration.

Private image registry: mirror only approved Dify and dependency tags, and block pulls from public registries at the enclave boundary.
Private PyPI mirror: host the wheels plugin dependencies need, synced on a schedule through review. Installs inside the enclave resolve only against the mirror.
Plugins: keep the Marketplace disabled and install .difypkg files from a controlled internal store after signature checks.
Models: point Dify at internal inference endpoints for every model job, including embedding and rerank. A missed call fails at runtime, so trace each job to an internal target before go-live.
Outbound filtering: Dify's SSRF proxy blocks internal and private IP ranges by default. Confirm with your version's configuration how that affects calls to internal model endpoints, and allow only the specific targets you need.

The mirror sync list needs owner approval for every change, and a fresh install from the mirror under deny-by-default egress should be tested before each release is adopted.

How to stage Dify for an offline install

This sequence moves a Dify release into a network with no internet access, so every image, plugin, package and model call comes from sources your team has checked. The result is a running instance whose egress has been tested and recorded.

Inventory the target version and its images
Record the Dify version you intend to run, using the release list on the Dify Releases page on GitHub, and read the upgrade notes for that version before you copy anything. Pull the image references from the docker-compose file and .env.example that ship with that release, so the list covers every core service, the plugin daemon, the sandbox and the SSRF proxy. Store the list with its checksums in your change record. You are done when a reviewer can match each image tag to a release note and approve the version in writing.
Mirror container images to a private registry
Pull each image on the connected staging host, retag it to your private registry and push it there. Save the exported image archives and their digests to controlled media, then load them into the isolated network and push them to the internal registry. Update the image references in your Compose files to point at the internal registry, so the air-gapped host never resolves a public name. You are done when every service in the Compose file starts from an internal image and a pull from an isolated host succeeds only against your registry.
Disable Marketplace access
Turn off the Marketplace in the deployment so the console does not try to reach public plugin indexes or download plugins from them. Review the environment reference for the Marketplace and plugin-source settings in your release, and set them to the values your version documents for disabled or local-only operation. Confirm the console still loads and that plugin installation pages show only local installation paths. You are done when the console starts with no Marketplace errors and the setting is recorded in your environment file.
Load and verify signed .difypkg plugins
Obtain each plugin package on the connected side, then check its signature and source before it crosses the boundary. Transfer the verified .difypkg files on approved media, install them through the local plugin installation path, and record the publisher, version and hash for each one. Remove any plugin whose publisher, signature or hash you cannot confirm. Your change process should cover integrity and authenticity checks for vendor software, the kind of control NERC CIP-013-2 addresses for supply chain procurement. You are done when every installed plugin has a matching record and the plugin list shows no unrecorded entries.
Host a private PyPI mirror for plugin dependencies
Some plugins install Python dependencies when they run, and those installs would reach the public package index from an isolated host. Build a private PyPI mirror on the staging side with the packages your plugins declare, including transitive dependencies, and copy it into the isolated network. Point the plugin runtime's package index setting at the internal mirror and block public index hosts at the firewall. Confirm the dependency list against each plugin's manifest before you mirror it. You are done when a fresh plugin install resolves all dependencies from the internal mirror and no request leaves for the public index.
Point model settings at self-hosted endpoints
Configure every model job to use an endpoint inside your network, including chat, embedding, rerank, and any speech or vision models used by workflows or knowledge bases. Options such as Ollama, vLLM or an OpenAI-compatible gateway can run entirely inside the boundary, but confirm each one with your model vendor and your own environment before you rely on it. Store the endpoint credentials in the Dify model provider settings, and remove any cloud provider entries that cannot be reached. You are done when each model type in every app and knowledge base resolves to an internal address and a test call returns a response.
Run a connectivity test that proves no unexpected egress
Place the Dify host behind a firewall that drops outbound traffic by default and allows only the internal registry, mirror, model endpoints, database and object storage. From the host and from inside each container, attempt connections to public DNS names and public IP addresses, and record which ones fail. Run a workflow that calls a model, an embedding and a knowledge base search, and capture the flows at the firewall to confirm they stay internal. Keep the test script and results with the change record so an auditor can rerun it. You are done when the logs show no unexpected outbound connection and the test passes on a clean restart.

How signed plugins and dependency mirrors keep the supply chain verifiable

Every item carried across an isolated boundary needs an integrity and authenticity check before it is trusted, because an offline network cannot ask a vendor whether a file is the one it published. In a Dify deployment that covers container images, .difypkg plugin packages, and the Python packages that plugins pull in during installation. For OT-regulated buyers, NERC CIP-013-2 offers a general example of the expectation: supply chain procurement should address verifying the integrity and authenticity of vendor software and patches. Treat that as a pattern for your own change process. It does not show that Dify is certified against the standard. The check happens once at the boundary, and the record of that check is what reviewers and auditors will ask to see.

The controls that make this reviewable are simple to name and easy to skip. Pin each image by digest instead of a floating tag, and record the digest next to the Dify version in your change record. Store plugin packages in a versioned folder with a SHA-256 checksum file, so a reviewer can recompute the hash on the inside of the boundary and compare it with the value recorded at the source. For Python dependencies, use a lock file that pins every version with hashes, build the private mirror from that lock file, and keep a dated snapshot of the mirror index. A snapshot lets you reproduce an install months later and shows exactly what the cluster was allowed to fetch. Make the mirror read-only for the Dify hosts.

The part the team must confirm is how Dify itself checks .difypkg signatures. Ask Dify which signing keys the plugin daemon trusts, whether an unsigned or altered package is refused by default, and whether verification needs any network call that an offline host cannot make. Check the documentation and release notes for the exact version you pin, starting with the Dify releases page, and test the behavior in staging with a deliberately altered package. Record the result. If Dify does not enforce what your policy requires, your own signature and checksum gate at the boundary becomes the control of record, and it needs an owner and a documented procedure.

Every model job needs a reachable endpoint inside the boundary

A Dify deployment without internet access still needs a model for every job that calls one. Generation, embeddings, rerank, moderation and plugin calls each need an endpoint the Dify services can reach from inside your network, and each must be confirmed separately.

Text generation endpoints

Workflows, chatflows and agents call a generation model at every LLM node. Inside the boundary, the usual choices are Ollama or an OpenAI-compatible server such as vLLM. Open WebUI documents running entirely offline with Ollama or OpenAI-compatible APIs, which shows the same pattern works for a chat front end. Confirm that the model you choose supports the tool calling and context length your workflows depend on, because those features vary by model and server.

Embedding and rerank models

Knowledge base indexing calls an embedding model for every chunk, and retrieval may call a rerank model on each query. Both run on the same Dify workers and API, so a missing endpoint fails ingestion or search rather than a single chat. Confirm the embedding dimension matches the vector index you configure, and confirm that rerank support exists for your chosen server before you plan the knowledge base design.

Moderation and classifier calls

Moderation nodes and any classifier step that uses a model send user content to that model. If the moderation model is a remote service, the call leaves your boundary and the design fails your offline requirement. Choose a model you host, or disable the step and document that decision. Test moderation with a prompt that should be blocked to confirm the local model returns results.

Tool and plugin model calls

Plugins and custom tools can call models of their own, and those calls do not appear in the workflow model list. Review each installed plugin's configuration for model credentials and endpoints, and confirm that every plugin resolves to a host inside the network. A plugin that reaches a public API will fail silently or hang in an isolated network, so test each one before it reaches production.

Per-job model inventory

Keep a written inventory that lists each job, its model, its serving software, its version and its endpoint. This turns model support into a checked list rather than an assumption. Ask the vendor or project for the supported model list and the offline behavior of each serving option, and record what you verified in your own environment.

What do buyers ask before running Dify offline?

What drives the cost of an offline Dify installation?

Scope drives most of the cost. The Community edition is free and limited to a single workspace, according to the Dify pricing page, so the main costs are labor, hardware and infrastructure. One-time costs include the build, staging, and acceptance testing of each plugin you install. Recurring costs include refreshing the package mirror and private image registry for each release, rebuilding offline bundles, and hosting every model job on your own endpoints. Costs rise with the number of model providers and plugins, the knowledge base volume, and whether PostgreSQL, Redis and object storage move to external services. Ask for a quote that breaks these into written line items, with stated assumptions about hardware, model endpoints and release cadence.

How long does it take to stage an offline Dify deployment?

No duration can be stated responsibly without the scope, so ask for a schedule tied to written deliverables. The main drivers are the number of self-hosted model endpoints, the plugins that need review, the size of the registry and package mirror, and how many approval cycles your security and change processes require. Dify ships minor releases roughly monthly, so a staged install should include a repeatable transfer process rather than a one-time copy. Ask the provider to show which steps run in your environment, which need your approvals, and which depend on your network team's transfer windows.

What does an offline Dify project need from our internal teams?

Four groups carry most of the work, and each needs a named owner before the build starts:

Network team: egress rules, the transfer path across the boundary, and confirmation that the Compose stack reaches only approved internal addresses.
Registry owner: a private image registry that holds every image the Compose stack and plugin daemon need, plus a package mirror for plugin dependencies.
Model platform owner: self-hosted endpoints for chat, embedding and rerank models, with credentials managed inside your environment.
Security approver: sign-off on what crosses the boundary, how each package is verified, and how the SECRET_KEY and other secrets are stored.

Without these owners, the build usually stalls at the transfer step.

Can our own team run an offline Dify deployment without a partner?

A capable platform team can do it alone if it already runs Docker Compose, PostgreSQL, Redis, a private registry and self-hosted model servers. The Dify Docker Compose guide requires at least 2 CPU cores, 4 GB of RAM and Docker Compose 2.24.0 or later, and the stack starts api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Teams most often lack experience with offline plugin verification, mirror tooling and rehearsing upgrades without internet access. A partner can cover those gaps under a fixed scope. Either way, decide ownership of each component in writing before the build starts.

How do Dify upgrades change the offline bundle?

Each upgrade is a new bundle, not just a new image tag. Minor releases arrive roughly monthly, so your team should expect to rebuild and retest the offline set on that cadence. For each release, rebuild the image set, confirm the plugin versions you depend on still install from your local .difypkg files, refresh the package mirror, and retest model connections. Follow the upgrade guide for the target version, take a backup before every upgrade, and check .env.example for new variables. Confirm with the vendor how plugin compatibility changes between versions, since that behavior depends on the release.

How does an Enterprise license relate to air-gapped use?

The license decides which features and rights you have, and air-gapped use is a separate question to confirm in writing. The Community edition is free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support, according to the Dify pricing page. The Dify Open Source License also prohibits operating the source code as a multi-tenant environment, meaning more than one workspace, without written authorization. Ask the vendor to confirm in writing whether your disconnected deployment, its update process and any support delivery fit the license you choose.

Which controls should we check for packages carried across an isolated boundary?

Verify the integrity and origin of every package before it enters the network, and record the result. This covers Dify images, .difypkg plugins, Python dependencies from the mirror, and model weights. If you are a NERC-regulated entity, CIP-013-2 addresses verifying software integrity and authenticity for vendor software and patches, which maps directly to this step. Also review the SECRET_KEY handling, the SSRF proxy settings that block internal and private IP ranges, and the outbound rules for the code sandbox. Confirm with your compliance lead which evidence an auditor will expect, since DeployOpen prepares that evidence but independent auditors issue any assessment result.

What should a written quote for offline Dify include?

A useful quote lists deliverables, not hours alone. Ask for the scope of each component: the Compose or Kubernetes layout, the private image registry, the package mirror, the plugin review and installation process, the self-hosted model endpoints, and the backup and restore procedure. It should state what runs in your environment, what you must provide, which approvals are needed, and how upgrades will be rehearsed. Ask which items are one-time and which recur, such as mirror refreshes and release rebuilds, and what a support retainer covers. Most engagements are fixed scope, so the agreed scope and timeline should appear in the written document before work starts.

What to confirm in your environment before committing

An offline Dify deployment depends on a few decisions that vendor documentation settles differently by edition and release. Confirm the license position, the Enterprise support model, plugin trust, the Marketplace switch and every external dependency before you order hardware or sign a statement of work.

License fit for your deployment model

The Dify Open Source License is a modified Apache License 2.0 that forbids operating the source code as a multi-tenant environment, where one tenant is one workspace, without written authorization. Community is limited to a single workspace, so a shared offline platform serving several business units may need Enterprise or written permission. Confirm with Dify which edition and terms match how many workspaces and internal tenants you plan to run.

Enterprise offline support and resources

Community is free, but the Enterprise edition adds SSO, multiple workspaces and professional support, and its Kubernetes checklist lists PostgreSQL 14 or later, Redis 6 or later, Qdrant and object storage. Ask the vendor in writing whether Enterprise supports installation without internet access, which chart and image channels it uses, and how license activation works when the network has no outbound route.

Plugin signature verification behavior

Locally installed .difypkg files are only as trustworthy as the checks the plugin daemon applies. Confirm in the target release whether signature verification is enforced by default, which keys it trusts, whether unsigned plugins can be forced through, and where the verification result is logged. Test with a deliberately altered package before you rely on the control for a regulated boundary.

Marketplace disable setting in your version

Setting the Marketplace off is the first step in an offline build, but the variable name, default and effect can change between releases. Read the environment variable reference for the exact release you will run, confirm that the web console hides marketplace calls, and check that plugin install from the console fails cleanly rather than timing out on every page load.

Dependencies that still resolve externally

Test the stack in a network with no route to the internet and watch for failed lookups. Typical candidates include plugin dependency installs that reach PyPI, container image pulls, model provider endpoints, update checks, telemetry, and any URL a knowledge base or tool calls. Record each outbound destination, then decide whether it is mirrored, proxied through SSRF_PROXY settings, or removed.

Release cadence and upgrade path

Dify minor releases arrive roughly monthly, so an offline mirror goes stale quickly. Confirm how you will import each new image, plugin package and dependency set, who validates them, and whether the upgrade guide for the target version needs network access. Plan backups before every upgrade and check .env.example for new variables.

How DeployOpen scopes an offline Dify deployment

DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure, including air-gapped networks where nothing is pulled from the internet at runtime. For an offline Dify deployment, that means the scope starts with an inventory of everything the platform needs to reach or load: container images, Python packages for plugin dependencies, plugin packages, model endpoints, and the update path for each. Most engagements are fixed-scope, so the boundary of that inventory, the deliverables and the timeline are agreed in writing before any build work begins. Your team keeps a clear record of what was approved to cross the isolation boundary and why.

Scoping also covers the parts of an offline Dify rollout that outsiders often miss: which Marketplace and update checks are switched off, how signed .difypkg files are reviewed and installed, where the private package mirror and image registry live, and which model jobs (chat, embedding, rerank, and any moderation or evaluation steps) run on hardware you operate. DeployOpen can also run security testing against the finished stack and prepare the systems, configuration and evidence that a compliance assessment will ask for. DeployOpen does not issue audit reports, attestations or certifications; independent assessors and certification bodies do that work.

We recommend starting with a written scope discussion. Bring your network diagram, your approved transfer process, the model endpoints you can host, and your target Dify version, so the scope can name the decisions your team must make and the checks you will need to sign off. Confirm with us which deliverables you expect (runbooks, configuration baselines, test results, backup and restore records) and who on your side approves each one. Contact DeployOpen to start that conversation and receive a scope you can review before work starts.

Dify in air-gapped and offline networks