Deploy and Host Open WebUI + LiteLLM on Railway

Open WebUI gives your team a private ChatGPT-style workspace, while LiteLLM sits behind it as an OpenAI-compatible gateway for provider keys, routing, virtual keys, and spend controls. This Railway template deploys Open WebUI with a private LiteLLM service, two Postgres databases, and Redis.

Published marketplace code: owui-litellm-src-20260617b

Published template ID: 54f72708-921d-41e7-bf86-40218160584c

About Hosting Open WebUI + LiteLLM

Self-hosting Open WebUI and LiteLLM keeps chat history, user accounts, provider configuration, and gateway state in infrastructure you control. Open WebUI stores users, chats, settings, and API keys in its own Postgres database. LiteLLM stores virtual keys, provider config, and spend data in a separate Postgres database, with Redis available for cache and routing coordination.

The template exposes only Open WebUI publicly. LiteLLM, both Postgres services, and Redis remain private inside the Railway project network.

Why Deploy Open WebUI + LiteLLM on Railway

Railway is a good fit for this stack because it can provision the app containers, private service networking, persistent databases, Redis, volumes, generated secrets, and public HTTPS domain in one deploy flow. You get a working Open WebUI frontend while keeping the LiteLLM gateway internal by default.

This template also bootstraps a generated Open WebUI admin account and generated LiteLLM master/salt keys so you can sign in, add provider keys, and configure models after deployment.

Common Use Cases

Private AI chat workspace for a team
OpenAI-compatible proxy in front of multiple LLM providers
Centralized provider key management
LiteLLM virtual key and spend tracking
Persistent Open WebUI chat and user state
Railway-hosted AI gateway starter stack

Dependencies for Open WebUI + LiteLLM

Deployment Dependencies

Open WebUI via ghcr.io/open-webui/open-webui:main
LiteLLM Proxy via ghcr.io/berriai/litellm:main-stable
Postgres 17 for Open WebUI state
Postgres 17 for LiteLLM state
Redis 7 for LiteLLM cache and routing coordination

Post-Deploy Setup

After deployment, open the public Open WebUI service URL and sign in with the generated WEBUI_ADMIN_EMAIL and WEBUI_ADMIN_PASSWORD variables from the open-webui service.

Then configure provider credentials and models inside Open WebUI or LiteLLM. The template does not include provider API keys, and it does not deploy local model inference or GPU workers.

Persistence

Open WebUI chat/user state persists in openwebui-postgres. LiteLLM gateway state persists in litellm-postgres. Redis has a persistent /data volume and is configured with maxmemory-policy noeviction.

Validation Evidence - 2026-06-17

Source project owui-litellm-src-20260617b deployed open-webui, litellm, openwebui-postgres, litellm-postgres, and redis to SUCCESS.
Source Open WebUI /health and root returned HTTP 200, and generated admin sign-in returned HTTP 200.
Source LiteLLM /health/liveliness and /health/readiness returned HTTP 200.
Source /key/generate created token 68b78034e211479f6f9ce22b7bd1afc361a0c4799dec044815700021667c7a75; /key/list returned it after a litellm restart.
Source admin sign-in still worked after an open-webui restart.
Public-template test project owui-litellm-test deployed all five services to SUCCESS.
Public-template Open WebUI /health and root returned HTTP 200 after first boot, and admin sign-in returned HTTP 200.
Public-template LiteLLM /health/liveliness and /health/readiness returned HTTP 200.
Public-template /key/generate created token 89322da8c530f9697e6bf8b2b568a99d7ed3a9cefe73d43c327e6320aef765a9; /key/list returned it after a litellm restart.
Public-template admin sign-in still worked after an open-webui restart.
Temporary LiteLLM validation domains, source project, and public-template test project were deleted after validation; cleanup audit returned [].