Why Dify security hardening is more than changing a default password
Hardening a self-hosted Dify means deciding how the platform controls five things: the secrets it holds, how far its code and agent steps can reach over the network, who can access it, how traffic is encrypted in transit, and how the system is recovered after a failure. A stack that starts and answers requests has passed none of these checks by default. The question for a team is whether it can hold model provider keys, customer documents and agent tools in the same environment and still meet its own security requirements. Changing a default password covers only one part of the login path and none of the others.
The difficulty comes from how many moving parts are involved. The Docker Compose deployment starts the api, worker, web, plugin daemon and other core services, along with PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Each has its own configuration surface and its own exposure. Workflow code nodes and agent steps can make outbound calls, so a prompt or tool definition can become a network request. Some of the most consequential settings are global. SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Proxy routes and encryption key storage also apply to every user of the instance, not just one app.
The Community edition runs anywhere Docker runs, and in a Docker Compose deployment your team owns every control. That includes generating and storing the secret key, deciding whether workspace encryption keys are stored locally or in Azure Key Vault, configuring the SSRF proxy, placing Nginx and TLS in front of the stack, and setting backup routines. The Community edition is free and limited to a single workspace, so a team that needs several isolated workspaces will be evaluating Enterprise. Dify Enterprise adds SSO, multiple workspaces and advanced security, and it can run on Kubernetes. Those additions change how identity and tenancy are handled, but they do not remove the need to configure secrets, outbound access and recovery. Ask the vendor which of these controls, if any, are preconfigured in the edition you evaluate.
Start with a short inventory before changing any settings. List every secret the stack holds: the SECRET_KEY, database and Redis credentials, workspace encryption keys, and model provider keys entered in the console. For each, record where it is stored, who can read it and how it is rotated. Then map outbound paths: which code nodes, tools and agent steps need internet access, which need internal systems, and whether the SSRF proxy blocks the private ranges your internal services use. The Dify 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, token-based authentication between services and sandboxed Jinja2 template rendering. Confirm on the version you deploy that these behaviors exist and are enabled in your configuration.
Plan to repeat these checks after every upgrade. Dify minor releases have arrived roughly monthly, with 1.16.0 on July 17, 2026 and 1.17.0 on August 25, 2026, and each release can add environment variables or change service behavior. The Docker Compose upgrade guidance recommends a backup before every upgrade and a review of .env.example for new variables. Treat the hardening baseline as a document versioned alongside the deployment. When you evaluate an implementation partner, ask how that baseline is verified against the release you run and who signs off on changes to secrets, egress rules and recovery procedures.
Which Dify components hold secrets or reach outward
A self-hosted Dify stack places several services in the trust path, and each one either holds credentials or data, or reaches a network beyond your edge. Start with the components that run code, send outbound requests and accept client traffic, then trace where the stored data lives. Confirm each behavior in the exact version you deploy, because the product changes often.
API, worker and plugin daemon
The api and worker services hold SECRET_KEY, which signs session cookies and JWTs and encrypts OAuth credentials, along with database credentials and the model provider keys entered in the console. They call out to model providers and tools, and the plugin daemon loads extensions that run alongside them. Check who can read the .env file, where provider credentials are stored, and whether the token-based authentication between services described in the 1.16.1 release notes is present in your build.
Code sandbox for code nodes
The code sandbox executes code from workflow code nodes, so it is where logic written by app builders runs on your hosts. Ask whether a sandboxed step can reach internal addresses or the instance metadata service of your cloud account. The 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy and sandboxed Jinja2 template rendering. Verify both in your version with a test workflow that attempts an outbound call to an internal address.
SSRF proxy as outbound path
The SSRF proxy is the route for outbound HTTP requests made by Dify features, so it defines what your deployment can reach on the internet. Per the environment variable reference, SSRF_PROXY settings send requests through a proxy that blocks internal and private IP ranges. Confirm which features in your version use the proxy, test that private addresses are refused, and document the external endpoints your model providers and tools require so that you can allowlist them deliberately.
Nginx as client-facing edge
Nginx terminates client traffic to the web console and the API, so it is where TLS, certificate handling and request size limits are configured. Confirm which host ports are published, that users reach Dify only through Nginx, and that plain HTTP redirects to HTTPS. Agree the certificate source and renewal process with your security team, and confirm how the web service is reached behind the proxy in your version.
PostgreSQL, Redis and metadata store
The metadata database holds accounts, apps, workflows and conversation records. PostgreSQL is the default, but the environment reference also lists MySQL and OceanBase, so confirm which engine your deployment uses. Redis supports caching and background task coordination, and its stored contents should be confirmed for your version. Restrict network access to both services, rotate their passwords, and include both in the backup scope.
Weaviate and file storage
Weaviate is the default vector store and holds the indexed content of knowledge bases, while uploaded source documents go to the configured file storage. That storage can be OpenDAL, S3-compatible storage, Azure Blob or Google Cloud Storage, so confirm which bucket or volume holds which data. Check who holds the access keys for each store, and make sure backups capture the vector index and the original files together, since restoring one without the other leaves knowledge bases inconsistent.
Which key storage, isolation and proxy options to choose
This table compares the key storage, sandbox and proxy, agent isolation and TLS options for a self-hosted Dify, along with the operational work each one creates. Read each row against the Dify version you deploy, because proxy and isolation behavior can change between releases. The main takeaway is that every addition to outbound reach or key custody creates a review, a recovery step or a maintenance window that a named owner must manage.
| Option | When it fits | Operational cost |
|---|---|---|
| SECRET_KEY set once and managed as a secret | Most self-hosted installs, with the key generated before first start and stored in your secrets manager | Set before go-live. It signs session cookies and JWTs and encrypts OAuth credentials, so back it up with the rest of your configuration. |
| SECRET_KEY rotated after go-live | Only when exposure is suspected or your policy requires periodic rotation | Changing it logs out all users, so schedule a maintenance window. Confirm in your version's FAQ how existing encrypted OAuth credentials are handled. |
| Workspace encryption keys stored locally | Small deployments with no Azure Key Vault in your estate | Key material sits on the Dify host, so host access control, disk protection and backup of the key material carry the risk. Recovery depends on your own backup process. |
| Workspace encryption keys in Azure Key Vault | Azure-hosted deployments where a security team must hold key custody | A named owner must manage the vault, access policies and key lifecycle. Dify depends on Azure connectivity, so plan outage behavior and recovery. Confirm the supported configuration for your version. |
| Default code sandbox and SSRF proxy only | Workflows that call public APIs and built-in tools only | Lowest review load. The SSRF proxy blocks internal and private IP ranges, so workflows that reach internal services will fail until you add an exception. |
| Allow-listed egress for specific internal APIs | Workflows that must call named internal services | Each entry widens reach. Record an owner and justification for every entry, review the list on a schedule, and confirm the exact SSRF_PROXY settings in the environment reference for your version. |
| Agent network isolation through the bundled Squid proxy | Dify 1.16.1 or later, where agents run code or call tools in the sandbox | No extra infrastructure, but you must verify that isolation is active and test agent workflows after each upgrade. Review proxy rules whenever the allow-list changes. |
| Network policy at host or cluster level | Organizations with existing firewall or Kubernetes network policy standards | Enforced outside Dify, so it also covers paths the application configuration may miss. Requires network team effort and rules that match the sandbox's actual traffic, so test them with agent workflows. |
| TLS terminated at bundled Nginx | Single-host Compose deployments where certificates are managed on the host | Certificate renewal and TLS settings live on the Dify host. Confirm the Nginx configuration and certificate paths in .env.example for your version. |
| TLS terminated at a load balancer, with Nginx for the internal hop | Enterprises with central certificate management or a web application firewall | Offloads public certificates to the load balancer but adds a second certificate to manage on the internal hop. Confirm forwarded-header handling and certificate paths for your version. |
Where the code sandbox and SSRF proxy stop outbound reach
The code execution sandbox and the SSRF proxy set the outer limit on what a workflow code node, an agent or an HTTP request step can reach. In the Docker Compose deployment, outbound requests from the api and worker services can be routed through a proxy configured by the SSRF_PROXY settings. That proxy blocks internal and private IP ranges, so a workflow that tries to call a database on your internal network, or a cloud metadata address, should fail by default. Treat that default as the starting point for your review. Before go-live, confirm in the .env.example for your target version which SSRF_PROXY variables exist, how the proxy is wired to each service, and whether any path bypasses it.
Most teams add internal tools sooner or later, such as a ticketing API, a document service or an internal search endpoint. Those hosts sit inside the private ranges the proxy blocks, so the team must decide which of them a workflow may reach and how to allow each one without weakening the block. The choice comes down to two options. Blocking everything is the safer default, but it pushes integration work into custom tools that will need their own access controls. Allow-listing named hosts gives workflows the reach they need, yet each entry opens a path into your network. For every host you allow, record the port, the purpose, the apps or node types that call it and the reason it cannot sit behind an existing API gateway.
Every allow-list entry needs a named owner who can explain why it exists and whether it is still needed. Record the owner in the change record, not in someone's memory, and review the list on a fixed schedule and after each Dify upgrade, since a new release may change how the proxy or sandbox handles requests. Ask the reviewer to check three things: whether the host still exists, whether its scope has widened, and whether any workflow now calls it in ways the original design did not contemplate. Remove entries whose owner does not respond. A stale entry to a shared service is often the path that turns a contained code node into a route to sensitive systems.
The sandboxed Jinja2 template rendering and the agent network isolation are version-dependent behaviors. The Dify 1.16.1 release notes describe agent sandbox network isolation through a Squid proxy, sandboxed Jinja2 template rendering and token-based API authentication between services. Do not assume these behaviors exist, or work the same way, in the version you deploy. Confirm them against the release notes and upgrade guide for your exact version, then test them directly. Attempt a template that reads local files, run an agent step that calls an internal address, and run a code node that opens outbound connections to one allow-listed host and one host that is not on the list.
The sandbox is not a complete isolation boundary. It limits common paths, but it does not replace a threat model for your deployment. Decide which data and credentials a compromised workflow could reach, then test those paths from inside the stack using the same identities your apps use, and record the results. Where a workflow could reach a sensitive system, fix the problem at the network layer with firewall rules, segmented subnets and egress filtering, and avoid relying on the proxy alone. Repeat these tests after every upgrade, because the boundary you verified on one version may have moved on the next.
Hardening sequence from secrets to backups
This sequence takes a self-hosted Dify from default settings to a deployment where secrets, key storage, outbound requests, model credentials, transport, access and backups are controlled and verifiable. Each step ends with a check the team can run and record. The final step confirms that the data stores and environment file can be restored into a working system.
Pin the Dify version and review release notes
The platform team pins one Dify release tag in the Docker Compose deployment and does not track the latest image. Before pinning, they read the release notes for the chosen version, including the 1.16.1 notes that describe agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering. They then compare the repository's .env.example with the variables already in use and decide how each new variable is set. Closing check: the running containers report the pinned version, and every variable added in the new .env.example is either set deliberately or left at its documented default.
Generate and store SECRET_KEY outside the repository
The team generates SECRET_KEY with a cryptographically secure random generator and stores it in the organization's secrets manager. It is injected into the api and worker environments at deploy time so the value never appears in the Git repository or in shared .env copies. Dify uses this value to sign session cookies and JWTs and to encrypt OAuth credentials, and changing it after deployment logs out all users, so it must be set before the first login and recorded in the restore procedure. Closing check: the api and worker containers show the variable as set, a first login succeeds, and a session survives a container restart.
Configure workspace encryption key storage
The team chooses where workspace encryption keys are kept, either local storage or Azure Key Vault. If Key Vault is used, the service identity receives only the permissions needed to read and write keys, and the security owner records who may rotate them. Confirm the exact configuration keys and permissions for the pinned version in Dify's environment variable reference. Closing check: save a test model credential in a workspace, read it back through the console, and confirm in PostgreSQL that the stored value is not plaintext.
Set SSRF proxy and sandbox, then test refusal
The team routes outbound requests through the SSRF proxy and confirms the sandbox settings in the environment file match the network plan for the deployment. Dify documents that the SSRF proxy blocks internal and private IP ranges, which limits how workflows, tools and HTTP nodes can reach internal services. Build a test workflow with an HTTP request node and point it at a private address and at a loopback address. Closing check: both requests are refused, the refusals appear in the logs, and the sandbox isolation behavior matches the release notes for the pinned version.
Keep model provider credentials out of prompts and DSL
Model provider keys are entered only through the platform's model provider settings, never inside prompts, system messages, code nodes or tool descriptions. Dify's documentation says YAML DSL exports exclude third-party API keys, so the team confirms this for its own version by exporting a test app and searching the file for key patterns. Closing check: the exported file contains no provider key string, and after import into a second workspace the app runs once credentials are entered there by an authorized person.
Place TLS in front of Nginx and verify headers
The team terminates TLS at Nginx or at a load balancer in front of it, using a certificate from the organization's internal or public certificate authority, and redirects HTTP to HTTPS. HTTP Strict Transport Security is set in the Nginx configuration, and the certificate chain is checked so that clients validate the server certificate through its intermediates. Closing check: an external TLS scan or an openssl s_client session shows a complete certificate chain, and the response headers on the console and API paths include Strict-Transport-Security.
Restrict admin console and API paths by network
The team limits access to the console and administrative API paths to the networks that need them, such as an admin subnet, a VPN range or the identity provider's egress addresses. Rules are applied through load balancer policies, security groups or Nginx allow lists, and the team documents which paths are public for end users and which are operator-only. Closing check: a request to an administrative path from an unlisted network is denied, and the same request from an allowed network succeeds. Both results are saved with the change record.
Back up data stores and .env, then test restore
The team schedules backups of PostgreSQL, the file storage backend, the vector store data (Weaviate by default) and the .env file, stored encrypted and separately from the deployment host. Dify's Compose documentation advises a backup before every upgrade, and the same job should run on a schedule between upgrades. The restore must include the same SECRET_KEY and key storage material, or stored credentials may not decrypt. Closing check: restore into a separate environment, then confirm a previously created app loads, a knowledge base query returns an answer, and a login succeeds. Record the restore steps and their outcome.
Model credentials, access and transport controls to lock down
The core hardening work in Dify is only as strong as the controls around it: who holds model provider keys, who can change the console, how traffic is encrypted, and what gets logged. Each card below names one control, the risk it addresses and the check that shows it works, so your team can verify the configuration on your own deployment.
One owner per provider key
Each model provider key configured in Dify should have a named owner who is responsible for rotation, scope and revocation. Dify stores these credentials inside the workspace, so a shared key used by several teams makes it hard to tell which app consumed which spend or who must act after a leak. Check that every provider credential maps to one accountable person and that the owner can revoke it at the provider without relying on a Dify administrator.
Provider-side spend limits and rotation
Set monthly spend limits and rotation dates at the model provider, not only in internal dashboards, so a stolen or misused key is capped even if Dify is compromised. Confirm with each provider which limit and alerting options its console and API offer, since these differ. Verify the schedule by revoking a test key in a non-production workspace and confirming that the Dify app fails closed and that the rotation runbook names who updates the key in Dify.
Exports exclude third-party API keys
Dify DSL exports carry app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but the Dify documentation states they do not include third-party API keys. Teams often assume an exported file is safe to share, then re-enter keys in the target workspace. Treat exports as design artifacts that still reveal prompts and workflow logic, control who can download them, and check that a test export contains no provider secrets before it leaves the environment.
Least-privilege console and workspace roles
Limit administrator accounts to a few named people and assign workspace roles by function, so builders can edit apps without managing model credentials or workspace membership. Remove or disable accounts that have not been reviewed, and keep a separate break-glass administrator with its own controlled credential. Verify by signing in as each role and attempting to open provider settings, member management and API key screens, recording any access that should have been denied.
Disable unused sign-in methods
Turn off sign-in methods that your organization does not use, such as open registration or social logins not approved for the workspace, so that every account traces back to an approved identity. Where your organization requires central identity, the identity integration is covered in the Dify SSO and identity integration topic, which also explains session duration and the Community versus Enterprise differences. Check the login settings after each upgrade, since defaults can change between releases.
TLS termination and internal traffic
Terminate TLS at Nginx or your load balancer with a certificate owned by a named team and tracked for renewal. Restrict protocol versions and cipher suites to what your security baseline allows, and confirm the settings with an external scan rather than assuming the defaults are acceptable. Internal traffic between the api, worker, plugin daemon, PostgreSQL, Redis and the sandbox services should also be reviewed, since the Compose stack runs these on a shared network that a plain HTTP listener could expose.
Logging scope, destination and review
Decide what Dify and its supporting services log, including sign-ins, role changes, provider credential edits, app publishes and API errors, and send those records to a central store with restricted write access. Name the person or team who reviews them and how often, and make sure logs do not capture prompts or secrets by default. Verify by performing a test role change and confirming the event appears in the central store within the window your review process assumes.
What drives hardening effort and how to keep each part down
This table lists the factors that most change the size of a Dify hardening engagement, what makes each one larger and how to keep it contained. Effort depends on the written scope, so the quote should list each driver with the number or choice it assumes. Readers who fix these inputs early usually get a smaller and more predictable review.
| Driver | What makes it larger | How to keep it down |
|---|---|---|
| Apps and workflows with code nodes or HTTP tools | Each code node or HTTP tool adds an outbound path that must be reviewed for egress, SSRF exposure and secrets handling | Limit code nodes to approved use cases, route outbound calls through the SSRF proxy, and inventory every tool in one list |
| Model providers and credentials | Each provider adds a credential to store, rotate and scope, plus a separate set of permissions to verify | Consolidate to the providers the business has approved and use one named credential per provider and environment |
| Internal systems that agents must reach | Every internal API or database an agent can call widens the network path and the access model that testers must check | Expose only the endpoints each app needs through a narrow API tool with its own service account and documented allowlist |
| Key storage in Azure Key Vault | Moving workspace encryption keys to Key Vault adds access policy design, identity configuration for the host and failover testing | Decide the storage location before hardening starts and scope one managed identity to the vault secrets Dify needs |
| Deployment model: Compose host or cluster | A single Compose host needs host-level firewall and service isolation, while a cluster adds network policy work across pods and services | Choose the deployment model in the scope document and keep the network policy rules in version control |
| Compliance evidence requirements | Each framework or internal policy asks for documented controls, configuration records and test results that must be collected and kept current | Agree the control list with the assessor early and map each control to a config file, log or test result. DeployOpen prepares evidence but does not issue audit reports |
| Environments: dev, test and production | Each environment needs the same SECRET_KEY handling, sandbox settings, TLS and backup controls, so work repeats per environment | Build one configuration template, parameterize values per environment, and test changes in test before production |
How to prove the controls fail safely and recover
A hardening control only counts once you have seen it fail the way you expected. For each control in this topic, write one pass test and one failure test before go-live, and keep the results with the change record. For the SSRF proxy, the most direct failure test is a workflow HTTP request to an internal or private address on your own network (illustrative). The request should be blocked, and the block should appear in the proxy logs. The matching pass test sends a request to an approved external endpoint through the same path and should succeed. For the code execution sandbox, run a snippet that opens a connection to a host outside the allowed path. It should fail inside the sandbox and never reach the target. Confirm with your network team which destinations form the allowed path, because the platform cannot determine that for you.
Test SECRET_KEY handling in a staging copy before go-live. According to the environment variable reference, the key signs session cookies and JWTs, encrypts OAuth credentials, and changing it after deployment logs out all users. Decide now how your team will handle a lost or rotated key, and confirm with the vendor how existing encrypted data is treated before you rotate it in production. For Azure Key Vault, simulate an outage by blocking the vault endpoint from the api host in staging. Then record what the platform does with stored workspace credentials: whether requests fail, whether any cached values are used, and what an operator sees. Do not assume the answer. Test TLS from a client outside the network, confirming that the certificate chain validates, that plain HTTP is redirected or refused, and that internal service ports are not reachable from public interfaces. Finish with login and role tests: each role should reach only its own functions, and a removed account should lose access immediately.
After hardening, backups decide whether a failed control becomes a lasting outage. Back up PostgreSQL, the file storage that holds uploaded documents, the vector store data (Weaviate by default, or the store you chose), the .env file, and the encryption key material, including workspace keys if they are stored locally or in Azure Key Vault. Losing the .env file or the key material can leave restored data unreadable, so keep those copies separate from the database backup, with restricted access. The Docker Compose guidance recommends a backup before every upgrade, and that rule should be written into your change process. Then prove the backup works. Restore the full set onto a separate host, start the stack, sign in with a test account, and open a knowledge base and a published app. Record how long the restore took and who ran it, so the recovery time comes from your own measurement.
Monitor three signals from the first day in production: failed logins, blocks from the SSRF proxy, and errors from the code execution sandbox. A spike in failed logins can indicate credential guessing, a steady stream of proxy blocks can show a workflow trying to reach internal services, and repeated sandbox errors can reveal a misconfigured or probing node. Assign an owner for each signal, set a review frequency, and define what triggers escalation. Confirm where these logs are written in your deployment, since the location depends on how the stack is run. Finally, re-run the full test set after every Dify version change. Minor releases arrive roughly monthly, and the 1.16.1 release notes describe changes to sandbox network isolation, service authentication and template rendering, any of which can alter a control you already tested. For the upgrade steps themselves, see the sibling topic on Dify upgrades and support.
What buyers and engineers ask before hardening a self-hosted Dify
Can the Community edition of self-hosted Dify be hardened to the same level as Enterprise?
Not through configuration alone. The Community edition is free and limited to a single workspace, while Enterprise adds SSO, multiple workspaces, advanced security and professional support, according to Dify's pricing page. Several controls exist in the Community Docker Compose stack, including SECRET_KEY handling, the code sandbox and the SSRF proxy settings. Release 1.16.1 added agent sandbox network isolation through a Squid proxy, which applies to the stack you deploy. Enterprise features such as SSO over OpenID Connect, SAML or OAuth2 are not part of Community, so those controls need a different design. Confirm each feature separately: whether the setting is exposed in your version, whether the fix is in the release you run, and whether your identity and logging requirements can be met without Enterprise. The license also restricts multi-tenant operation without written authorization, which limits some designs.
What drives the cost and effort of hardening Dify, and what should a quote include?
The main drivers are the number of environments, the model providers and integrations in scope, whether you run Docker Compose or Kubernetes, and whether key storage uses Azure Key Vault. DeployOpen works from a written scope, so the quote should follow from that document, and DeployOpen does not publish a price list. Ask the quote to separate the review of current configuration, changes to SECRET_KEY handling, sandbox and SSRF proxy settings, key storage, TLS and backup setup, any security testing, and handover documentation. Ask which items are one-time and which recur, such as infrastructure, model provider spend and any support retainer, which is priced separately. Also ask what is excluded, for example retesting after each upgrade, and who in your organization must approve changes.
Can our own team harden Dify, and what skills do they need?
Yes, a capable platform team can do it internally, but the work spans several skill areas. Container networking matters because the sandbox and SSRF proxy run inside the stack, and outbound requests to internal and private IP ranges must stay blocked. Secrets management covers SECRET_KEY, database credentials and workspace encryption keys. If you use Azure Key Vault, someone must own its access policies and key lifecycle. TLS termination at Nginx and certificate renewal are routine but easy to misconfigure. The team must also track monthly releases and check .env.example for new variables after each upgrade. Illustrative: a team strong in Docker but new to Key Vault should plan time to close that gap before go-live, or add a partner for that part of the work.
How long does Dify hardening take?
Duration depends on the written scope and environments, and no figure is given here. The main variables are the number of environments, such as development, staging and production, the deployment model, the number of model providers and integrations, and whether Azure Key Vault is in use. Approval cycles and access grants often take longer than the technical changes, so response times from your security, identity and change teams matter as much as engineering capacity. Ask for a schedule with milestones tied to named access, a review step for each environment, and a verification step before handover. Dates in a quote should be linked to the client responsibilities they depend on, so delays in access or approvals are visible early.
What does a hardening engagement need from our team?
It needs environment access, named owners and decisions in writing. Expect to provide roles in the cloud account, container host, DNS and certificate authority, along with access to the deployment repository and the environment files. Each secret and key needs an owner who approves rotation and grants access, including the Azure Key Vault administrators if that service is used. Egress rules need an approver who can confirm which outbound destinations model providers, plugins and agents require, so the SSRF proxy and sandbox rules can block everything else. Also agree who signs off changes, when maintenance windows fall, and who receives backups and test evidence. Name these owners in the first week, since they often set the pace of the work.
Why does changing SECRET_KEY after deployment log out every user?
SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, so changing it invalidates existing sessions for all users. Plan the change as a maintenance event with an announced window. Confirm how stored OAuth credentials will be handled, since they depend on the key, and check each environment separately, because staging and production should never share a value. Generate the new value with enough randomness, store it in a secrets store and keep it out of shared files, and make sure backups hold it in protected form. After the change, verify that users can sign in and that OAuth-connected providers still work. Record the change date and the verification results for your change log.
Does DeployOpen issue security certifications for a hardened Dify deployment?
No. DeployOpen does not issue audit reports, attestations or certifications. It plans, implements and documents controls, and it prepares evidence such as configuration records, access lists and backup restore results that an independent auditor or certification body can review. Whether the deployment meets a given standard is decided by the assessor, based on your scope and on operating evidence collected over time. Before engaging, confirm which control framework you are preparing for, which control IDs the work should map to, and which evidence the assessor expects. Involving your auditor early helps match the evidence format to what they will request.
How DeployOpen scopes, hardens and hands over a Dify deployment
DeployOpen treats Dify security hardening as a written, fixed-scope project inside your own infrastructure, covering the secrets, sandboxing, network paths, credentials, TLS and backups that a self-hosted Dify depends on. Each step produces documented settings and evidence your security and platform teams can review and run after handover.
How we scope
- Inventory the Dify version, deployment method (Docker Compose or Kubernetes) and every service in your stack, including the code sandbox and SSRF proxy
- Confirm the SECRET_KEY, workspace encryption key storage and model credential locations before any change is made
- Agree in writing which controls are in scope, such as agent network isolation, TLS termination and backup restore testing, and which are excluded
How we build
- Set and document SECRET_KEY handling, with the understanding that changing it after deployment logs out all users
- Configure the sandbox and SSRF proxy settings so outbound requests from workflows and agents cannot reach internal or private address ranges
- Review model provider credentials, token-based service authentication and network segmentation, then test each control against the agreed scope
How we hand over
- Deliver a written configuration record covering environment variables, secret locations, network rules and TLS settings for your reviewers
- Document backup and restore procedures, including a restore test, and the steps to check .env.example after each upgrade
- Walk your platform and security teams through the runbook so they can operate and verify the hardened state without us
How we support
- Support after go-live is available as a retainer, covering upgrades, re-testing after version changes and questions about configuration
- Retainers can include continuous security testing of Dify apps, APIs and agent behavior, scoped in writing
- Confirm with DeployOpen during scoping which support hours, response expectations and upgrade work the retainer includes
