Deploy and Host Dify on Railway

For a visual AI application builder on Railway with document retrieval and plugin infrastructure included, use Dify AI Pro Stack. It connects Dify 1.17.1, PostgreSQL, Redis, Qdrant, signed plugins, a code sandbox and a private S3-compatible Bucket across 11 services behind one public HTTPS origin. Create the owner account without a model key, then configure providers in Dify for chat, embeddings and model-dependent workflows.

The application runs Dify 1.17.1. First-owner setup needs no model key, SMTP or custom domain. Configure model providers inside Dify when you need chat, embeddings or other model-dependent features. If you searched for Difi, the open-source AI app builder's name is Dify.

Why Deploy Dify on Railway?

Your requirement	Included configuration
Build workflows and chat applications	Official API/Web images, Celery Worker and Beat
Index a document knowledge base	Qdrant plus background indexing workers
Install model providers and tools	Signed Plugin daemon with persistent package storage
Run Code nodes and HTTP Request nodes	Dify Sandbox and an SSRF proxy
Keep uploads across app redeployments	Shared native Railway S3 storage and persistent databases
Avoid wiring multiple public origins	One HTTPS gateway for dashboard, APIs, files and streaming
Use Railway database tooling	Native PostgreSQL/Redis configurations and standard connection variables

First deployment and owner setup

Deploy and wait for all services, especially API, Worker and Plugin, to start. Fresh migrations and image pulls can take several minutes.
Open the public domain of the Dify gateway service.
At the initialization page, paste the generated INIT_PASSWORD from API → Variables.
Create your owner account with your email, name and a new password, then sign in. The signed OpenAI provider is installed automatically after workspace creation.
Open Settings → Model Provider and configure the providers needed by your application. Start with a small workflow or Knowledge document and verify its execution/indexing status.

INIT_PASSWORD protects first-owner setup; it does not reset existing passwords. Generated values are supplied, with no required blank values before deployment.

Frequently asked questions

Can I deploy Dify without an OpenAI API key?

Yes. Deployment, owner creation and the visual builder do not require one. A basic Python Code workflow and economy keyword Knowledge indexing can run without paid model credentials. LLM chat, vector embeddings and model-based nodes need a configured provider. Hosting and provider API usage are billed separately.

Is this Dify template suitable for RAG and document Q&A?

Yes. Knowledge documents are stored in the private Bucket; workers process indexing tasks; Qdrant stores vectors; PostgreSQL stores knowledge metadata. Select a compatible embedding provider for vector indexing and a chat model for generated answers. Wait for documents to finish indexing before testing retrieval.

Can I use Claude or other models with Dify?

Configure a supported provider plugin and credentials in Dify's Model Provider settings. The Plugin daemon supplies provider/tool execution; the signed OpenAI provider is bootstrapped automatically. Other providers may need their own signed plugin installation and account permissions. No model credits are bundled, and this template's integration tests do not validate every provider account.

Will workflows, documents and credentials survive a redeploy?

They persist when the same volumes, Bucket and secrets are preserved. Back up all persistent components together. Provider credentials depend on both the PostgreSQL data and workspace RSA private keys stored in the Bucket under privkeys/WORKSPACE_ID/private.pem; a PostgreSQL-only backup is insufficient to restore those credentials.

Do I need two domains, SMTP or GitHub to get started?

No. A generated Railway HTTPS domain serves the whole application. The template deploys from container images. Email/password owner login works without SMTP. Configure a mail provider for invitations, password-reset emails and verified email changes.

Does it include Agent V2 or collaborative editing?

Classic workflows, Chatflow, chatbot apps, Knowledge/RAG, standard plugin tools, existing agent nodes and Python/JavaScript Code nodes are included. Experimental Agent V2 local-shell execution and realtime collaborative workflow editing are disabled because they need additional runtime or websocket infrastructure.

Can unrelated customers safely run arbitrary code in this deployment?

Use this configuration for a workspace of trusted users. Code, plugin and other runtime services share the Railway project network. The included Sandbox and SSRF proxy do not establish isolation between mutually hostile tenants. Limit administrator access and review plugins before installation.

About Hosting Dify

Resource	Version or role
API, Web, Worker and Beat	Official Dify 1.17.1 application images
Plugin	Official Plugin daemon 0.6.10-local, signed packages
Sandbox	Dify Sandbox 0.2.15 for Code nodes
Qdrant	1.19.2 vector storage
Postgres	Railway SSL PostgreSQL 17.11
Redis	Native Railway Redis 8.2 with authentication/AOF
Dify gateway	Nginx, one public HTTPS origin
SSRF-Proxy	Squid for restricted outbound HTTP requests
Railway Bucket	Private shared S3-compatible storage

PostgreSQL, Nginx and Squid images are pinned by immutable digest. PostgreSQL and Redis reuse native Railway database configurations with standard PG*, REDIS* and connection-URL variables. The Plugin daemon uses a separate dify_plugin database, and Redis database indexes separate application uses.

Only Dify receives a public HTTP domain. Databases and execution services use private networking. Nginx routes the dashboard to Web; /console/api, /api, /v1, /files, /mcp and trigger callbacks to API; and /e/ to Plugin. Responses can stream without proxy buffering. The gateway permits uploads up to 100 MB; Dify's own smaller application limits still apply.

Persistent storage and backups

Store	Durable data
Postgres volume	Accounts, workflows, Knowledge metadata, encrypted credentials, plugin database
Redis volume	Persistent broker and application state
Qdrant volume	Vector collections
Plugin volume	Signed packages, assets and Python environments
Private Railway Bucket	Uploaded files and workspace private keys

API and workers access the same Bucket without a shared local filesystem. Preserve SECRET_KEY, datastore credentials, the Bucket and all four volumes across restarts. Back up PostgreSQL, Qdrant, Plugin storage, object storage and secrets as a consistent set. Delete neither volumes nor keys during a routine redeploy.

Verification and troubleshooting

Acceptance checks cover fresh owner setup/login, a Python Sandbox workflow (21 → 42), authenticated workflow API execution, S3 upload/read, Celery indexing, keyword retrieval, a signed JSON Process plugin, restricted HTTP requests and persistence after restart.

Qdrant vector retrieval and credential persistence were also checked using a signed OpenAI-compatible provider with a private deterministic embedding fixture. This validates the integration path rather than semantic model quality. The fixture is not deployed with the template.

For failed tasks, inspect API/Worker logs, then Plugin, Qdrant and Sandbox. Check provider credentials, the selected model and document status: gateway health alone does not prove indexing succeeded.

API runs migrations; Worker/Beat do not. Database timeouts and keepalives help reconnection after restarts. Web readiness uses /signin because / redirects after setup; gateway health probes API's /health.

Capacity, costs and upgrades

Railway bills all 11 services, storage and applicable networking; models are billed separately. A brief acceptance run used 3.9 GB combined memory after startup, not a capacity or price guarantee. Documents, plugins and concurrency change usage.

Worker concurrency defaults to two; API uses one process. Measure memory and latency before raising concurrency. Keep Beat for schedules/maintenance and Plugin for providers/tools.

Upgrade API, Web, Worker and Beat to the same release together. Review that release's Plugin/Sandbox requirements and back up storage first. PostgreSQL major-version changes require a database migration.

For a custom domain, keep API/Web public URL and CORS settings on one HTTPS origin; Worker and Beat inherit API settings. Host-only secure cookies need neither COOKIE_DOMAIN nor a second domain. Never expose private datastore/runtime services or credentials to browser code.

Dependencies for Dify Hosting

Deployment Dependencies

Dify's self-hosted license, branding and applicable feature licensing remain in effect. Configure external models and email when needed.