Deploy LiteLLM Proxy
LLM proxy for Claude, GPT & Gemini with keys, budgets & caching
Just deployed
/var/lib/postgresql/data
Redis
Just deployed
/data
railway-litellm-template
Just deployed
Deploy and Host LiteLLM Proxy on Railway
LiteLLM Proxy is an open-source gateway that puts one OpenAI-compatible endpoint in front of Anthropic, OpenAI, Google and 100+ other LLM providers. Point any OpenAI SDK at it and switch models by name, without changing client code. This template deploys the proxy with Postgres for key management and spend tracking, and Redis for response caching.
About Hosting LiteLLM Proxy
Running LiteLLM in production means more than starting a container: it needs a Postgres database for virtual keys and spend logs, database migrations applied on every version bump, and ideally Redis so repeated prompts are not paid for twice. This template wires all three services together, generates the master key for you, applies Prisma migrations automatically on first boot, and exposes a healthcheck so deploys fail loudly rather than silently. The LiteLLM image is pinned by digest, so every deploy gets the same tested version instead of whatever upstream released today.
Why Deploy LiteLLM Proxy?
Handing raw provider keys to every app and teammate is hard to undo and impossible to audit. With this proxy you issue virtual keys scoped to specific models, each with its own budget, and revoke them individually. Every request is written to Postgres with cost attribution, so spend is visible per key, per model and per team rather than as one opaque monthly invoice. Redis caching returns identical prompts without a second provider call. Switching between Claude, GPT and Gemini becomes a model-name change instead of a rewrite, which also makes it easy to fall back to another provider during an outage.
Common Use Cases
- Give a team shared access to Claude, GPT and Gemini through one endpoint, with per-person keys and budgets instead of shared provider credentials.
- Track and cap AI spend per project or client, using the usage dashboard and per-key budget limits.
- Put a single gateway in front of your apps so you can change providers or models centrally, without redeploying every client.
- Cut costs on repetitive workloads — classification, extraction, evaluation runs — where the same prompt is sent repeatedly and can be served from cache.
Dependencies for LiteLLM Proxy Hosting
- A Postgres database for virtual keys, spend logs and runtime model configuration (included in this template).
- Redis for response caching (included; the proxy also starts without it, with caching disabled).
- At least one provider API key —
ANTHROPIC_API_KEY,OPENAI_API_KEYorGEMINI_API_KEY— set after deploying. Models whose key is missing are simply not served.
Deployment Dependencies
- LiteLLM documentation
- LiteLLM GitHub repository
- Provider configuration reference
- Get provider keys from Anthropic Console, OpenAI Platform or Google AI Studio
Implementation Details
The proxy binds to the port Railway provides and reports health at /health/liveliness. Railway's REDIS_URL is split into the host, port and password fields LiteLLM expects, so caching works with or without a Redis password. Models are defined in config.yaml and can also be added at runtime through the admin UI, where they persist in Postgres.
The admin UI is at /ui — log in with username admin and your LITELLM_MASTER_KEY.
Template Content
Redis
redis:8.2railway-litellm-template
officeOptibiz/railway-litellm-template