---
title: "Deploy Dify LLM App Platform + MinIO"
description: "Dify LLM app platform with pgvector, plugin daemon, sandbox and MinIO"
category: "AI/ML"
url: https://railway.com/deploy/dify-llm-app-platform-minio
---

# Deploy Dify LLM App Platform + MinIO

Dify LLM app platform with pgvector, plugin daemon, sandbox and MinIO

**[Deploy Dify LLM App Platform + MinIO on Railway](https://railway.com/template/dify-llm-app-platform-minio)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/dify-llm-app-platform-minio/manifest.json

- **Creator:** Protemplate
- **Category:** AI/ML
- **Total deploys:** 8

## Template content

### dify-web https://cdn.simpleicons.org/dify

- **Image:** langgenius/dify-web:1.17.1
- **Public domain:** Yes

### dify-api https://cdn.simpleicons.org/dify

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

### dify-sandbox https://cdn.simpleicons.org/dify

- **Image:** langgenius/dify-sandbox:0.2.15

### Redis https://devicons.railway.app/i/redis.svg

- **Image:** redis:7-alpine
- **Start command:** `sh -c 'docker-entrypoint.sh redis-server --requirepass "$REDIS_PASSWORD" --save 60 1 --dir /data --bind :: 0.0.0.0'`

### Postgres https://devicons.railway.app/i/postgresql.svg

- **Image:** pgvector/pgvector:pg16

### dify-worker https://cdn.simpleicons.org/dify

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

### MinIO https://cdn.simpleicons.org/dify

- **Image:** quay.io/minio/minio:RELEASE.2025-03-12T18-04-18Z
- **Start command:** `/bin/sh -c "mkdir -p /data/dify && exec minio server /data --address :9000"`

### dify-plugin-daemon https://cdn.simpleicons.org/dify

- **Image:** langgenius/dify-plugin-daemon:0.6.10-local

## Documentation

# Deploy and Host Dify on Railway

Dify is an open-source platform for building production LLM applications. It combines a visual workflow editor, RAG knowledge pipelines, agent orchestration, prompt management, and model provider integrations in one self-hostable app, so teams can move from prototype to production without stitching together separate tools.

## About Hosting Dify

Hosting Dify means running several cooperating services rather than a single container. The API server handles the console, public app, and service APIs; a Celery worker processes background jobs like document indexing and async tasks; a Next.js web frontend serves the UI; and a plugin daemon runs marketplace plugins in isolation. Backing them are PostgreSQL for application metadata and a vector store for embeddings, plus Redis for caching and the Celery broker. Self-hosting normally means provisioning each of these, generating shared secrets, running database migrations, and wiring private networking between them. This template does that wiring for you using the official pinned Docker images, persistent volumes, and Railway reference variables, with pgvector serving double duty as both the metadata database and the vector store to keep the service count low.

## Common Use Cases

- **AI app and chatbot builder**, design chat, completion, and agent apps in a visual editor and publish them as hosted web apps or APIs
- **RAG knowledge bases**, ingest documents, embed them into pgvector, and ground answers in your own data
- **Agentic workflows**, chain LLM calls, tools, conditionals, and code nodes into multi-step automations
- **Internal LLM gateway**, give a team one workspace to manage model providers, prompts, and usage
- **Plugin and tool extensions**, install marketplace plugins to add models, tools, and integrations

## Dependencies for Dify Hosting

- **PostgreSQL with pgvector**, application metadata database and the default vector store (provisioned by this template via the `pgvector/pgvector:pg16` image)
- **Redis**, cache and Celery message broker (provisioned by this template)
- **Dify API**, backend server (console, service, and inner APIs) on port 5001
- **Dify Worker**, Celery background task processor
- **Dify Web**, Next.js frontend on port 3000
- **Dify Plugin Daemon**, runs and isolates marketplace plugins on internal port 5002
- **Dify Sandbox**, sandboxed runtime for Code nodes in workflows, on internal port 8194
- **MinIO**, object storage for uploaded files, shared by the API and the worker

### Deployment Dependencies

- [Dify on GitHub](https://github.com/langgenius/dify)
- [Dify self-hosting documentation](https://docs.dify.ai/en/getting-started/install-self-hosted/readme)
- [Dify environment variable reference](https://docs.dify.ai/en/getting-started/install-self-hosted/environments)
- [dify-api Docker image](https://hub.docker.com/r/langgenius/dify-api)
- [dify-web Docker image](https://hub.docker.com/r/langgenius/dify-web)
- [pgvector image](https://hub.docker.com/r/pgvector/pgvector)

### Implementation Details

Uploaded files go to the MinIO service over S3 rather than a local directory, because the API and
the worker both need to read them and Railway cannot mount one volume into two services. That single
choice is what makes document indexing work here.

The default vector store is **pgvector inside the Postgres service**, which needs no extra container. To use a dedicated vector database instead, add a `qdrant/qdrant` service and point the API and worker at it:

```
VECTOR_STORE   = qdrant
QDRANT_URL     = http://${{Qdrant.RAILWAY_PRIVATE_DOMAIN}}:6333
QDRANT_API_KEY = 
```

Secrets and cross-service URLs are wired automatically with Railway references. The worker shares the API's `SECRET_KEY`, plugin keys, database, and Redis so encrypted data stays compatible:

```
SECRET_KEY (worker)        = ${{dify-api.SECRET_KEY}}
DB_HOST                    = ${{Postgres.RAILWAY_PRIVATE_DOMAIN}}
CELERY_BROKER_URL          = redis://default:${{Redis.REDIS_PASSWORD}}@${{Redis.RAILWAY_PRIVATE_DOMAIN}}:6379/1
CONSOLE_WEB_URL            = https://${{dify-web.RAILWAY_PUBLIC_DOMAIN}}
PLUGIN_DAEMON_URL          = http://${{dify-plugin-daemon.RAILWAY_PRIVATE_DOMAIN}}:5002
```

After deploy, generate public domains for `dify-api` and `dify-web` (the URL variables update automatically), open the web URL, and create the first admin account. **Known limitation:** Railway volumes cannot be shared between services, so `dify-api` and `dify-worker` each mount their own `/app/api/storage`. For production file and dataset operations that both must read, switch `STORAGE_TYPE` to Railway object storage (S3) so uploads are centralized.

## Why Deploy Dify on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Dify on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Private networking connects the eight services with no egress cost, the API and worker scale independently, and persistent volumes keep your data safe across redeploys. Host your servers, databases, AI agents, and more on Railway.


## 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-llm-app-platform-minio