Deploy and Host LightRAG on Railway

LightRAG is an open-source, graph-enhanced RAG (retrieval-augmented generation) system from HKUDS — it builds a knowledge graph from your documents so queries can follow relationships between entities, not just match similar text. This template deploys it in a production configuration: LightRAG backed by PostgreSQL for all four storage roles, rather than the file-based defaults that LightRAG's own docs mark as development-only.

What This Template Deploys

Both services run on Railway's private network. PostgreSQL handles all four LightRAG storage types in one database, so there's no Neo4j, Milvus, or Redis to run separately.

About Hosting LightRAG

LightRAG needs four kinds of storage: KV (LLM response cache, chunks), vector (embeddings), graph (the knowledge graph itself), and doc-status (ingestion tracking). Out of the box it uses in-memory, file-persisted stores — NetworkX for the graph, NanoVectorDB for vectors — and LightRAG's documentation is explicit that these are for development and debugging, not production.

This template uses PostgreSQL for all four. A single Postgres instance with the pgvector and Apache AGE extensions handles KV, vector search, the knowledge graph, and doc-status together — production-grade storage that survives scale, backs up cleanly, and doesn't lose your graph to a corrupted file. That's the difference between a demo you can query and a knowledge base you can trust.

Two things to know when configuring it:

The LLM and the embedding model are configured separately. LLM_BINDING sets the chat model; the embedding model has its own EMBEDDING_BINDING and EMBEDDING_DIM. Both must be set, and the embedding dimension must match your model (1536 for OpenAI's text-embedding-3-small).

The graph backend requires Apache AGE, not plain Postgres. LightRAG's PGGraphStorage runs on the AGE extension, so this template uses a Postgres image with pgvector and AGE built in — a stock Postgres won't provide graph storage.

LightRAG delegates inference to external providers, so no GPU is needed. Memory scales with document volume and graph size; Railway's larger plans handle sizable collections comfortably.

Typical cost: ~$10–20/month on Railway for LightRAG and Postgres, plus your LLM and embedding provider usage.

How It Compares

Naive vector RAG matches similar chunks but can't follow entity relationships. Microsoft's GraphRAG is powerful but heavy to operate. LightRAG on Postgres gives you graph-enhanced retrieval with multi-hop reasoning, a Web UI, and production storage in one deployable stack.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — LightRAG and PostgreSQL build automatically (~3 minutes)
2. Set LLM_BINDING, LLM_BINDING_HOST, and LLM_BINDING_API_KEY for your chat model
3. Set EMBEDDING_BINDING, EMBEDDING_MODEL, and EMBEDDING_DIM for your embedding model
4. Confirm the LIGHTRAG_*_STORAGE variables point at PostgreSQL and set an AUTH_ACCOUNTS login
5. Open the Web UI, upload documents, and query once indexing completes

Swapping LLM providers later is three environment variables — no redeploy of the storage layer.

Common Use Cases

• Enterprise knowledge base — ingest internal docs and query in natural language, surfacing entity relationships across departments
• Legal and academic research — multi-hop reasoning across case law, papers, or filings where connections between entities matter
• Technical documentation search — answer questions that span multiple documents by following the graph, not just matching one chunk
• Research synthesis — connect findings across a large corpus where the relationships are the insight
• Private RAG for compliance — keep documents and the derived knowledge graph on infrastructure you control

Configuration

LLM and embedding models are separate. Set both bindings. EMBEDDING_DIM must match your embedding model exactly, or indexing fails with a dimension mismatch.

Graph storage needs Apache AGE. PGGraphStorage runs on the AGE Postgres extension. This template uses a pgvector + AGE image; a stock Postgres cannot provide the knowledge graph.

Dependencies for LightRAG Hosting

• Railway account — expect ~$10–20/month for LightRAG and Postgres
• An LLM provider API key (OpenAI, Azure, or any OpenAI-compatible endpoint)
• An embedding provider (often the same as the LLM provider)
• Optional: Cohere or Jina API key for reranking to improve result quality

Deployment Dependencies

• LightRAG GitHub Repository
• LightRAG API Server Documentation
• Storage Backends Reference
• Railway Volumes Documentation

Implementation Details

The template runs ghcr.io/hkuds/lightrag on port 9621 against a PostgreSQL service built with the pgvector and Apache AGE extensions. All four LightRAG storage roles are pointed at Postgres through the LIGHTRAG_*_STORAGE variables, so KV, vector, graph, and doc-status data live in one database rather than in the in-memory file stores LightRAG uses by default.

LLM and embedding configuration are independent: LLM_BINDING selects the chat model while EMBEDDING_BINDING and EMBEDDING_DIM configure embeddings separately, and the dimension must match the chosen embedding model. Because LightRAG supports any OpenAI-compatible endpoint, switching providers is a matter of changing the binding, host, and key — the storage layer is unaffected.

Web UI and API authentication are configured through AUTH_ACCOUNTS and TOKEN_SECRET. Inference is delegated to external providers, so the service runs on CPU with no GPU; memory use scales with corpus size and the resulting knowledge graph.

Frequently Asked Questions

Why PostgreSQL instead of the file-based default? LightRAG's default NetworkX and NanoVectorDB stores are documented as development-only. This template uses PostgreSQL for all four storage roles, which is production-grade — it scales, backs up, and won't lose your graph to a corrupted file.

Why does the graph need Apache AGE? LightRAG's PGGraphStorage is built on the AGE Postgres extension. A stock Postgres image can't provide graph storage, so this template uses a pgvector + AGE build.

Do I need a GPU? No. LightRAG delegates inference to external LLM and embedding providers, so it runs on CPU. Memory scales with document volume and graph size.

Which LLM providers work? OpenAI, Azure OpenAI, Ollama, Gemini, AWS Bedrock, and any OpenAI-compatible endpoint. Change LLM_BINDING, its host, and key to switch without touching storage.

Why are LLM and embedding configured separately? They're different models. The embedding model and its EMBEDDING_DIM must be set independently, and the dimension must match or indexing fails.

How is this different from normal vector RAG? Vector RAG retrieves similar chunks. LightRAG also builds a knowledge graph of entities and relationships, enabling multi-hop reasoning across documents.

Does my data persist? Yes. All storage lives in the Railway PostgreSQL service — documents, vectors, and graph — and persists across redeploys. Back it up on a schedule.

Why Deploy LightRAG 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 on Railway you get graph-enhanced RAG in a production shape — PostgreSQL handling all four storage roles with pgvector and Apache AGE, a Web UI, 20+ LLM providers, and automatic HTTPS. Multi-hop reasoning over your own documents, on storage you can actually run in production, on infrastructure you own.