Deploy Dify · Quick Start

Deploy and Host Dify on Railway

Dify is an open-source platform for building LLM apps: chatbots, agents, RAG over your own documents, and visual workflows, with a published API for each app. This template runs the full self-hosted stack from Dify's official docker-compose.yaml on Railway. It uses the official images, closes public sign-up, creates your admin account on first start and keeps everything on the private network except one HTTPS domain.

About Hosting Dify

• The complete upstream stack. API, Celery worker, Celery beat, web console, code sandbox, plugin daemon, agent backend, agent sandbox and SSRF proxy. These are the same services and settings as upstream docker/docker-compose.yaml, with a small Caddy router in place of nginx using the same routes.
• One public domain. The router is the only service with a domain. The console, /console/api, /api, /v1 (Service API), /files, /mcp, /triggers, /socket.io and plugin endpoints (/e/...) all share one origin, so Dify's cookie login works without cross-site settings. Every other service talks over *.railway.internal.
• No default login. The admin account is created from ADMIN_EMAIL with a generated password. /install is locked by a generated INIT_PASSWORD, and public sign-up and workspace creation are off.
• All secrets generated. These include SECRET_KEY, the plugin daemon key, the inner API key, the sandbox key, the agent tokens and the Postgres and Redis passwords. They are stored as variables, so they survive redeploys.
• Outbound traffic is filtered. HTTP requests from workflows, the code sandbox and the agent sandbox go through Squid, which blocks private, loopback, link-local and cloud-metadata addresses. Plugin signature checks are on, so only marketplace-signed plugins install.
• Durable storage.
  • Postgres with pgvector holds metadata, knowledge-base vectors and the plugin database, on a volume.
  • Redis runs on a volume.
  • Uploads and tenant encryption keys go to a Railway bucket (S3).
  • Installed plugins and the agent sandbox home have their own volumes.
• Tracks upstream. Images use :latest (the plugin daemon uses latest-local), and database migrations run automatically when the API starts.

Getting started

1. Enter ADMIN_EMAIL (the only input) and deploy. The first start takes a few minutes while the API runs database migrations.
2. Open the API service, then Variables, and copy ADMIN_PASSWORD.
3. Open the Dify service's public URL and sign in with ADMIN_EMAIL and ADMIN_PASSWORD. Change the password under Settings → Account.
4. Go to Settings → Model Provider, install a provider plugin from the marketplace (OpenAI, Anthropic, Gemini, Ollama, …) and add your API key.
5. In Studio, create an app (chatbot, agent or workflow), test it, publish it, and call it through the Service API at https://YOUR_DOMAIN/v1 with an app API key.
6. If you left ADMIN_EMAIL empty, open https://YOUR_DOMAIN/install, enter INIT_PASSWORD from the API service's variables and create the admin there.

Common Use Cases

• Chat assistants that answer from your own documents (knowledge bases with pgvector retrieval).
• Workflow automation that mixes LLM steps, Python and JavaScript code nodes, HTTP requests and tools.
• Agents that call marketplace plugins and tools, or your own APIs.
• A backend for LLM features in your product, using each app's REST API and API keys.
• Comparing model providers and prompts in one place before shipping.

Dependencies for Dify Hosting

• PostgreSQL with the pgvector extension (metadata, vectors and the plugin database)
• Redis (cache, locks and the Celery broker)
• S3-compatible object storage (a Railway bucket)

Deployment Dependencies

• Dify source and compose file: https://github.com/langgenius/dify/tree/main/docker
• Dify self-hosting docs: https://docs.dify.ai/en/self-host/quick-start/docker-compose
• Environment variable reference: https://docs.dify.ai/en/self-host/configuration/environments
• Official images: https://hub.docker.com/u/langgenius
• Plugin marketplace: https://marketplace.dify.ai
• Railway buckets: https://docs.railway.com/storage-buckets
• Railway private networking: https://docs.railway.com/networking/private-networking

Implementation Details

Custom domain: add the domain to the Dify service (target port 8080), set DIFY_PUBLIC_HOST on that service to the new host name, then redeploy API, Worker and Web so they pick up the new URL.

Email: password reset, invitations and email login need a mail provider. Set MAIL_TYPE (resend or smtp) and its variables on API and Worker, as described in Dify's environment docs.

Upgrades: the services pull :latest on every deploy. To upgrade, redeploy API first, because it runs migrations, then the other dify-* services. Back up Postgres before a major Dify release. To pin a version, change the image tag on API, Worker, Worker-Beat, Web, Sandbox and the agent services to the same release (for example 1.19.0). Pin the plugin daemon to its matching -local tag. Keep SECRET_KEY and the bucket. Without them, stored model credentials can't be decrypted.

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.