Deploy Dify

Deploy and Host Dify on Railway

Dify is an open-source platform for building LLM applications: visual workflows, agents, RAG pipelines over your own documents, and a prompt IDE, with every app publishable as a chat interface or an API endpoint. This template runs Dify 1.19.0 as a full ten-service stack, configured for the things that break when you move Dify's docker-compose.yaml onto Railway unchanged.

About Hosting Dify

Dify is not a single container. It is a web console, an API, Celery workers, a code sandbox, a plugin runtime, a database, a cache, and a gateway that routes between them. Running it properly means running all of that, and three of Dify's compose assumptions do not survive the move to Railway.

Shared file storage. Dify's compose mounts one storage directory into both the API and the worker. A Railway volume attaches to exactly one service, so a volume-based setup leaves the worker unable to read the files the API saved — document indexing hangs with no obvious error. Worse, with the default key provider Dify writes each workspace's RSA private key into that same storage and uses it to encrypt your saved model-provider credentials. On an ephemeral filesystem, a redeploy throws that key away and your stored API keys become permanently undecryptable. This template puts application storage in a Railway bucket, so the API, worker and scheduler share one object store and the keys outlive a redeploy.

IPv6. Railway's private network is IPv6-only. Gunicorn and Next.js both bind 0.0.0.0 by default, so the services come up green and are unreachable from the gateway. The API binds [::] and the web service sets HOSTNAME=::.

Gateway DNS. A service gets a new private address on every redeploy, and nginx resolves proxy_pass hostnames once at startup. The gateway here resolves through Railway's internal DNS on a one-second TTL with the upstream in a variable, so it keeps working after the API restarts.

Common Use Cases

• Build a RAG chatbot over your own documents and publish it as a web app or API.
• Design multi-step agent workflows visually instead of writing orchestration code.
• Give a non-engineering team a prompt IDE with versioning and side-by-side model comparison.
• Put one governed layer in front of several model providers, with usage logged per app.
• Self-host so prompts, documents and conversation logs stay on infrastructure you control.

Dependencies for Dify Hosting

• A model provider. Dify ships with none. After deploying you install a provider plugin (OpenAI, Anthropic, Gemini, or any OpenAI-compatible gateway) from the marketplace and add your key. Until then the model list is empty — that is expected, not a broken deploy.
• Postgres with pgvector, provisioned here. It holds the application database, the vector index and the plugin daemon's separate database, which the image creates on first boot.
• Redis, as the Celery broker and cache.
• A Railway bucket, for uploaded files, generated files and workspace encryption keys.

Implementation Details

SECRET_KEY signs sessions and encrypts stored secrets. It is generated at deploy time; rotating it invalidates sessions and saved credentials.

The SSRF proxy sits in front of outbound traffic from the sandbox and from HTTP-request nodes, and denies anything addressed to the private network. Without it, anyone who can edit a workflow in your Dify can reach your own Postgres.

The sandbox runs the Python and JavaScript in code nodes in a confined process. The API refuses to execute a code node if it cannot reach it.

The plugin daemon keeps installed plugins on a volume, and its container runs as a non-root user while Railway mounts volumes as root — this template fixes that ownership at boot, which is otherwise the cause of every plugin install failing after the download succeeds.

Dify's agent sandbox (agent_backend and local_sandbox) is not included. It expects Docker-level isolation and dedicated network segments that Railway does not provide, and running it without them would hand workflow authors a shell with reach into your project.

After You Deploy

1. Open the public URL and create the admin account immediately — the setup page is open to whoever reaches it first.
2. Go to Integrations → Model Provider and install a provider plugin, then add your API key.
3. Set a default system model, or apps will have nothing to run against.
4. Upload one small document to a knowledge base. Indexing is the first thing that exercises the bucket from the worker, so it is where a storage problem would surface.

Cost and Scaling

Ten services is a real deployment, not a hobby one. The containers idle cheaply and the model provider will be the larger bill, but this is not a single-container app. If your knowledge base outgrows pgvector, set VECTOR_STORE to Qdrant, Weaviate or Milvus and point the matching variables at it; nothing else changes.

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.