Deploy and Host Open WebUI on Railway

Open WebUI is the most widely used self-hosted AI chat interface — a private, ChatGPT-style front end over OpenAI, Anthropic or any OpenAI-compatible model. This template deploys it for the job most people want from it: chatting with their own documents. Postgres with pgvector holds the embeddings, Apache Tika handles extraction, and embeddings run through an API rather than in-container — the configuration that keeps document upload from killing the worker.

What This Template Deploys

Service	Purpose
`open-webui`	Chat interface, users, roles and RAG on port `8080`. Public domain.
`Postgres`	Application data and vector store, via the pgvector extension. Volume attached.
`tika`	Apache Tika extraction sidecar for PDFs, Office files and scanned documents.
Volume	Uploaded source documents under the app data directory.

All three talk over Railway's private network and only Open WebUI takes a public domain. Note the Postgres image carries the pgvector extension — a standard Postgres image cannot serve as the vector store, the detail most Open WebUI stacks get wrong.

About Hosting

Open WebUI chats fine out of the box. It is document ingestion that breaks it, and every default below is a default that works on a laptop and fails in a container.

The default vector store crashes the worker on upload. Open WebUI defaults to ChromaDB on local SQLite, which its own docs call unsafe for multi-process access — there is a named failure mode for workers dying during upload. On Railway it also sits on an ephemeral container layer. Set VECTOR_DB=pgvector with PGVECTOR_DB_URL, on a Postgres image that has the extension.

RAG settings stop listening to environment variables after first boot. Open WebUI persists many settings into the database on first launch, and changing the variable afterwards does not replace the stored value. Get the vector store, extraction engine and embedding engine right before the first deploy, or change them in the admin interface — editing variables and redeploying looks like it should work and quietly does not.

Running the embedding model in-container is the wrong default. Out of the box Open WebUI loads SentenceTransformers in-process, downloading weights at runtime and taking the memory with it. Railway has no GPU, so this is CPU work in a small container: slow first ingest and a memory spike that reads as a crash. Set RAG_EMBEDDING_ENGINE=openai or ollama.

Uploaded documents are files, not rows. Postgres holds metadata and embeddings; the original PDFs and spreadsheets sit on disk under the app data directory. Any claim that all Open WebUI data lives in Postgres is wrong, and believing it means a redeploy that keeps every chat and loses every source file.

Default extraction is not good enough for real documents. Open WebUI's docs advise against the built-in extractor beyond plain text. Tika or Docling as a sidecar handles PDFs, Office formats and OCR properly — and TIKA_SERVER_VERSION must match the Tika you run, or extraction fails against an otherwise healthy server.

Typical cost: ~$20–30/month for Open WebUI, pgvector Postgres and the Tika sidecar at $10/GB/month RAM, $20/vCPU/month CPU and $0.15/GB/month volumes — Tika is a JVM and wants real memory. Open WebUI is free; embedding and inference bill to your provider.

How It Compares

	Open WebUI RAG	NotebookLM	ChatGPT file upload	Custom RAG stack
Document location	Your volume	Google	OpenAI	Yours

The honest edge: NotebookLM is better at grounded summarisation of a small corpus and costs nothing, so for a handful of public documents it wins outright. A purpose-built retrieval stack beats this on precision if you will tune a pipeline. Open WebUI sits in the middle and earns its place on one axis — documents that cannot leave your infrastructure, with chunking, top-k and embedding model adjustable, in a UI colleagues can use untaught.

Deploy in Under 5 Minutes

Click Deploy and pick a workspace. Open WebUI, pgvector Postgres and Tika come up wired, with WEBUI_SECRET_KEY generated and the RAG variables set.
Before opening the app, add your embedding provider key. These settings persist on first launch, so setting it now saves a trip through the admin UI.
Open the public domain, create the admin account, then set ENABLE_SIGNUP=false so nobody else can register.
Add a model under Connections — a provider key or any OpenAI-compatible base URL.
Upload a PDF to a knowledge collection and ask about something on page 20. A correct answer means extraction, embedding and retrieval all work.

Verify before you rely on it: redeploy, then ask that page-20 question again. A correct answer proves the embeddings are in Postgres and the source file is on the volume, not in a container layer that was just replaced.

Common Use Cases

Chat with internal documentation — contracts, runbooks, policies and specs that cannot go to a vendor.
Research over a private corpus — ingest a few hundred PDFs and query across them with citations back to source.

Configuration

Variable	Required	Description
`VECTOR_DB`	Required	`pgvector`. The default `chroma` uses local SQLite and is unsafe here.
`PGVECTOR_DB_URL`	Required	Postgres connection for the vector store. Needs the pgvector extension.
`RAG_EMBEDDING_ENGINE`	Required	`openai` or `ollama`. Leaving it unset runs the model in-container.
`CONTENT_EXTRACTION_ENGINE`	Required	`tika`, routing extraction to the sidecar.
`TIKA_SERVER_VERSION`	Required	Must match your Tika major version or extraction fails silently.
`WEBUI_SECRET_KEY`	Generated	Signs sessions. Changing it logs everyone out.
Storage volume	Pre-set	Holds uploaded source documents under the app data directory.

Set the RAG variables before the first boot. Open WebUI writes these into the database on first launch, and a later environment change will not override the stored value — you would have to change it in the admin interface instead.

A standard Postgres image will not work as the vector store. VECTOR_DB=pgvector requires the extension. Pointing it at plain Postgres fails at ingestion, not at startup, so the app looks healthy until someone uploads a file.

Dependencies for Open WebUI Hosting

Railway account — ~$20–30/month for the app, pgvector Postgres and Tika.
Bundled services — Postgres with pgvector for data and embeddings, Apache Tika for extraction, both wired by the template.
Volume — required, for uploaded source documents. Postgres holds embeddings and metadata, not the originals.
Provider keys — one for embeddings, one for chat. Same provider or different.

Deployment Dependencies

Implementation Details

Open WebUI runs the official image on a pinned tag, serving on 8080 behind the Railway domain. Postgres uses a pgvector-enabled image rather than the standard one, because VECTOR_DB=pgvector needs the extension present — the single substitution separating a RAG deployment that works from one that accepts uploads and dies. Tika runs as a private sidecar on 9998 with no public route, and TIKA_SERVER_VERSION matches it, since the two major versions expose different endpoints and a mismatch fails extraction while the server reports healthy.

Three things share a load a laptop install keeps in one process. Postgres holds application data and embeddings; the volume holds uploaded source files; the embedding model lives at your provider via RAG_EMBEDDING_ENGINE, because Railway has no GPU and a CPU-bound SentenceTransformers model in a small container is the quickest route to an out-of-memory kill during ingest.

For backups you need both halves. A Postgres dump captures chats, users and every embedding; the volume holds the documents those embeddings point at. Restore one without the other and you get citations with no documents, or documents with no index. Snapshot them together, and if the corpus outgrows a volume, switch to S3 rather than enlarging it.

Frequently Asked Questions

Why does document upload crash the app? The default ChromaDB vector store runs on local SQLite, which Open WebUI's docs say is unsafe for multi-process access. Switch to pgvector, as this template does.

I changed a RAG environment variable and nothing happened. Why? Open WebUI persists many settings to the database on first launch, after which the stored value wins over the environment. Change it in the admin interface instead.

Can I run embeddings locally to avoid API costs? Not well. Railway has no GPU, so the local model is CPU-bound in a small container — slow ingestion and a memory spike.

Why is retrieval returning the wrong passages? Usually chunk size, overlap or top-k rather than the model. All are adjustable in admin settings, and tuning them beats swapping models.

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 get the document stack configured the way its own docs recommend — pgvector instead of local Chroma, extraction through Tika with a matched version, embeddings at your provider rather than in-container, and source files on a volume that survives every redeploy.