Can Dify 1.18.0 KnowledgeFS Be Self-Hosted? Decide Whether to Enable It First

Your existing Dify knowledge workflow works, but the new KnowledgeFS option has unclear support or image requirements.

Fast answer: keep a stable Classic Knowledge workflow as it is. Treat KnowledgeFS as an optional Beta, not a required upgrade. If you run Community Edition locally, confirm the supported enablement path, image availability, and recovery plan before testing it; don’t make it the default for production data yet. The Dify 1.18.0 release notes mark Agent Knowledge Base as Beta and describe it as a separate service and database.

This guide is for developers running Dify Community Edition who are assessing an upgrade.
It also helps knowledge-base owners and small engineering teams separate platform, knowledge-service, and model-inference needs.

Last updated October 26, 2026. Details were checked against the official release notes, the official Compose configuration, and the KnowledgeFS environment example.

Dify 1.18.0 KnowledgeFS self-hosting: keep the decision conditional

The release notes mark Agent Knowledge Base as Beta. The deployment configuration describes KnowledgeFS as a distinct service with a separate database, rather than a replacement that every existing knowledge workflow must adopt. The official Compose configuration leaves KnowledgeFS disabled by default. The deployment guidance also requires a Community Edition local deployment to explicitly enable the development option. Check the release notes, Compose file, and KnowledgeFS environment example before changing a running deployment.

That combination calls for a cautious decision. A Beta feature can be worth evaluating when it solves a concrete workflow problem. But an optional service with a separate database introduces more operational work: another component to deploy, observe, back up, and restore. A Beta label alone does not establish that every edition, deployment method, or production support path is ready for a given team.

Classic Knowledge remains a distinct path according to the release information. Therefore, a working Classic Knowledge deployment does not become obsolete merely because Agent Knowledge Base appears in a new release. The meaningful question is whether the team has a requirement that the new feature actually addresses.

Existing workflows and Agent Knowledge Base

How does Dify Agent Knowledge Base differ from the original knowledge workflow?

The new Agent Knowledge Base capability is aimed at knowledge spaces used by agents, retrieval nodes, and associated workflows. Classic Knowledge is the existing route for teams that already ingest material and retrieve it through established RAG workflows. These are related capabilities, but the release does not present KnowledgeFS as a mandatory migration target.

That distinction matters when planning a change. A team can have a valid reason to test knowledge-space management, retrieval tracing, or permission separation without deciding to move every existing dataset. First identify the exact capability needed, then compare it with the current workflow. Do not treat a new feature name as evidence that an existing knowledge base must be replaced.

A useful evaluation should name the specific feature being tested. “We want to use the new knowledge base” is too broad to justify another production dependency. “We need agents to use separately managed knowledge spaces, and we need to verify retrieval traces and access boundaries” is testable.

Does KnowledgeFS need its own service and database?

Yes. The official release and environment example describe KnowledgeFS as a distinct service with a separate database dependency. This changes the operational boundary even if Dify’s main application remains on the same host. The team must account for the new service in deployment configuration, health checks, data retention, backup, and recovery procedures. Review the KnowledgeFS environment example for its configuration inputs rather than guessing them.

Before enabling it, map which component owns each dataset and which credentials can access it. Then test restoring the KnowledgeFS data together with the Dify configuration that refers to it. A successful container start is not proof that an end-to-end recovery works.

Community Edition deployment checks

Can Dify Community Edition self-host KnowledgeFS?

The official guidance says local Community Edition deployment must explicitly enable the development option; the default Compose configuration leaves KnowledgeFS off. This confirms an enablement condition, not a blanket production-support promise. The safest reading is that self-hosted evaluation may be possible under the documented conditions, while support boundaries and image availability still need to be checked against current official materials.

A community user raised questions about KnowledgeFS image availability and support paths in an October 24, 2026 GitHub issue. That issue records a user’s question. It is not an official statement that images are unavailable, nor does it prove that Community Edition is unsupported. Do not turn an unanswered issue or a local image-pull failure into a product-support conclusion.

When checking images, verify the image name and version reference in the official deployment files, confirm that the registry can be reached from the target host, and check that the selected architecture is compatible. Do not rely on an image tag copied from an old issue or an unofficial Compose example. The official Docker deployment guide is the safer starting point for reviewing the documented self-hosting path.

The distinction between editions is important. Community Edition setup steps should not be treated as a contract for Enterprise features or Cloud rollout. For any managed or enterprise deployment, confirm availability, support scope, data boundaries, and recovery expectations with current official material before connecting business documents.

Separating platform, knowledge, and inference workloads

A Dify deployment is easier to size when its work is divided by responsibility. The Dify platform handles the application and workflow layer. Knowledge services manage the related retrieval data path. Model inference may run locally or use an external API. These are separate planning questions; the model’s compute demand should not be counted as a requirement of the Dify platform when inference is external.

For a locally hosted model, estimate memory from the model’s weight representation and the additional working memory required by the selected context and runtime. Then test the actual model and workload on the intended CPU and memory configuration. Do not infer tokens per second, concurrency, or suitability from a model’s parameter count alone. CPU inference may be acceptable for some small-model, embedding, reranking, or batch workloads, but training and high-concurrency large-model inference should not be treated as the target of this server plan.

When using an external model API, separately decide which prompts, source excerpts, or document-derived content may be sent outside the organization. The privacy question concerns the full request and response path, not just where the Dify web application runs. Document the approved data classes, the information sent to the model provider, and the internal review path before connecting a production knowledge source.

A controlled enablement checklist

Use this checklist before enabling KnowledgeFS in a test or production environment:

• [ ] Write down the specific Agent Knowledge Base feature the team needs and why the existing Classic Knowledge workflow does not meet that need.
• [ ] Check the current official release notes and deployment guide for the relevant edition and deployment method.
• [ ] Inspect the official Compose configuration and KnowledgeFS environment example; record the required services, database, settings, and image references.
• [ ] Verify that the images can be retrieved from the target host and that their architecture matches the server.
• [ ] Deploy in an isolated environment with non-production documents and test retrieval, permissions, and expected workflow behavior.
• [ ] Document which data belongs to KnowledgeFS and how it is backed up; restore that data into a test environment to validate recovery.
• [ ] Record a rollback path that returns the team to its existing Classic Knowledge workflow without losing access to current data.
• [ ] Before production use, confirm the feature’s support status for the exact edition and hosting model.

For existing production knowledge bases, leave the current path untouched while these checks are pending. For a new Agent workflow, a separated evaluation avoids making uncertain image or support assumptions part of the business-critical deployment. General hosting questions can be reviewed through NodeKVM’s help resources, but that information should not be read as confirmation that NodeKVM has preinstalled or validated KnowledgeFS.

When dedicated hardware fits the deployment

A small test or lightly used internal tool may not justify a dedicated physical server. A temporary evaluation can be simpler on an existing development environment. A production workload with steady platform services, a separately managed knowledge database, and predictable resource use may benefit from more direct control over the host.

Shared virtual machines can involve competing workloads, CPU oversubscription, plan-specific limits on storage changes, or bandwidth and usage charges that are harder to forecast. Those trade-offs vary by provider and plan, so compare the actual terms rather than assuming every cloud instance has the same limitations. A dedicated AMD physical server is more relevant when the team needs exclusive host resources and expects the services to run continuously; it is not a substitute for checking the workload’s memory, storage, backup, and network requirements.

If the team confirms that KnowledgeFS is supported for its deployment and that a stable, long-running host is justified, compare the current NodeKVM dedicated-server options against the actual service layout. Check the live NodeKVM pricing and configuration information for available resources and terms. This comparison can inform a hosting decision; it does not guarantee KnowledgeFS compatibility. For a short evaluation, a light workload, or a setup that needs rapid hourly scaling, a dedicated server may be the wrong fit.