🤖 Dify on Railway — Lean Stack

Self-host Dify, the open-source LLM app platform, on Railway — same RAG/agent/workflow features as the standard deploy, running one fewer service.

🎯 What is Dify?

Dify is an open-source platform for building and running LLM applications: a visual workflow builder, RAG pipelines for your own documents and knowledge bases, agent tooling with 50+ built-in integrations, and a model-agnostic backend that talks to OpenAI, Anthropic, local models, and dozens of other providers — all through one console and one API.

Common Use Cases

• Internal Knowledge Bases: Connect your company's documents to build a secure, private RAG pipeline for employee Q&A.
• Autonomous AI Agents: Equip LLMs with custom tools (API calls, web scraping) to automate complex, multi-step tasks.
• Customer Support Bots: Deploy intelligent, context-aware chatbots trained on your product documentation and help center articles.
• Visual Prompt Orchestration: Design and test multi-model workflows visually before exposing them via API to your frontend applications.

⚡ Why This Template

The reference Dify stack ships 11 containers, including a dedicated Weaviate service for vector search. This template drops Weaviate and points Dify at pgvector instead — a Postgres extension running on the same Postgres instance Dify already needs for its application data. Same knowledge-base/RAG functionality, one fewer container to provision and pay for, and one less service that Dify's own hosting guides flag as a common source of out-of-memory crashes on smaller hosts.

MinIO stays, on purpose. It's tempting to drop it too and write uploads straight to a Railway volume, but Railway doesn't support sharing one volume across services — and Dify's Api and Worker containers both need read/write access to the same uploaded files (Api saves what you upload, Worker processes it into the knowledge base afterward). MinIO gives them shared access over the network, which a local volume can't.

Deploy and Host

About Hosting

Hosting Dify on Railway provides a managed, scalable environment for your LLM applications without the overhead of traditional infrastructure. Railway handles the container orchestration, internal DNS, and volume management out of the box, allowing you to focus on building AI workflows rather than debugging server configurations.

Why Deploy

• Cost Efficiency: By replacing Weaviate with pgvector, you consolidate your database and vector store, significantly reducing your monthly resource footprint.
• Zero-Config Networking: Railway's internal private networking securely connects your Api, Worker, Postgres, Redis, and MinIO services without exposing backend databases to the public internet.
• Instant Scaling: You can easily scale up RAM and CPU for the Worker and Sandbox containers independently as your background processing and code execution needs grow.

Dependencies for

Deployment Dependencies

• Railway Account: A Developer or Pro plan. (The Hobby tier minimums will not provide enough RAM for the Dify Api and Worker containers to run stably).
• PostgreSQL 16 (with pgvector): Serves as both the application database and the vector store.
• Redis 7: Required for caching and acting as the Celery task broker.
• MinIO: Required for shared, network-accessible file storage between the Api and Worker containers.
• LLM API Keys: Active API keys for OpenAI, Anthropic, or other providers to power your agents once the platform is live.

🏗️ Architecture

Note: 8 services run long-term. The two "temp" jobs get deleted after first deploy — same pattern as the standard Dify template.

🚀 Deployment Steps

1. New empty project on Railway.
2. Add Postgres from pgvector/pgvector:pg16 (not Railway's native Postgres plugin — it needs the pgvector extension pre-built in). Set POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB=dify. Mount a volume at /var/lib/postgresql/data.
3. Add Redis from redis:7-alpine. Mount a volume at /data. Set the start command to redis-server --requirepass $REDIS_PASSWORD and define REDIS_PASSWORD.
4. Add Storage from minio/minio. Mount a volume at /data. Set MINIO_ROOT_USER, MINIO_ROOT_PASSWORD, start command minio server /data --console-address ":9001".
5. Add Storage Provision from minio/mc — a one-off job that creates the bucket against the Storage service, then exits. Reference Storage's internal domain via Railway's ${{Storage.RAILWAY_PRIVATE_DOMAIN}} variable syntax.
6. Add DB Provision from postgres:16-alpine — a one-off job that connects to Postgres and runs CREATE DATABASE dify_plugin; plus CREATE EXTENSION IF NOT EXISTS vector; on the dify database.
7. Add Plugin Daemon, Sandbox, Api, Worker, Web from the images above, wiring each to Postgres/Redis via Railway's variable references rather than hardcoding hosts.
8. Generate public domains for Web and Api separately.
9. Set CONSOLE_API_URL, SERVICE_API_URL, and APP_WEB_URL to your actual generated domains, and set WEB_API_CORS_ALLOW_ORIGINS / CONSOLE_CORS_ALLOW_ORIGINS so Web can call Api across domains.
10. Deploy everything, then delete Storage Provision and DB Provision once they've run successfully.

Important: Worker's exact Celery start command and the current storage variable names (OPENDAL_* vs S3_*) shift between Dify releases — confirm both against the current docker-compose.yaml and .env.example before you publish.

🔑 Core Environment Variables

Note: Storage (MinIO/S3) and Plugin Daemon variables aren't in this table because their exact names move between Dify versions — pull the current list from Dify's .env.example linked above rather than trusting a snapshot here.

👤 First-Time Admin Setup

Dify doesn't ship default credentials. On first boot:

1. Visit [https://your-web-domain.up.railway.app/install](https://your-web-domain.up.railway.app/install)
2. Enter the value you set for INIT_PASSWORD
3. Create your admin email + password
4. Log in at the regular console URL from then on

If you didn't set INIT_PASSWORD, check the Api service's deploy logs — Dify may print a one-time setup link there instead, the same way PocketBase does.

🛡️ Security Considerations

• Set a real SECRET_KEY and INIT_PASSWORD before your first deploy — don't leave either blank on a public domain.
• Rotate MINIO_ROOT_PASSWORD, REDIS_PASSWORD, and POSTGRES_PASSWORD away from any example values before going live.
• Keep INIT_PASSWORD set until setup is complete; it has no effect afterward, so there's no need to remove it, but don't publish it anywhere.

📊 Limitations

• Heavier than a typical Railway template — budget real RAM for Api, Worker, and Sandbox, not hobby-tier minimums.
• Two separate public domains (Web, Api) means CORS config to get right, unlike single-domain Nginx-fronted Dify setups.
• First deploy takes a few minutes longer than a single-service template while Postgres, Redis, and MinIO all come up before Api can start cleanly.

🔗 Links

• Dify Documentation
• Dify GitHub
• Dify Environment Variables Reference
• Railway Documentation

📄 License

This template deploys official Dify images under the Dify Open Source License (Apache 2.0 plus two restrictions: no unauthorized multi-tenant SaaS use, no removing Dify's branding from the console). This is a community deployment template, not an official Dify or LangGenius product.

Made with ❤️ for the Railway community