No Code RAG with Dify v1.15.0: Deploy Guide (2026)

Two ways to get a no code RAG stack running with Dify: sign up for the hosted cloud at cloud.dify.ai, or self-host with Docker Compose. If you’re just prototyping and don’t care about data leaving your network, cloud wins – zero setup. But if you’re reading a deployment tutorial, you probably want the self-hosted route, and that’s where the real work starts. The catch nobody mentions up front: the plugin_daemon container is the single biggest reason installs fail in 2026, and none of the top tutorials explain how to fix it.

This guide walks the self-host install for Dify v1.15.0 (released June 25, 2026), plus the specific errors you’ll hit and how to unblock them. If you just want managed no code RAG in ten minutes, close this tab and go to cloud.dify.ai.

What Dify actually gives you

Dify is a self-hostable platform that turns RAG into a drag-and-drop task. Upload PDFs to a Knowledge Base, wire a Knowledge Retrieval node into a Chatflow, done – no orchestration code, no vector DB tuning by hand. 2026 additions include MCP (Model Context Protocol) integration for connecting agents to any external tool, improved multi-agent orchestration, improved RAG with hybrid search, built-in evaluation frameworks, and expanded provider support (Gemini 2.0, Claude 3.5+, GPT-4o).

Under the hood it’s not one binary – it’s seven-ish containers: API, worker, web, PostgreSQL, Redis, Weaviate, plugin_daemon, sandbox, ssrf_proxy, nginx. That matters for resourcing, and it’s why upgrades break so often.

System requirements (what the docs say vs. what actually works)

The official docs (as of mid-2026) list a bare minimum of CPU >= 2 Core and RAM >= 4 GiB. That’s technically true – the stack will boot. It will not be pleasant.

On macOS specifically, set the Docker virtual machine to use a minimum of 2 vCPUs and 8 GB of initial memory – otherwise the installation may fail. This trips up first-timers who leave Docker Desktop at defaults. Windows users need WSL 2 backend enabled; store the repo inside the Linux filesystem, not on the Windows side, or file watching breaks.

Seven containers sounds like a lot for what is essentially a document Q&A tool. It is. But each one has a job that would otherwise be your job – Weaviate handles vector indexing, sandbox isolates code execution, ssrf_proxy blocks server-side request forgery. The tradeoff: more moving parts means more things that can quietly restart without you noticing.

Install Dify v1.15.0 step by step

Three commands. The real work comes after.

# 1. Clone the latest release (not main - main is unstable)
git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git

# 2. Prepare env file
cd dify/docker
cp .env.example .env

# 3. Start the stack
docker compose up -d

The clone command needs git, curl, and jq installed. Missing jq produces a cryptic command-not-found – install it (apt install jq or brew install jq) and re-run. First pull expects several GB of images, so give it a few minutes on a home connection.

Verify with docker compose ps. Every service should read Up or healthy. One exception: according to the official docs, an Exited status for init_permissions is expected – that container just chmods volumes and dies on purpose. Any other container stuck in a restart loop? Jump to the errors section now, before continuing.

First-time config: from admin login to your first RAG app

Open http://localhost/install and create the admin account. You’ll land in Studio.

Model providers. Since Dify 1.x, they’re plugin-based – go to Settings → Model Providers, click Install on OpenAI (or Anthropic, or whichever), paste an API key. If the install spinner runs forever without completing, your plugin_daemon is the problem. Check its logs before touching anything else: docker compose logs plugin_daemon --tail 50.

For the actual no code RAG app:

1. Knowledge → Create Knowledge → upload a document (PDF, Markdown, or TXT)
2. Leave chunk settings at defaults to start – 500 tokens with 50 overlap is a commonly recommended starting point for mixed docs
3. Wait for status to flip to Completed (usually under a minute for small files)
4. Studio → Create App → Chatflow
5. Drag a Knowledge Retrieval node between Start and LLM. Point it at your Knowledge Base.
6. Publish. You now have a REST API endpoint and a shareable chat URL.

Timing matters: Turn on hybrid search (dense + sparse/BM25) in the Knowledge Base retrieval settings before uploading. It’s off by default, and flipping it later means re-indexing everything. A community-recommended starting point is roughly 0.7 vector / 0.3 keyword for mixed technical docs – adjust based on your results.

The plugin_daemon errors that eat your weekend

Almost every install horror story on the Dify GitHub traces back to one container. Three failure modes worth knowing.

1. Plugin marketplace won’t download anything. You click Install on OpenAI, it churns, then: Reached maximum retries (3) for URL https://marketplace.dify.ai/… From inside your plugin_daemon container, run curl https://marketplace.dify.ai to check connectivity. If it fails, it’s DNS. Fix: add dns: 8.8.8.8 under the plugin_daemon service in docker-compose.yaml, then restart all containers. (Source: GitHub discussion #26398)

2. Host proxy poisoning. Turns out Docker host proxy variables get inherited by service containers – which breaks marketplace access on any machine running Clash, a corporate VPN, or a system-level HTTP proxy. Verify: docker compose exec api env | grep -i proxy. If you see values there, blank them out explicitly in the api service block of docker-compose.yaml:

api:
 image: langgenius/dify-api:1.15.0
 environment:
 <<: *shared-api-worker-env
 HTTP_PROXY: ""
 HTTPS_PROXY: ""
 http_proxy: ""
 https_proxy: ""

3. plugin_daemon restart loop after upgrade. Upgrading from 1.4.x or earlier? The daemon may PANIC on boot. The GitHub community tracked this down (discussion #21396): the PLUGIN_S3_USE_AWS variable is absent from older .env files, and the default in docker-compose.yaml is empty instead of false. One-line fix: add PLUGIN_S3_USE_AWS=false to your .env file.

50MB cap. The plugin daemon rejects packages over a configurable limit – default 50MB, per the official plugin FAQ. No friendly UI error. It just refuses. If you’re building a plugin that ships large model weights or static assets, host them externally and download on first use. Separately: plugins run inside a managed Python 3.12 environment. Pin your dependencies to versions compatible with 3.12. A different runtime version in manifest.yaml is ignored entirely.

Other real-world install snags

Knowledge base indexing stuck at 0%? Check docker compose logs worker. Common causes (per community reports): insufficient memory for the embedding model, a network issue reaching the embedding API, or a corrupted document file. Try re-uploading in a different format – Markdown is almost always more reliable than scanned PDFs.

Vector store swap. Dify supports Weaviate (default, pre-wired, no credentials needed), plus pgvector, Milvus, Qdrant, and Chroma via the VECTOR_STORE env variable in .env (as of mid-2026). One rule: decide before you index anything. Switching vector stores later means re-embedding every document, which burns API credits.

Upgrading and uninstalling

cd dify/docker
docker compose down
git pull origin main
docker compose pull
docker compose up -d

Two things before running those commands. Back up the volumes/ directory – that’s where Postgres, Redis, and plugin data live. Then diff your .env against the new .env.example: new required variables appear in almost every release, and missing them causes the restart loops above. The 1.15.0 release patched two CVEs (path traversal in plugin-daemon forwarding, plus a LiteLLM upgrade for CVE-2026-42208), so this one is worth doing promptly.

To uninstall completely: docker compose down -v from the docker directory (the -v flag removes the volumes), then delete the cloned repo. Skip -v and your knowledge bases and API keys survive – useful if you’re just reinstalling a broken container.

Air-gapped deployments. Simply copying plugin files or container images is not enough. Plugin registration metadata lives in the dify_plugin database – not in the container image. For a full offline migration, export both the dify_plugin database tables and the /docker/volumes/plugin_daemon directory. If you’re moving to an environment without internet access, also set FORCE_VERIFYING_SIGNATURE=false in .env to disable signature checks that require outbound calls. (Source: GitHub discussion #26207)

Here’s an honest question worth sitting with before you commit to self-hosting: how much of your engineering time is worth spending on container ops vs. actually building the RAG app? For most teams under ten people, the cloud tier handles the load. Self-hosting makes sense when data residency is a requirement, when you’re building custom plugins, or when you’re running enough volume that cloud credits become a real cost.

FAQ

Is Dify actually free if I self-host?

Yes. Self-hosted has no feature paywall.

Do I need to know Python or JavaScript to build a RAG app?

For the standard chatbot-over-your-docs use case, no – the Chatflow builder plus a Knowledge Retrieval node handles it. You’ll want basic Docker familiarity for the install (understanding docker compose ps, reading container logs), but that’s ops knowledge, not coding. Where you might reach for code: writing custom plugins, or using the Code node in workflows for data transformations Dify doesn’t ship natively.

Should I use Weaviate or swap in Milvus/Qdrant?

Stick with the default Weaviate unless you already run another vector store in production. It ships pre-wired, has no separate credentials to manage, and handles the scale most teams need. The moment to swap: when you have an existing pgvector or Qdrant cluster with backups and monitoring – then pointing Dify at it via VECTOR_STORE saves you from operating a second database.

Next step: once your stack is up, upload one real document from your own work, wire a Chatflow, and ask it a question you already know the answer to. If the citation points to the right chunk, you’re production-ready. If it doesn’t, try smaller chunks (e.g. 300 tokens) before touching anything else.