Deploy LightRAG

Deploy and Host LightRAG on Railway

For a document knowledge graph with vector retrieval on Railway, use LightRAG Pro Stack. It combines the LightRAG Web UI and authenticated API with PostgreSQL and pgvector, using PostgreSQL table-backed graph storage. Deploy without a provider key and configure it in the protected /setup screen, or supply Railway variables. Document processing still needs working language-model and embedding providers; no GPU or model credits are bundled.

LightRAG Railway Template: Quick Answers

How do I deploy LightRAG or Light RAG on Railway?

Use this LightRAG Railway template to deploy with or without a model provider key. If you leave the key empty, the protected /setup screen lets you configure it after deployment. The template provisions LightRAG with its Web UI and authenticated API, plus private Railway PostgreSQL 18 with pgvector. Log in as admin with the generated ADMIN_PASSWORD from the LightRAG service variables.

What does this LightRAG Pro Stack add?

The knowledge graph, vector embeddings, document records and processing status all use PostgreSQL storage. It uses LightRAG's native PGTableGraphStorage, so an additional Neo4j or graph database service is not required. The two-service deployment includes persistent volumes, private database networking, generated administrator/API credentials and a setup extension on a version-pinned official LightRAG base image. This is a PostgreSQL-backed configuration rather than the upstream file-storage defaults.

Can I connect LightRAG to Open WebUI?

Yes, through LightRAG's Ollama-compatible routes, if the client connection supports the custom X-API-Key header. LightRAG supplies retrieval and graph-backed document queries; Open WebUI supplies the chat interface. The LightRAG API key and your model provider key are separate credentials.

Do documents survive a LightRAG restart?

Restarting or redeploying with the existing volumes and secrets preserves uploaded files and PostgreSQL data. Keep the volumes and signing secret, and back up both the database and uploaded files before upgrades. API model usage and Railway hosting are billed separately.

About Hosting LightRAG

This template runs LightRAG v1.5.7 and Railway PostgreSQL 18 with pgvector using a small setup extension built on the official LightRAG image pinned by digest, plus Railway’s native PostgreSQL SSL image. PostgreSQL stores the documents, processing status, embeddings, entities and relationships. Native PGTableGraphStorage keeps the knowledge graph in PostgreSQL as well.

There are two services and two persistent volumes. The PostgreSQL service includes Railway’s standard PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE and DATABASE_URL variables for the Data and Connect panels. The database is reachable over Railway's private network; only LightRAG receives a public HTTPS domain. An administrator password, API key and token signing secret are generated separately for every deployment.

Get started

1. Deploy immediately with no model key, or enter LLM_BINDING_API_KEY in Railway if you already have it. The key is optional at deployment.
2. Wait for both services to start, then open the LightRAG public URL.
3. If no key was provided, sign into the protected setup screen as admin using the generated ADMIN_PASSWORD from Railway. Configure chat and embeddings, save, and wait for LightRAG to restart. Then sign into the native LightRAG interface with the same administrator credentials. The setup screen remains available at /setup.
4. Upload a text document or a PDF containing selectable text. Wait until its status is Processed.
5. Open Retrieval and ask a question about the document. You can also explore its entities and relationships in the graph view.

You can change ADMIN_USERNAME and ADMIN_PASSWORD in Railway variables, then redeploy LightRAG. The API key is a separate credential; it is not your administrator password or your model provider key.

Dependencies for LightRAG Hosting

• LightRAG API server and bundled Web UI, version 1.5.7.
• PostgreSQL 18 with the pgvector extension.
• An OpenAI account with API access, or another compatible model provider configured in the variables below.

Deployment Dependencies

• Railway setup extension source
• LightRAG source
• LightRAG API server documentation
• LightRAG Docker deployment guide
• pgvector

Configuration

For a different provider, update the LLM binding, API host and model, plus the embedding binding, host, model, dimension and key as needed. Chat and embedding providers can be configured separately. Choose an embedding model before importing data; changing its model or dimension later requires rebuilding the affected indexes.

Model inference uses the configured provider. Provider charges are separate from Railway resource usage. Native document parsing is enabled; scanned PDF OCR and image understanding require additional configuration and are not included in this default setup.

Provider Setup: Railway Variables or Product UI

Both configuration paths are supported. A nonempty Railway chat key makes the Railway chat key, model and host authoritative; the same rule applies independently to embedding credentials. If a group has no Railway key, the protected /setup screen manages that group. Saved keys are never returned to the browser. They are encrypted on the /app/data volume using the stable TOKEN_SECRET; keep that secret with your volume backups.

The setup screen supports OpenAI and OpenAI-compatible endpoints. To use Claude for chat, configure an OpenAI-compatible gateway such as LiteLLM, then supply its URL, model alias and proxy key. Claude does not replace an embedding model: configure a compatible embedding endpoint and key separately. No gateway or external model credits are bundled. Other native LightRAG bindings can still be configured through Railway variables.

After configuration, changing the embedding model, dimension or endpoint requires a planned index migration; the setup screen protects these settings once activated. Key rotation for the same provider remains available. Saving settings gracefully restarts the application. An unconfigured /health reports setup_required: the configuration screen is ready, but document processing still needs working providers.

Persistent Storage and Restarts

The PostgreSQL data directory is /var/lib/postgresql/data/pgdata. LightRAG uses PGKVStorage, PGVectorStorage, PGTableGraphStorage and PGDocStatusStorage. It creates the required tables and pgvector extension automatically on the included database.

Restarting or redeploying these services preserves their attached volumes. Deleting a volume deletes its contents. Back up both PostgreSQL and the uploaded files before major upgrades. Keep the database on PostgreSQL 18 unless you carry out a database migration. The base LightRAG image is pinned; review setup extension and upstream changes before upgrading.

The public /health endpoint is used for Railway health checks. Document, query and Ollama-compatible API routes require authentication. Deployment connection retries allow LightRAG to wait for PostgreSQL during startup.

API and Open WebUI Connection

Use the LightRAG public HTTPS URL as the base URL. Send X-API-Key: YOUR_LIGHTRAG_API_KEY for API calls, or use the bearer token returned by /login.

LightRAG also provides Ollama-compatible endpoints under /api, including /api/tags and /api/chat. In an Open WebUI connection that supports custom headers, use the LightRAG URL as an Ollama endpoint and add the X-API-Key header. A raw API key sent as a bearer token does not replace this header. The generated API key is available in the LightRAG service variables.

LightRAG is distributed under the MIT license. Review upstream documentation for additional providers, parsers and backup policies.

Other deployment choices from this publisher

• For a document-ingestion platform with Infinity and MinIO: RAGFlow
• For a separate multi-provider chat workspace with LiteLLM: Open WebUI