How Dify upgrades work after go-live
Most organizations running a self-hosted Dify handle upgrades in-house, with a partner brought in for larger version jumps, a failed upgrade or a security-driven change they cannot schedule themselves. The deciding factor is usually whether someone on your team owns the platform week to week and has time to read each release before it reaches production. Upgrades are not optional maintenance you can defer indefinitely, because Dify ships new minor releases roughly every month and each one carries its own changes. Upgrade work is triggered by several events, and each one needs a different response. A new release is the routine trigger, and the upgrade guide for the target version on the Dify GitHub Releases page is the starting point. A security fix is the urgent trigger: Dify 1.16.1 release notes describe changes to agent sandbox network isolation through a Squid proxy, token-based authentication between services and sandboxed Jinja2 template rendering, so confirm whether a release touches these areas before deciding how fast to move. A failed upgrade, a new model provider you need to add, or a change in the team that operates the platform will also start the work. Each trigger should have a named owner and a written record of what changed. Every upgrade on Docker Compose should begin with a backup, which Dify's own Compose documentation recommends before every upgrade. Back up the metadata database, the file storage and your environment file, and keep the previous .env values so you can compare them. After the upgrade, check .env.example in the new version for variables you did not set before, because a missing variable can change behavior silently. Plugin daemon changes follow the same pattern: confirm that installed plugins still load and that the plugin daemon service is healthy before you release the environment back to users. The Community and Enterprise editions differ in who owns support. The self-hosted Community edition is free and limited to a single workspace, so the upgrade path, testing and rollback are your responsibility, with your team or a partner. The self-hosted Enterprise edition is custom priced and includes professional support, so the contract defines what the vendor covers. Ask the vendor in writing which support is included, what response is committed, and whether upgrade assistance is part of the agreement, because the public pricing page does not list support levels. Whatever edition you run, write a scope before the first upgrade after go-live. It should name the environments that get upgraded first, the test cases that prove each workflow still runs, the rollback steps, and who approves production changes. A fixed-scope upgrade project or a support retainer can cover this work, and the written scope is what lets you compare an internal plan with a partner quote on equal terms.
What a Dify upgrade and support engagement includes
An upgrade and support engagement covers the steps between one Dify release and the next, from assessing the running version to keeping the upgraded system supported after go-live. The cards below follow the order of work, and the deliverables at the end are what the client keeps when the engagement closes.
Pre-upgrade assessment
We record the running Dify version, the Docker Compose file, the .env values in use and any custom changes to Nginx, the plugin daemon or the sandbox. Dify ships minor releases roughly monthly, so the gap between the running and target versions determines how many upgrade guides must be read and in what order. The assessment ends with a list of configuration items that the upgrade could affect.
Backups before each upgrade
Before any change, we back up the metadata database (PostgreSQL by default, or MySQL or OceanBase if that is what the client runs), the file storage location and the vector store behind knowledge bases. The Dify Docker Compose documentation recommends a backup before every upgrade. We confirm that each backup restores to a scratch environment, because an unrestored backup is not a recovery plan.
Following the target version guide
Each upgrade follows the upgrade guide for the target version published on the Dify GitHub Releases page, not a general procedure. We record which guides apply between the running and target versions and note any step that requires a manual action. Where a release changes security behavior, such as the agent sandbox network isolation and token-based service authentication introduced in 1.16.1, we verify that the new behavior is active after the upgrade.
Reviewing new environment variables
After an upgrade, we compare the client's .env file with the current .env.example. New variables are added with defaults that may not suit the environment, and renamed variables silently stop taking effect. We document each change, decide the value for the client's environment, and record why. Values that sign session cookies, encrypt OAuth credentials or route outbound traffic through the SSRF proxy are reviewed with particular care.
Staging copy upgrade
We run the upgrade first on a staging copy built from a recent backup, using the same Compose file, images and configuration as production. The staging run confirms that containers start, migrations complete and the plugin daemon reconnects. Results from staging set the production change window and the rollback steps. Staging must hold real data volumes, or the test is weaker than it appears.
Post-upgrade verification
After the production upgrade, we check that existing apps run their workflows, that knowledge bases return retrieval results from the vector store, and that every model connection still authenticates against its provider. We also confirm that user sign-in works and that outbound calls from agents and tools pass through the configured proxy. Each check is written down with its result so that a later regression can be traced to a version.
Ongoing support under a retainer
Between upgrades, support covers monitoring of new releases, planning of upgrades against the client's change calendar, and investigation of issues that appear after a version change. Retainers are agreed in writing, so the scope, deliverables and what is excluded are fixed before work starts. Response times are defined in the agreement, not assumed here, and clients should confirm them before signing.
Upgrade record and configuration documentation
The upgrade record lists the versions moved between, the guides applied, the backups taken, the variables changed and the verification results. Updated configuration documentation describes the current .env values, Compose overrides and component versions, so the next engineer can work from it. Together these documents show what changed and why, which matters for audit evidence and for diagnosing faults.
Rollback plan and support runbook
The rollback plan states the restore order for the metadata database, file storage and vector store, the image tags to return to, and the decision point at which rollback is chosen over repair. The support runbook covers routine tasks such as restarts, log locations, backup checks and escalation paths. Both documents are tested against staging before the client relies on them.
Why Dify's monthly release pace changes your upgrade plan
A team that upgrades its self-hosted Dify once a year is not making one upgrade. It is crossing many versions at once. The GitHub releases page shows 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026, so minor releases arrive roughly monthly. Each skipped release adds guide steps, configuration changes and compatibility checks that someone has to carry out in order. Decide early whether you will upgrade on a fixed cadence, such as after each minor release, or in planned batches, and write that decision into your operating procedures.
Release notes also carry security changes, and these matter as much as features. The 1.16.1 notes describe agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. Each one changes a boundary your team may depend on. Network isolation can affect outbound calls from agents and tools, token authentication can break internal scripts that call Dify's APIs without credentials, and template rendering changes can alter prompts or workflow outputs. Review each security item against your own network rules, proxy settings and custom integrations before you approve the upgrade.
Read the upgrade guide for every version between your current release and your target, not only the final one. The Docker Compose documentation says upgrades follow the guide for the target version on the GitHub Releases page, recommends a backup before every upgrade and advises checking .env.example for new variables afterward. Record which guides you followed, which settings you changed and who approved the change. Confirm each version's breaking changes in its guide rather than assuming the previous version's steps still apply. Take a backup before each step, not only before the final one, so that a failed intermediate upgrade can be rolled back.
The plugin daemon needs its own check. The Compose stack runs it as a core service next to the api, worker and web containers, and it manages the model and tool plugins your apps depend on. Its configuration, behavior and compatibility with installed plugins can change between versions. Make an inventory of the plugins in use, check each one against the target release notes and test a sample workflow for each model provider after the upgrade. Ask whether your support arrangement covers plugin compatibility testing for each release, since that work grows with every version you adopt.
What each phase of a Dify upgrade produces
The sequence moves a self-hosted Dify instance from its current version to a target version in a controlled order, with each phase leaving a record that the next one depends on. Every phase has an output your team can inspect, so the cutover decision rests on evidence rather than memory of the earlier work.
Inventory the current Dify installation
The upgrade starts with a written record of what runs today: the Dify version, image tags, the .env file in use, the metadata database, vector store and file storage chosen at deployment, installed plugins and any local changes to Compose or Nginx files. Your platform team or the DeployOpen engineer compiles the record. The phase is done when someone outside the original deployment can read it and name the version being upgraded from and every component the upgrade touches. Confirm which apps, knowledge bases and integrations depend on this instance, since those determine what the post-upgrade checks must cover.
Confirm Compose version and extensions
The Docker Compose deployment requires Docker Compose 2.24.0 or later, so each host is checked against that minimum before any change is planned. The output is a recorded Compose version per host and a list of any override files, extensions or wrapper scripts that alter the stock Compose configuration. If a host is below the minimum, the Compose upgrade becomes a separate change with its own rollback plan. Ask your platform team whether configuration management tooling could overwrite local overrides during the upgrade.
Back up and test the restore
Dify's Docker Compose documentation recommends a backup before every upgrade. This phase produces a complete backup of the metadata database, file storage and configuration, including the SECRET_KEY value and vector store data. A backup counts only after a restore has been rehearsed on a separate host and the restored instance signs in, opens an app and returns a knowledge base answer. Record backup identifiers, checksums and the restore result in the change record. Confirm with your storage team how long a restore takes, since that sets the rollback window you can commit to.
Upgrade a staging copy
A staging environment is built from the production backup and upgraded by following the upgrade guide for the target version on the GitHub Releases page. The phase produces a staging instance on the target version, a log of every manual step and every deviation from the guide, and a list of the apps, workflows and knowledge base queries that were exercised. Dify minor releases arrive roughly monthly, so the target version is fixed in writing before staging begins. The phase is complete when the test cases run without errors in the api and worker logs.
Update the environment file and secrets
Compare .env.example in the target release with the production .env and decide on each new variable, setting values that fit your environment. Keep SECRET_KEY unchanged unless you accept the consequence: changing it after deployment logs out all users, because the key signs session cookies and JWTs and encrypts OAuth credentials. The output is a reviewed diff, a configuration file held in version control or a secrets store, and a short record of each variable decision. Confirm with your security team who approves any SECRET_KEY rotation and where the value is stored.
Check the plugin daemon
The plugin daemon runs alongside the api and worker services, so the upgrade confirms that it starts on the target version and that installed model and tool plugins still load. The check compares the plugin list before and after the upgrade and tests at least one call for each model provider that production apps use. The output is a pass or fail record per plugin and a note of any plugin that needs an update before cutover. Confirm with the plugin owners which providers carry production traffic, since those must pass before cutover.
Cut over production
Production cutover runs inside the agreed change window. It covers a final backup, stopping writes where the workload requires it, applying the target version and reviewed configuration on the production host and starting the stack. The output is a running production instance on the target version, a timestamped change log and a rollback decision point documented before the window opens. Confirm with the application owners how they will be notified and who has authority to roll back, and make sure that person is reachable for the whole window.
Run post-upgrade checks
Post-upgrade checks confirm that the service works end to end on the target version. They cover sign-in, a sample of published apps, workflow runs that call external models, knowledge base retrieval, file upload and the outbound path through the SSRF proxy to any external tools. The output is a signed test record that reuses the staging cases, plus a monitoring baseline for the period that follows. Any failure is fixed or rolled back under the change plan. Confirm which checks your team owns after go-live, since that defines what ongoing support must cover.
What drives Dify upgrade and support effort
This table lists the factors that change how much work each Dify upgrade and ongoing support takes, why each one adds effort, and the step that keeps it manageable. Check each row against your own installation before agreeing on a support scope. The main takeaway is that most effort comes from custom components and non-default infrastructure, so inventory those first.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Workspaces and apps | Each workspace and app has its own prompts, workflows and knowledge base connections that need re-testing after an upgrade. | Keep a current inventory and export app DSL files as a recovery reference before each upgrade. |
| Plugins and custom tools | Third-party plugins and custom tools can break when the plugin daemon or API behavior changes between releases. | Pin versions, name an owner for each plugin, and test each one in staging before production. |
| Custom code nodes | Code nodes run in the sandbox, so changes to sandbox or template rendering can alter their output. | Keep code nodes small, add tests with expected outputs, and document each node's dependencies. |
| Metadata database and object storage | PostgreSQL, MySQL, OceanBase, OpenDAL and S3-compatible storage each add their own backup, restore and migration steps. | Use the default where your standards allow, and script database and file store backups together. |
| Vector store | Weaviate is the default. Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch each need separate index and compatibility checks. | Choose a store your team already operates and confirm compatibility with the target Dify version first. |
| Deployment method | Docker Compose upgrades are simpler. Kubernetes adds Helm chart, cluster version and node upgrade work. | Keep Docker Compose at 2.24.0 or later, or document Helm and cluster versions in the runbook. |
| Number of environments | Each environment needs the same upgrade, .env changes and test pass, so effort multiplies with every copy. | Promote the same tested configuration through development, staging and production in that order. |
| Edition | Enterprise adds SSO, multiple workspaces and vendor support, which add settings to maintain. Community runs one workspace. | Confirm in the written scope which edition and support terms apply before setting the support boundary. |
| Versions skipped per upgrade | Minor releases arrive roughly monthly, so a long gap crosses several upgrade guides and .env changes. | Upgrade in small steps, reading each version's guide and checking .env.example at every step. |
What goes wrong in Dify upgrades and how to prevent it
Most failed Dify upgrades trace back to a few habits: skipping the backup, testing on the live system, and carrying old configuration forward. Each card names the prevention step and the team that should own it. Assign these owners before the first upgrade, not after the first incident.
Upgrading without a backup or rehearsal
Upgrades that start without a fresh backup, or that go straight to production, leave no clean way back. The Dify Docker Compose guidance recommends a backup before every upgrade, and that backup is only useful once a restore has been tested. Prevention: back up the metadata database, file storage and the .env file, then upgrade a staging copy by following the guide for the target version on the GitHub Releases page. Owner: the platform team, with a named approver for each production change.
Missing new .env variables and old proxy settings
Some releases add variables to the environment template, and settings such as the SSRF proxy and code sandbox can keep values chosen for an older version. A copied .env file may start without a visible error while missing new features or weaker protections. Prevention: after each upgrade, compare your .env against the .env.example for the target version and review every security-related value. Owner: the platform engineer who runs the deployment, with the security team approving proxy and sandbox settings.
Changing SECRET_KEY during an upgrade
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials. Changing it after deployment logs out all users, and it can affect access to stored OAuth credentials. Regenerating the key during an upgrade is a common self-inflicted outage. Prevention: keep the existing value in your secret store, confirm it is unchanged in the new .env before restarting, and add that check to the change checklist. Owner: the platform owner, who controls access to the secret store.
Plugin daemon and vector store drift
After a version jump, the plugin daemon may expect a different plugin interface, so installed plugins can fail until they are updated. Knowledge bases depend on the vector store, and a store that falls out of step with the Dify release can return poor retrieval or fail to load. Prevention: list installed plugins and knowledge bases before upgrading, then test a plugin run and a retrieval query in staging. Owner: the platform team for the stack, with each app owner validating their own knowledge bases.
Unowned version tracking
Dify minor releases arrive roughly monthly, and each has its own upgrade guide. Without a named owner, teams either fall behind on security fixes, such as the agent sandbox network isolation added in 1.16.1, or upgrade without reading what changed. Prevention: record the running version, watch the GitHub releases page, and set a monthly review to decide which upgrades to schedule. Owner: a named platform lead who approves each upgrade window.
Which upgrade and support tasks stay in-house and which go to a partner
This table compares the upgrade and support tasks a self-hosted Dify platform team usually keeps with those organizations often outsource, and names the skills each task needs. Use it to decide which gaps in your own team would need a partner before the next minor release arrives. The main takeaway is that app and business decisions usually stay with your owners, while container, database and configuration work is where outside help is most often requested.
| Task | Usually kept in-house | Often outsourced | Skills needed |
|---|---|---|---|
| Monitoring releases | Platform lead watches the GitHub releases page and triages which versions matter to your deployment | Retainer partner posts a release digest with impact notes for your stack | Reading release notes, judging security impact, Dify component knowledge |
| Approving changes | Platform owner and security sign-off on each upgrade window | Partner prepares a written change plan for your approval | Change management, risk assessment, Dify configuration knowledge |
| App owner testing | Business app owners test prompts, flows and knowledge base answers after staging | Partner runs scripted regression checks on sample apps | LLM application knowledge, test case design, domain expertise |
| User support for prompts and flows | Internal help desk and app builders handle questions about prompts, flows and outputs | Partner handles second-line escalations under a retainer | LLM application knowledge, workflow node debugging, support triage |
| Backup verification | Platform team confirms backup jobs run and retention is in place | Partner restores backups into a test environment and checks PostgreSQL and file storage consistency | PostgreSQL administration, object storage operations, restore testing |
| Staging upgrades | Platform team owns the staging environment and runs a first upgrade pass | Partner performs the staging upgrade, records every step and reports issues | Container operations with Docker Compose, PostgreSQL administration, Redis and Weaviate operations |
| Reviewing .env and plugin daemon changes | Platform team tracks changes against .env.example and records decisions | Partner compares the new .env.example with your file, checks plugin daemon config and flags security-relevant variables | Environment variable configuration, plugin daemon operations, security review of SECRET_KEY and SSRF proxy settings |
| Retainers for ongoing monitoring | Internal team keeps incident ownership and business contact | Partner provides scheduled upgrades, monitoring and on-call coverage under a written retainer scope | Container operations, security review, incident response, written scope management |
How upgrades differ by starting point and environment
A Community edition deployment on Docker Compose upgrades on a single host by replacing the service images and updating the local configuration. The Dify Docker Compose docs direct you to the upgrade guide for the target version on the GitHub Releases page and recommend a backup before every upgrade. Because the stack includes the api, worker, web, plugin daemon, code sandbox and SSRF proxy alongside PostgreSQL, Redis and Weaviate, each of these moves with the release.
- Back up first: capture the metadata database, the vector store data and the storage volumes before you pull new images.
- Compare .env: after upgrading, check the target release's .env.example for new variables and copy the ones you need into your .env file.
- Check Compose version: confirm Docker Compose is at 2.24.0 or later, which is the minimum in the self-hosting docs, and any higher minimum in the target release notes.
- Review service changes: read the release notes for changes to the plugin daemon, code sandbox and SSRF proxy, since these affect plugins and workflows.
- Keep SECRET_KEY unchanged: changing SECRET_KEY after deployment logs out all users, so keep the existing value through the upgrade.
Confirm the target version, its upgrade guide and a tested restore procedure before you schedule the maintenance window.
Dify Enterprise on Kubernetes is upgraded through its Helm chart and your cluster's change process. The main dependencies, including PostgreSQL, Redis, the Qdrant vector database and S3-compatible object storage, usually run as separate services that have their own upgrade schedules. The Dify Enterprise resources checklist sets minimums of Kubernetes 1.24 or later and Helm 3.14 or later, so check both before planning the change.
- Check cluster versions: confirm the cluster meets Kubernetes 1.24 or later and Helm 3.14 or later, and check whether the cluster itself is due for an upgrade in the same period.
- Check dependency compatibility: the checklist requires PostgreSQL 14 or later and Redis 6 or later, so confirm that the running versions are supported by the target release.
- Review values changes: compare the chart's values files against the previous release, then render the manifests and review them before applying.
- Confirm rolling capacity: the checklist's production example uses six worker nodes with 8 CPUs and 32 GB of RAM each, so confirm that your cluster has headroom to replace pods during a rolling update.
- Snapshot stateful services: take database snapshots and object storage backups, and confirm that the restore steps have been tested.
Confirm with your Enterprise support contact which chart version maps to which application release before you start.
A deployment several releases behind needs the upgrade guide for each version it passes on the way to the target, not only the final one. Minor releases arrive roughly monthly, so a gap of a few months can cover many releases. For example, an illustrative move from 1.16.0 to 1.17.1 would pass through 1.16.1 and 1.17.0, and each of those releases may carry its own configuration and behavior changes.
- Map the path: list every release between your current version and the target, and read each upgrade guide in order.
- Rehearse on a copy: restore a recent backup into a staging environment and run the full sequence there before touching production.
- Review security changes: release 1.16.1 changed agent sandbox network isolation through a Squid proxy, token-based authentication between services and sandboxed Jinja2 template rendering, so agents and templates may behave differently.
- Compare .env files at each step: check your .env against each intermediate version's .env.example, since new variables may be added and later removed.
- Verify app behavior: after each step, check app DSL, model provider credentials and knowledge base index settings with a short set of test runs.
Confirm the full sequence of releases and a rollback point before the first upgrade step begins.
In an air-gapped environment, the upgrade starts outside the network. Release artifacts, container images, chart or Compose files, and upgrade guides must be obtained, checked and carried in through your controlled transfer process. The cluster or host cannot pull new images or chart versions from public sources, so every dependency needs to be staged before the maintenance window opens.
- Build an artifact list: include container images for every service, including the plugin daemon, code sandbox and SSRF proxy, plus the Compose file or Helm chart and the .env.example for the target version.
- Mirror and verify: stage the artifacts in your internal registry and verify them using your own integrity checks before they enter the environment.
- Stage dependencies: confirm the PostgreSQL, Redis, vector store and object storage versions the target release needs, and stage their images or packages too.
- Plan plugin installation offline: identify which plugins and model provider packages must be installed without internet access, and confirm how they are imported.
- Record the transfer: route the transfer through your change and security approval steps, and keep a record of what was imported and when.
Confirm the lead time for your transfer process with its owner, and test the full import in a staging enclave before the production window.
Custom plugins, custom tools and code nodes depend on Dify internals that can change between releases, so they add a compatibility step to every upgrade. Code nodes run in the code sandbox and plugins run under the plugin daemon, so both need to be tested against the target release rather than assumed to keep working.
- Check plugin compatibility: confirm each custom plugin's version against the target release, and check whether the plugin daemon version changes in the same upgrade.
- Test code nodes: run each code node in the sandbox after the upgrade, because the sandboxed Jinja2 rendering change in 1.16.1 may alter outputs that depend on template behavior.
- Recheck API-based tools: review how internal endpoints are called, how tokens are handled and which hosts the SSRF proxy allows, since service authentication and outbound routing changed in 1.16.1.
- Rebase source patches: if you have modified Dify source, rebase each patch onto the target release, record every change and retest it.
- Keep a regression set: maintain representative workflows and agent runs with expected outputs, and rerun them after each upgrade.
Confirm who owns each custom component and which regression results must pass before the upgrade is approved.
Recurring costs after go-live: hosting, support and upgrade effort
This table lists each cost line that continues after a self-hosted Dify goes live, who is paid for it, and what to ask for in a quote. Read the recurring rows as the budget you carry every year, and the one-time rows as costs that return only when you change scope or rebuild. The main takeaway is that infrastructure and model spend are only part of the picture, because staff time for monitoring and each minor release is a steady cost that a partner retainer can shift but not remove.
| Cost line | One-time or recurring | What drives it and what to ask for |
|---|---|---|
| Compose or Kubernetes infrastructure | Recurring | Docker Compose needs at least 2 CPU cores and 4 GB of RAM as a floor, not a sizing. Ask for production sizing for your user count, and for Kubernetes, the Enterprise checklist production example (six worker nodes, 8 CPUs and 32 GB each, plus a three-node Qdrant cluster). |
| Model provider and vector store spend | Recurring | Model tokens and any GPU capacity scale with usage. Vector store and object storage grow with knowledge base size. Ask for an estimate per model and per knowledge base, based on your expected traffic and document volume. |
| Enterprise subscription (if chosen) | Recurring | Enterprise is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Ask Dify for a written quote that states term, included support levels and what is excluded. |
| Dify Cloud list prices (comparison only) | Recurring | Per the Dify pricing page, Cloud Professional is listed at 590 US dollars per year and Team at 1,590 US dollars per year. Use these only to compare against self-hosting, and confirm current prices on the pricing page before you rely on them. |
| Staff time for monitoring | Recurring | Someone must watch service health, backups, disk growth and sandbox or proxy behavior. Ask who owns on-call for Dify, which alerts exist, and how many hours per month your team has allocated. |
| Staff time for minor upgrades | Recurring | Releases arrive roughly monthly. Each upgrade needs the target version's upgrade guide, a backup taken first, a review of new .env.example variables and a plugin daemon check. Estimate effort per release in your own test environment. |
| Initial backup and restore setup | One-time | Setting up backups for PostgreSQL, the vector store and file storage, and testing a restore, is a one-time cost. Ongoing backup storage and retention are recurring. Ask the partner to show a tested restore, not only a backup job. |
| Partner retainer for support and upgrades | Recurring | Retainers cover upgrades, monitoring, troubleshooting and continuous testing. Ask for the written scope, response expectations, which Dify versions are covered, and what happens when a release changes plugin daemon or security behavior. |
| Re-scoping after a major change | One-time | Moving to Kubernetes, changing the vector store or adding SSO are separate projects. Ask for a fixed-scope quote for each change, since these costs do not repeat with routine upgrades. |
What the client needs to provide before support starts
Support cannot start until the client gives the team the access, recovery points and named owners it needs to change a live Dify system safely. The first items are admin access to the host and the deployment target. For a Docker Compose install, that means a shell on the host with rights to run docker compose and read the directory holding the .env file. For a Kubernetes install, it means a cluster account scoped to the Dify namespace with rights to manage the Helm release. Confirm whether access runs through a bastion, whether sessions are recorded, and who holds break-glass credentials if the usual administrator is unavailable.
The client should also supply credentials for each stateful dependency: the metadata database (PostgreSQL by default, or MySQL if that was chosen), Redis, the vector store behind knowledge bases, and the object storage bucket that holds uploaded files. The accounts need enough rights to take database dumps and to read and write objects, but not broader administrative rights. Ask the client to confirm where these secrets are stored and how they rotate, because an upgrade that changes .env variables often requires the team to edit those values in the same change.
A current backup is the precondition for every upgrade, and the client should own it. The Dify Docker Compose guidance recommends a backup before every upgrade, so require one taken on the day of the change, not a backup job that ran last week. A restore test on the staging copy matters more than the job log. Confirm that the backup covers the metadata database, the object storage contents and the .env file. Keep SECRET_KEY in that backup, because changing it after deployment logs out all users and affects encrypted credentials. Name who can authorize a restore.
Staging, change approval and release timing need named people before the first upgrade is scheduled. Provide a staging environment that matches production closely enough to rehearse the upgrade, including the plugin daemon and sandbox services. Name the change approval owners for application, security and data, and document the internal change window with its days, hours and freeze periods. Compare that window with the cadence of Dify minor releases, which have arrived roughly monthly. Name one decision maker who can accept a deferred patch or a skipped version.
Finally, the client should provide a list of apps and knowledge bases with a named owner for each, because an upgrade is only verified when someone who knows the workflow confirms it still works. Supply the model provider accounts and keys the apps depend on, with the quotas and billing owner noted. Before any customization starts, confirm the license conditions. The Dify Open Source License forbids operating a multi-tenant environment, meaning more than one workspace serving separate tenants, without written authorization, and it forbids removing or modifying the logo or copyright information in the console. Confirm the intended use with legal counsel and obtain any authorization in writing first.
Questions buyers ask about Dify upgrades and support
Can our own team upgrade a self-hosted Dify without outside help?
Yes, if someone on the team has the time and skills to repeat the work. Each Dify release has an upgrade guide on the GitHub Releases page, and the Docker Compose docs say to follow the guide for the target version, back up before every upgrade and check .env.example for new variables afterward. The effort repeats because minor releases arrive roughly monthly. Dify 1.16.0 shipped on July 17, 2026, and 1.17.0 on August 25, 2026. Each cycle needs someone who can read the release notes, update configuration, run a staging upgrade, test apps and knowledge bases, and roll back if something fails. Ask whether that work fits your existing on-call and change-management routine.
What does a Dify upgrade cost and what drives the price?
The cost is mostly labor, and DeployOpen quotes it from a written scope. DeployOpen does not publish prices. Cost components include reviewing the release notes, taking backups, preparing a staging copy, updating environment variables, checking plugins and custom code, testing apps, and documenting the result. The main drivers are the number of production apps and workflows, custom plugins or code nodes, the external database, vector store and object storage in use, the number of model providers connected, how far behind the current version you are, and whether a staging environment already exists. Upgrades are one-time work per release, while a retainer covers recurring work. Ask for a fixed-scope quote that lists deliverables, test coverage, exclusions and what you must provide.
How long does a Dify upgrade take from start to finish?
The duration depends on the drivers listed in the scope, so confirm it during scoping. No standard timeline is published here, and a figure would depend on your environment. The main factors are the version gap, the number of apps and knowledge bases to test, the number of custom plugins and integrations, the state of backups and staging, the approval steps your organization requires, and the maintenance windows you can use. Ask the provider to state the timeline in the written scope, including the testing window, the rollback plan and the points where your team must approve work. If the upgrade touches production during a change freeze, confirm that schedule before work starts.
What do we need to provide for a Dify upgrade?
You need administrative access, named owners, backups and a staging environment. Access includes the host or cluster, Docker or Kubernetes management, the PostgreSQL or MySQL database, file storage, the vector store and the configuration files, including .env. Name a business owner for each app who can confirm test results and approve go-live. Backups should cover the metadata database, file storage, vector data and configuration. Record the current SECRET_KEY value and keep it unchanged, because changing it after deployment logs out all users. A staging copy with the same configuration lets you test the upgrade before production. Also agree on a change window and a rollback decision point.
Does the Dify Community edition include vendor support?
The Community edition is free and limited to one workspace, and the pricing page lists professional support only with Enterprise. The pricing page describes Enterprise as adding SSO, multiple workspaces, advanced security, a commercial license and professional support. Confirm directly with Dify what, if anything, is available for Community users, and read the current terms for the support channels they offer. Support from DeployOpen is a separate arrangement: it is a retainer or occasional help under a written scope, and it is not a substitute for vendor support. Ask any provider to state in writing what response and coverage they commit to, and to which versions and components that applies.
Should we buy a support retainer or request occasional help?
Choose a retainer if you expect regular upgrades and want the work planned, and choose occasional help for a single project or incident. A retainer suits teams that must follow the monthly release pace, keep production current and respond to problems without a new scope each time. Occasional help suits a one-off upgrade, a version gap that needs catching up, or a fault that your team cannot resolve. Compare the number of production apps, the amount of custom code, the availability of internal staff, your change-control rules and how much downtime you can accept. Ask each option to be written down with the included tasks, the exclusions and the way requests are handled.
What usually breaks during a Dify version upgrade?
Missing environment variables, plugin daemon changes and altered security settings are common causes of failure. Check .env.example after each upgrade, because new variables can be required and an omitted one can stop a service. Plugin daemon changes can break installed plugins or custom tools. Security changes also matter: the 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, so custom code nodes or outbound calls may behave differently. Verify each upgrade with smoke tests of model calls, knowledge base retrieval, workflow runs, file uploads, SSO sign-in if enabled, and logs for errors in the api, worker and plugin daemon services.
How DeployOpen scopes, delivers and supports Dify upgrades
DeployOpen plans and carries out Dify upgrades inside your own infrastructure, from the Docker Compose or Kubernetes environment you already run. Each engagement is fixed-scope, with the work agreed in writing before any upgrade begins, and ongoing support can be added as a retainer.
How we scope
- Inventory your current Dify version, deployment method, database, vector store and object storage before naming a target release.
- Map the release notes and the upgrade guide for each version between your current and target release, and list the steps that apply to your setup.
- Agree in writing which apps, workflows, knowledge bases, plugins and custom integrations are in the upgrade and which are excluded.
How we build
- Take and verify backups of the metadata database, file storage and environment configuration before any change is made to the running system.
- Compare your .env file with the current .env.example, record new variables, and set values that match your security and network requirements.
- Test the upgrade in a staging copy, including plugin daemon behavior, agent sandbox settings and a regression pass over your key apps before production.
How we hand over
- Provide a written runbook with the exact upgrade steps, rollback procedure, backup locations and verification checks used for your environment.
- Document every configuration change, including new environment variables, their chosen values and the reason each value was set.
- Walk your platform and operations team through the runbook and record open items, so your team can repeat the upgrade on later releases.
How we support
- Review new minor releases on a schedule agreed with you, and recommend which ones to adopt based on the changes that affect your deployment.
- Run the same backup, staging and verification steps for each later upgrade, and update the runbook after every change.
- Confirm with your team what support covers, including response expectations and out-of-scope work, before a retainer begins.
