--- title: "Deploy Portkey" description: "A powerful AI gateway for routing, guardrails, fallbacks, and 200+ LLMs." category: "AI/ML" url: https://railway.com/deploy/portkey --- # Deploy Portkey A powerful AI gateway for routing, guardrails, fallbacks, and 200+ LLMs. **[Deploy Portkey on Railway](https://railway.com/template/portkey)** - **Creator:** INF Labs - **Category:** AI/ML ## Template content ### Redis https://cdn.sanity.io/images/sy1jschh/production/0ce0bfdcfbdbf69662b1116671f97c2dd788b655-157x157.svg - **Image:** redis:8.2 - **Start command:** `/bin/sh -c "rm -rf $RAILWAY_VOLUME_MOUNT_PATH/lost+found/ && exec docker-entrypoint.sh redis-server --requirepass $REDIS_PASSWORD --save 60 1 --dir $RAILWAY_VOLUME_MOUNT_PATH"` ### Portkeyai - **Image:** portkeyai/gateway:latest - **Public domain:** Yes ## Documentation # Deploy and Host Portkey AI Gateway on Railway Portkey AI Gateway is an open-source AI gateway designed to route, control, and optimize requests across multiple LLM providers through a unified API layer. This Railway template deploys **Portkey AI Gateway with Redis**, giving you a lightweight, production-oriented gateway stack with shared caching over Railway private networking. ## About Hosting Portkey AI Gateway This template deploys Portkey AI Gateway as the public-facing API layer and Redis as its internal cache backend. Portkey handles LLM request routing, retries, fallbacks, guardrails, provider abstraction, and gateway-level policies, while Redis provides a shared cache store that can be reused across gateway restarts or multiple gateway replicas. The stack communicates internally through Railway's private network, so Redis does not need to be publicly exposed. ## Included Services * **Portkey AI Gateway** — Public AI gateway and OpenAI-compatible API layer * **Redis** — Shared cache backend for gateway requests * **Railway Private Networking** — Internal communication between Portkey and Redis ## Common Use Cases * Route requests across multiple LLM providers * Build a unified API endpoint for AI applications * Add fallback logic between different models or providers * Centralize AI provider configuration * Apply gateway-level guardrails and policies * Cache repeated LLM requests using Redis * Reduce duplicate provider calls * Build an OpenAI-compatible AI gateway * Add an abstraction layer between applications and LLM providers * Scale gateway instances while sharing a common Redis cache ## Dependencies for Portkey AI Gateway Hosting This template includes: * Portkey AI Gateway * Redis PostgreSQL is not required for the standard open-source gateway deployment. ## Portkey AI Gateway Portkey runs as the public service in this template. The gateway listens on: ```text 8787 ``` Its API is available under: ```text /v1 ``` The deployment also exposes the Portkey web interface under: ```text /public/ ``` A typical deployed endpoint will look like: ```text https://your-portkey-domain.up.railway.app/v1 ``` ## Redis Cache Redis runs as an internal service and is used as Portkey's shared cache backend. Portkey connects to Redis using Railway service references and private networking. The Redis service does not require a public domain. This improves the deployment by keeping cache traffic inside Railway's private network while allowing the gateway itself to remain publicly accessible. ## Important Environment Variables ### Portkey AI Gateway `PORT` Defines the HTTP port used by the gateway. `CACHE_STORE` Configured as `redis` so Portkey uses Redis as its cache backend. `REDIS_URL` References the Redis connection URL exposed by the Redis service. `LOG_LEVEL` Controls gateway logging verbosity. `PORTKEY_CLIENT_AUTH` Can be used as an additional gateway authentication secret where supported by the deployed Portkey version. Treat this value as sensitive and do not expose it in frontend applications. ### Redis Redis is configured with: * Private Railway hostname * Port `6379` * Default Redis user * Automatically generated password * Internal Redis connection URL The Redis URL is consumed directly by the Portkey service through a Railway service reference. ## Networking The intended architecture is: ```text Internet │ ▼ Railway HTTPS │ ▼ Portkey AI Gateway :8787 │ │ Railway Private Network ▼ Redis :6379 ``` Only the Portkey service needs a public domain. Redis should remain private. ## Persistent Storage Redis persistence is optional for this template. If Redis is used only as a cache, losing cached entries after a Redis restart does not prevent Portkey from functioning. The cache will simply be rebuilt as new requests are processed. If long-lived Redis persistence is required, a Railway Volume can be added to the Redis service. ## After Deployment 1. Wait until both Portkey AI Gateway and Redis are running. 2. Generate a public domain for the Portkey service on port `8787`. 3. Keep the Redis service private. 4. Verify the gateway health endpoint. 5. Open the Portkey interface under `/public/`. 6. Configure your preferred LLM provider credentials or gateway configuration. 7. Point your AI application to the Portkey `/v1` endpoint. 8. Verify that requests are being routed successfully through the gateway. 9. Confirm Redis connectivity from the Portkey logs if cache functionality is enabled. ## Security Notice Do not expose Redis publicly. Keep all provider API keys, Redis credentials, and gateway authentication secrets in Railway environment variables. For production workloads: * Use restricted provider credentials where possible * Avoid exposing administrative secrets to frontend applications * Protect public gateway endpoints appropriately * Rotate compromised credentials immediately * Keep Redis accessible only through Railway private networking ## Portkey vs Alternatives | Feature | Portkey | LiteLLM | OpenRouter-style Gateway | Direct Provider APIs | | ------------------------- | ------: | ------: | -----------------------: | -------------------: | | Unified LLM gateway | ✅ | ✅ | ✅ | ❌ | | OpenAI-compatible API | ✅ | ✅ | ✅ | ⚠️ | | Multi-provider routing | ✅ | ✅ | ✅ | ❌ | | Fallbacks | ✅ | ✅ | ✅ | ❌ | | Guardrails | ✅ | ✅ | ⚠️ | ❌ | | Shared Redis cache | ✅ | ✅ | Depends | ❌ | | Self-hosted | ✅ | ✅ | Depends | ❌ | | Provider abstraction | ✅ | ✅ | ✅ | ❌ | | Centralized gateway layer | ✅ | ✅ | ✅ | ❌ | Portkey is a strong fit when you want a dedicated AI gateway layer between your applications and multiple LLM providers without coupling each application directly to individual provider APIs. ## Why Deploy Portkey AI Gateway 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. Deploying Portkey AI Gateway on Railway provides: * Automatic HTTPS networking * Private communication with Redis * Simple secret management * Easy redeployments and upgrades * Integrated logs * Shared Redis caching * A lightweight two-service architecture * No PostgreSQL dependency for the standard gateway deployment This template provides a straightforward way to self-host Portkey AI Gateway with Redis while keeping the infrastructure simple, secure, and production-oriented. ## Similar templates - [Chat Chat](https://railway.com/deploy/-WWW5r) — Chat Chat, your own unified chat and search to AI platform. - [stella](https://railway.com/deploy/stella) — Self-host stella with web, API, Postgres, Redis, and object storage. - [Hermes Agent | OpenClaw Alternative with Dashboard](https://railway.com/deploy/hermes-agent-or-openclaw-alternative-wit) — Self-Hosted Hermes AI Agent for Telegram, Discord & Slack Open this page in a browser: https://railway.com/deploy/portkey