---
title: "Deploy Dify"
description: "Dify workflows & RAG, chatbots, plugins, Qdrant and S3. Dify AI (DifyAI)."
category: "AI/ML"
url: https://railway.com/deploy/dify-ai-with-qdrant-and-s3
---

# Deploy Dify

Dify workflows & RAG, chatbots, plugins, Qdrant and S3. Dify AI (DifyAI).

**[Deploy Dify on Railway](https://railway.com/template/dify-ai-with-qdrant-and-s3)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/dify-ai-with-qdrant-and-s3/manifest.json

- **Creator:** Xav's Projects
- **Category:** AI/ML
- **Total deploys:** 1

## Template content

### Redis https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/redis.svg

- **Image:** redis:7.2.16-bookworm
- **Start command:** `sh -c 'exec redis-server --bind 0.0.0.0 :: --protected-mode yes --requirepass "$REDIS_PASSWORD" --appendonly yes --maxmemory-policy noeviction'`

### Postgres https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/postgresql.svg

- **Image:** postgres:17.11-bookworm

### Worker https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-api:1.17.1

### Plugin https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-plugin-daemon:0.6.10-local
- **Health check:** /health/check

### Sandbox https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-sandbox:0.2.15
- **Health check:** /health

### Web https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-web:1.17.1
- **Health check:** /signin

### Qdrant https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/qdrant.svg

- **Image:** qdrant/qdrant:v1.19.2
- **Health check:** /healthz

### Dify https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** nginx:1.28.0-alpine@sha256:30f1c0d78e0ad60901648be663a710bdadf19e4c10ac6782c235200619158284
- **Start command:** `sh -c 'printf %s "$NGINX_TEMPLATE_B64" | base64 -d > /tmp/nginx.template; resolver=$(sed -n "s/^nameserver //p" /etc/resolv.conf | head -n 1); case "$resolver" in *:*) resolver="[$resolver]";; esac; sed "s/RESOLVER/$resolver/" /tmp/nginx.template | envsubst "\$API_HOST \$WEB_HOST \$PLUGIN_HOST" > /etc/nginx/nginx.conf; exec nginx -g "daemon off;"'`
- **Health check:** /health
- **Public domain:** Yes

### Beat https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-api:1.17.1

### API https://raw.githubusercontent.com/langgenius/dify/1.17.1/web/public/favicon.ico

- **Image:** langgenius/dify-api:1.17.1
- **Health check:** /health

### SSRF-Proxy https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/docker.svg

- **Image:** ubuntu/squid@sha256:6a097f68bae708cedbabd6188d68c7e2e7a38cedd05a176e1cc0ba29e3bbe029
- **Start command:** `sh -c 'printf %s "$SQUID_CONFIG_B64" | base64 -d > /etc/squid/squid.conf; exec /usr/sbin/squid -f /etc/squid/squid.conf -NYC'`

## Buckets

- **dify-storage**

## Documentation

# Deploy and Host Dify on Railway

Dify is an open-source platform for building AI chatbots, visual workflows, knowledge bases and retrieval-augmented generation (RAG). This template deploys Dify AI 1.17.1 with background workers, signed plugins, a Python/JavaScript code sandbox, Qdrant and persistent S3 storage. The dashboard, app APIs and file URLs share one Railway HTTPS domain.

## About Hosting Dify

This stack runs the official Dify API, Web, Celery Worker and Beat images with a Plugin daemon, PostgreSQL, Redis, Qdrant, Dify Sandbox, an SSRF proxy and a small Nginx gateway. Railway creates the private networking, four persistent volumes and native S3 Bucket automatically. You do not need custom domains, a GitHub repository, SMTP or a model API key to deploy and create your first workflow.

The template pins Dify API/Web/Worker/Beat to 1.17.1, Plugin daemon to 0.6.10-local, Sandbox to 0.2.15, Qdrant to 1.19.2, PostgreSQL to 17.11 and Redis to 7.2.16. Nginx and Squid images are pinned to immutable digests. Only the Dify gateway has a public HTTP domain; internal databases and runtime services stay private.

### First login

1. Click **Deploy**. Wait for all 11 services, including API, Worker and Plugin, to finish starting. On a fresh database, migrations and image pulls can take several minutes.
2. Open the public domain of the **Dify** service.
3. Dify asks for an initialization key. Open **API → Variables**, copy the generated `INIT_PASSWORD` value and paste it into the initialization page. This guards the first owner setup. It is different from the account password you create next.
4. Enter your email, name and a new account password to create the first owner and workspace. Log in with that account. The official signed OpenAI provider is installed automatically after workspace creation.
5. To use LLMs or high-quality vector indexing, add a supported provider and its credentials in **Settings → Model Provider**. Provider API charges belong to the provider account and are separate from Railway hosting. A simple Python code workflow and economy keyword Knowledge indexing work without a paid model key.

Generated values and reference variables are supplied automatically, so there are no required blank values before deployment. `INIT_PASSWORD` is the first-run setup gate, not an automatic admin account or a password-reset mechanism. It does not update existing users when changed after setup. Keep `SECRET_KEY` and the data stores stable across redeploys.

### One public domain

Nginx routes the dashboard to Web, `/console/api`, `/api`, `/v1`, `/files`, `/mcp` and trigger callbacks to API, and `/e/` to Plugin. It preserves Railway HTTPS forwarding headers, allows uploads up to 100 MB at the proxy, and streams chat/workflow responses without proxy buffering. Dify's own smaller upload limits still apply.

The URL variables follow the Dify service's generated Railway domain. If you add a custom domain later, choose it as the public domain and set the public URL/CORS variables in API and Web to that same HTTPS origin. Worker and Beat inherit API settings. The default setup uses host-only secure authentication cookies and does not require `COOKIE_DOMAIN` or a second custom domain.

### Durable data

- **Postgres volume:** accounts, workflows, knowledge metadata, encrypted provider credentials, and the separate `dify_plugin` database created by Plugin.
- **Redis volume:** persistent Celery broker data and application state, with authentication and AOF enabled.
- **Qdrant volume:** knowledge vectors and collections.
- **Plugin volume:** installed signed packages, assets and Python execution environments.
- **Native Railway Bucket:** uploaded documents, files and workspace RSA private keys. API and workers share this object store directly, so no shared local filesystem is required.

Back up PostgreSQL, the Bucket, Plugin storage, Qdrant and the stable application secrets together. PostgreSQL alone cannot restore encrypted provider credentials: default workspace private keys are stored under `privkeys/WORKSPACE_ID/private.pem` in the Bucket. Keep the Bucket private. Do not delete persistent volumes or regenerate secrets as part of an ordinary redeploy.

### What has been verified

The acceptance checks use a fresh deployment of this exact configuration:

- First-run initialization, owner creation, login and authenticated console access on one HTTPS domain.
- A real Python Code node computes 42 from input 21 inside Dify Sandbox.
- The same published workflow executes through `/v1/workflows/run` with an app API key; requests without an API key are rejected.
- Text upload to the native Bucket, subsequent file read, completed Celery indexing and economy keyword retrieval.
- Installation with signature verification enabled and execution of the official JSON Process plugin inside a workflow.
- High-quality indexing and vector retrieval through Qdrant and the signed OpenAI-compatible provider, using a temporary private deterministic embedding fixture. This verifies the vector pipeline and credential handling; it does not measure an AI model's semantic quality. The fixture is not part of this template.
- Public HTTP workflow requests succeed; private destination requests are blocked by Dify's SSRF guard.
- Persistence after restart: the same owner, workflows, uploaded document, indexed Knowledge, vectors, encrypted provider credentials and signed plugin continue to work.

### Included scope

Classic visual workflows, Chatflow, chatbot apps, Knowledge/RAG, standard plugin tools, the existing agent nodes and Python/JavaScript Code nodes are included. Model-dependent features need the appropriate provider configuration.

The new experimental **Agent V2 local shell runtime** and realtime collaborative workflow editing are disabled. They require additional backend/sandbox or websocket services beyond this template. Railway private networking does not reproduce Docker Compose's isolated per-service networks, so this template does not provide mutually hostile-tenant sandbox isolation. Use it for a workspace of trusted users and keep administrative access private. Standard code and plugin runtimes also execute within the same Railway project network.

Email delivery is optional for initial owner creation and email/password login. Configure SMTP or a supported mail provider for invitations, password-reset emails and verified email changes. The Dify self-hosted license and upstream branding requirements still apply.

### Resource use

This is a complete multi-service stack. A brief acceptance run measured about **3.9 GB of combined memory** across the 11 included services after startup, with very low average CPU use. Using Railway's published resource rates, that snapshot is approximately **$40/month of compute if maintained continuously**, excluding persistent storage, Bucket usage, egress and model-provider charges. Any resource usage included in your Railway plan applies to the bill. This is an illustrative snapshot, not a guaranteed bill; document size, concurrent tasks, installed plugins and model traffic can change consumption.

Worker concurrency defaults to two and API to one process. Measure sustained memory and task latency before increasing concurrency. Disable unused services only if you understand which capabilities they supply; Beat supports scheduled workflows and periodic maintenance, while Plugin supplies model providers and tools.

### Upgrade and troubleshooting

Upgrade API, Web, Worker and Beat together using the same Dify release. Read that release's compatibility notes for Plugin and Sandbox images and back up persistent stores first. API runs database migrations; Worker and Beat do not run competing migrations. Shared PostgreSQL timeouts and TCP keepalives allow recovery when containers and private IPs change after a restart. The initial startup queue can wait for dependencies and fresh migrations to complete. Web uses `/signin` as its stable public readiness page, while the gateway probes `/health` on API. Using `/` for Web readiness would break redeploys after owner setup because the root page then redirects to sign-in.

If the dashboard loads but operations fail, inspect API and Worker logs first, then Plugin, Qdrant and the code Sandbox. A healthy dashboard alone does not establish that a Knowledge document finished indexing. Keep all private database/API keys generated by the template and do not expose database or runtime services through public domains.

## Why Deploy

Deploy a private, customizable Dify workspace with a visual AI workflow builder and durable knowledge data. This template removes manual multi-domain configuration and wires S3, workers, plugins, vectors and sandbox execution together using official containers.

## Common Use Cases

- Internal document assistants and knowledge retrieval with a configured embedding/LLM provider.
- Visual automation with Code, HTTP Request and signed plugin Tool nodes.
- Published AI apps or workflow APIs for an existing product.
- A private workspace for evaluating prompts, providers and RAG pipelines.

## Dependencies for Dify

Railway resources are created automatically. External AI models and email delivery are optional integrations configured inside Dify when needed.

### Deployment Dependencies

- [Dify official repository and release](https://github.com/langgenius/dify/releases/tag/1.17.1)
- [Dify self-hosting documentation](https://docs.dify.ai/en/self-host/deploy/quick-start/docker-compose)
- [Dify Plugin marketplace](https://marketplace.dify.ai/)
- [Qdrant](https://qdrant.tech/)
- [Railway native S3 Buckets](https://docs.railway.com/storage-buckets)
- [Railway resource pricing](https://docs.railway.com/pricing/plans)
- [Dify license](https://github.com/langgenius/dify/blob/1.17.1/LICENSE)


## Similar templates

- [Chat Chat](https://railway.com/deploy/-WWW5r) — Chat Chat, your own unified chat and search to AI platform.
- [stella](https://railway.com/deploy/stella) — Self-host stella with web, API, Postgres, Redis, and object storage.
- [Hermes Agent | OpenClaw Alternative with Dashboard](https://railway.com/deploy/hermes-agent-or-openclaw-alternative-wit) — Self-Hosted Hermes AI Agent for Telegram, Discord & Slack

Open this page in a browser: https://railway.com/deploy/dify-ai-with-qdrant-and-s3