Deploy Open WebUI

Deploy and Host Open WebUI on Railway

Open WebUI is a self-hosted chat interface for large language models: conversations, model switching, document chat with RAG, prompt presets and multi-user accounts, in a UI that will feel familiar to anyone who has used ChatGPT. It talks to OpenAI-compatible APIs and to Ollama, so you choose the backend and keep the chat history on your own infrastructure.

About Hosting Open WebUI

Open WebUI is the front end. It does not run models itself — it needs somewhere to send inference requests, and this is the decision to make before you deploy.

An OpenAI-compatible API is the straightforward path. Set OPENAI_API_KEY and Open WebUI will use it; the same variable works for any provider that speaks the OpenAI protocol, including a LiteLLM or OpenRouter gateway, by pointing the base URL at it.

Ollama is the other path. Set OLLAMA_BASE_URL at an Ollama instance you run elsewhere. Note that Railway has no GPUs, so running Ollama alongside this on Railway means CPU inference, which is slow enough to be frustrating for anything but the smallest models. Point it at a GPU host instead.

Chat history, user accounts, uploaded documents and the vector index all live in /app/backend/data, which this template mounts as a volume, so your conversations survive redeploys.

Common Use Cases

• Give a team one shared chat interface over an API key, instead of handing the key to everyone.
• Keep conversation history on infrastructure you control rather than in a vendor's account.
• Chat with your own documents using the built-in RAG pipeline.
• Put a familiar UI in front of a self-hosted or gateway-routed model fleet.
• Compare models side by side without changing tools.

Dependencies for Open WebUI Hosting

• A model backend — an OpenAI-compatible API key, or an Ollama endpoint. Nothing works until one is configured.
• A volume at /app/backend/data — provisioned by this template. Holds accounts, chats, documents and embeddings.
• No database service required. Open WebUI uses SQLite inside that volume, which is fine for a team; heavy multi-user installs can be pointed at Postgres instead.

Implementation Details

WEBUI_SECRET_KEY signs sessions and is generated at deploy time. Keep it stable — rotating it invalidates every existing session.

WEBUI_AUTH and ENABLE_SIGNUP control who gets in. The first account created becomes the administrator. Turn signup off once your team has registered, or anyone who finds the URL can create an account and spend your API credit.

DEFAULT_MODELS sets what new conversations open with, so users are not left picking from an empty list.

After You Deploy

1. Open the public URL and create the first account — it becomes the admin.
2. Set ENABLE_SIGNUP to false once everyone who needs access has registered.
3. Confirm your model backend under Settings, and send a test message.
4. If you plan to use document chat, upload one small file first and check the embedding step completes.

Cost and Credit

The container itself is inexpensive; your model provider is where the money goes. Because every user shares one API key, an open signup page is a direct path to an unexpected bill. Set usage limits at the provider as well as turning signup off.

Why Deploy Open WebUI 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 Open WebUI 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.