Deploy and Host LightRAG Server on Railway

LightRAG is an open-source retrieval-augmented generation engine that builds a knowledge graph from your documents and combines graph traversal with vector search to answer questions. This template deploys the official LightRAG Server: a FastAPI backend, a WebUI for uploading documents and exploring the graph, a REST API, and an Ollama-compatible chat endpoint for clients such as Open WebUI.

About Hosting LightRAG Server

Hosting LightRAG Server is a single container. This template uses the official ghcr.io/hkuds/lightrag:v1.5.7 image with a Railway volume mounted at /data, where LightRAG keeps its knowledge graph, vector index, LLM cache, document status and uploaded files. PORT and the domain target are pinned to 9621 so Railway's healthcheck hits /health on the right port, and HOST is :: so other Railway services can reach the API over private networking. Authentication is enabled out of the box: a generated password for the admin WebUI login, a generated JWT secret and a generated API key. Bring your own LLM and embedding provider: the defaults point at OpenAI and one OPENAI_API_KEY is enough, or switch the bindings to Gemini, Azure, Bedrock, Ollama or any OpenAI-compatible gateway.

Common Use Cases

Knowledge base over documents: upload PDFs, DOCX, Markdown and text, then query with local, global, hybrid or naive retrieval
Graph RAG for agents: call /query and /query/data from other Railway services over the private network
Chat front end: connect Open WebUI or any Ollama client to the /api endpoints
Graph exploration: browse extracted entities and relations in the built-in graph viewer

Dependencies for LightRAG Server Hosting

Railway volume at /data (included)
LLM and embedding API key: optional at boot, required before indexing works. Set OPENAI_API_KEY, or LLM_BINDING_API_KEY and EMBEDDING_BINDING_API_KEY for other providers
No database service required: file-based storage is the upstream default. Postgres, Neo4j, Redis, Qdrant and Milvus are optional backends

Deployment Dependencies

Implementation Details

The image entrypoint fixes volume ownership and starts python -m lightrag.api.lightrag_server, which reads everything from the environment, so no custom start command is needed. Key variables:

PORT=9621
HOST=0.0.0.0
WORKING_DIR=/data/rag_storage
INPUT_DIR=/data/inputs
PROMPT_DIR=/data/prompts
AUTH_ACCOUNTS=admin:${{secret(32)}}
TOKEN_SECRET=${{secret(64)}}
LIGHTRAG_API_KEY=${{secret(32)}}
WHITELIST_PATHS=/health
LLM_BINDING=openai
LLM_MODEL=gpt-5.4-mini
EMBEDDING_BINDING=openai
EMBEDDING_MODEL=text-embedding-3-large
EMBEDDING_DIM=3072

First steps after deploy

Wait for /health to return {"status":"healthy"}.
Add OPENAI_API_KEY to the LightRAG service variables (the service redeploys automatically).
Open your Railway domain and log in as admin with the password found after the colon in the AUTH_ACCOUNTS variable.
Upload a document, wait for its status to become processed, then ask a question in the Retrieval tab.
For API access send the LIGHTRAG_API_KEY value as the X-API-Key header.

Do not change EMBEDDING_MODEL or EMBEDDING_DIM after the first document is indexed, and keep one replica: the file-based stores are single-process.

Why Deploy LightRAG Server 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 LightRAG Server on Railway, you get a pinned, health-checked graph RAG service with persistent storage, generated credentials, managed SSL, and private networking to the rest of your Railway project.