Deploy and Host Dify on Railway

Dify is an open-source LLM app development platform: a visual builder for chatbots, agents and RAG workflows, with a plugin marketplace for model providers and tools, a knowledge base with vector retrieval, a sandbox for generated code, and an API for every app you publish.

This template runs Dify 1.16.1 as six services instead of eleven, with the plugin daemon verified working end to end — a marketplace plugin was installed on the live deploy and survived a redeploy.

About Hosting Dify

Dify is not a single container. It needs an API server, a Celery worker, a beat scheduler, a Next.js frontend, a code sandbox, a plugin daemon, PostgreSQL, a vector store, Redis, and object storage. Most Railway templates map that one-to-one and bill you for eleven services, including two one-shot "provisioning" containers you are told to delete by hand.

This template folds the API, worker and beat into one container (Railway volumes cannot be shared between services, and all three want the same storage directory), uses pgvector inside the same PostgreSQL instance instead of a separate vector database, and stores files on a volume instead of running MinIO plus an mc provisioning job. The frontend container also runs the nginx gateway, so the API never needs a public domain and nothing runs with CONSOLE_CORS_ALLOW_ORIGINS=*.

Other things handled for you:

Migrations run once. Upstream's compose enables migrations on both the API and the worker, which races alembic on first boot. Here they run once, before any role starts.
Every image is pinned (api/web 1.16.1, sandbox 0.2.15, plugin daemon 0.6.3, PostgreSQL pgvector pg17, Redis 8.2.1). Dify migrates forward on boot and does not support downgrade, so a moving tag makes every redeploy an unrequested upgrade.
The install is closed. INIT_PASSWORD is generated per deploy, so the first stranger who finds your URL cannot claim the instance.
Volumes are repaired before the privilege drop, so the API's storage directory and the plugin daemon's package directory are actually writable.
PostgreSQL is sized from the container's cgroup rather than left at the 128 MB default shared buffers.

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.

Dify is an always-on service — an API, a worker, a scheduler and a plugin daemon that stay resident — which is exactly the workload Railway's usage-based billing and private networking suit. Everything talks over the private network; only the web frontend gets a public domain.

Common Use Cases

Build and publish LLM chatbots and agents with a visual workflow editor, then call them from your own product over Dify's API.
Run retrieval-augmented generation over your own documents using the built-in knowledge base and pgvector.
Give a team a shared, self-hosted console for prompt engineering, model comparison and conversation logs, without sending prompts through a SaaS.

Dependencies for Dify Hosting

PostgreSQL 17 with the pgvector extension (application database, plugin database and vector store — included in this template)
Redis 8 (Celery broker and plugin daemon coordination — included)
Dify sandbox for executing generated code (included)
Dify plugin daemon for the model-provider and tool marketplace (included)

Deployment Dependencies

Dify source and documentation: https://github.com/langgenius/dify
Dify plugin marketplace: https://marketplace.dify.ai
Railway wrapper images and build files: https://github.com/bon5co/dify-railway

Implementation Details

After the deploy finishes, open the web service's public URL. The instance is locked with the generated INIT_PASSWORD on the api service: copy it from the Railway variables panel, enter it on the first screen, then create your admin account. Model providers are installed from the plugin marketplace inside the console — no API keys are required at deploy time.

Uploaded files and installed plugins live on volumes, so they survive redeploys.