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

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.