---
title: "Deploy Dify | AI App Builder with a Redis That Requires a Password"
description: "AI app builder stack whose Redis actually enforces its password"
category: "AI/ML"
url: https://railway.com/deploy/dify-or-ai-app-bui-1
---

# Deploy Dify | AI App Builder with a Redis That Requires a Password

AI app builder stack whose Redis actually enforces its password

**[Deploy Dify | AI App Builder with a Redis That Requires a Password on Railway](https://railway.com/template/dify-or-ai-app-bui-1)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/dify-or-ai-app-bui-1/manifest.json

- **Creator:** Templates Guru
- **Category:** AI/ML

## Template content

### Weaviate

- **Image:** semitechnologies/weaviate:1.32.19

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

- **Image:** postgres:15-alpine
- **Start command:** `/bin/sh -c "unset PGPORT; docker-entrypoint.sh postgres --port=5432"`

### Storage

- **Image:** pgsty/minio:RELEASE.2026-08-04T00-00-00Z
- **Start command:** `/bin/sh -c "mkdir -p $RAILWAY_VOLUME_MOUNT_PATH/difyai && exec minio server --address [::]:$MINIO_PRIVATE_PORT $RAILWAY_VOLUME_MOUNT_PATH"`

### Api

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

### Web

- **Image:** langgenius/dify-web:1.16.1
- **Health check:** /
- **Public domain:** Yes

### plugin-daemon

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

### Worker

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

### Sandbox

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

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

- **Image:** redis:6-alpine
- **Start command:** `/bin/sh -c 'redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes --bind 0.0.0.0 :: --protected-mode no'`

## Documentation

# 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

- [Dify on GitHub](https://github.com/langgenius/dify)
- [Official Docker Compose bundle](https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml)
- [Dify documentation](https://docs.dify.ai)

### 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.


## 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-or-ai-app-bui-1
