Deploy and Host Dify on Railway

Dify is an open-source platform for building AI applications and agentic workflows: a visual builder, a plugin system, RAG pipelines, and both a console and a public API for the apps you publish. This template runs the full ten-service stack: Postgres, Redis, Weaviate, MinIO, the code sandbox, the plugin daemon, the API, the queue worker, and the web console.

About Hosting Dify

Dify ships an official Docker Compose bundle, and the most-installed Railway template for it is a close copy of that bundle. Copying it also copies one of its assumptions: the bundle's Redis has no password enforced on the server, because in Docker Compose Redis is never reachable from outside the compose network. On Railway a service can get a public TCP proxy, and once it does, an unauthenticated Redis is a database anyone can read and write from the open internet.

This was verified directly, not assumed. A bare redis:6-alpine container built the same way - no start command, a REDIS_PASSWORD variable that is never passed to the server - was deployed with a public TCP proxy, and an anonymous redis-cli connection could PING, SET, and GET without ever authenticating. This template's Redis runs with an explicit redis-server --requirepass "$REDIS_PASSWORD" start command instead, so the password variable is the password, not decoration.

Three internal keys that coordinate the API and the plugin daemon (SERVER_KEY, DIFY_INNER_API_KEY, and the serverless-connector key) are generated per deployment here. In the template this was built from, those three were fixed literal strings, identical across every installation made from it.

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. Host your servers, databases, AI agents, and more on Railway.

Specific to this template:

Redis requires its password. See above - this is the one that matters.
Every image is pinned: Dify 1.16.1 (API and Web), plugin-daemon 0.6.6-local, sandbox 0.2.15, Weaviate 1.32.19, MinIO RELEASE.2025-09-07. Nothing tracks latest.
The MinIO bucket is created before the server starts serving, as part of Storage's own start command, instead of a separate one-shot container. A minio/mc container takes its command as literal arguments to the mc binary - there is no shell in between - so a shell one-liner passed as a start command doesn't run a script, it prints mc's own usage text and exits. That is a real trap in the source template, not a hypothetical one.
Verified by completing the actual first-run setup through Dify's own console API: POST /console/api/setup returned 201, Alembic ran the schema migration, and the API logged Using ak and sk for S3 against this template's MinIO credentials.

Common Use Cases

A self-hosted AI app builder for a team that wants its workflows, prompts, and API keys on infrastructure it controls rather than a shared SaaS.
A RAG backend: Weaviate for vectors, MinIO for the source documents and generated files, Postgres for everything relational.
A base for agent workflows that need the code sandbox and the plugin system rather than a plain chat completion wrapper.

Dependencies for Dify Hosting

Postgres for relational data and the plugin daemon's own database
Redis for the Celery broker, cache, and pub/sub
Weaviate as the vector store
MinIO as the S3-compatible object store
A sandbox service for AI-written code execution
A persistent volume on Postgres, Redis, Weaviate, MinIO, and the sandbox

Deployment Dependencies

Implementation Details

Nothing to fill in - every credential is generated per deployment and wired between services automatically. Visit the Web service's domain to create the first workspace and administrator account through Dify's own setup flow.

SMTP and initial-password variables are intentionally left out of this template rather than shipped blank: Dify's config layer treats a present but empty SMTP_PORT as an invalid integer and refuses to start, which is a different failure mode from that variable being absent. Add SMTP_SERVER, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, MAIL_TYPE, and MAIL_DEFAULT_SEND_FROM on the Api and Worker services yourself if you want outbound email; Dify runs correctly without them.