LiteLLM multi-region deployment

When does a LiteLLM multi-region deployment make sense?

A multi-region LiteLLM deployment makes sense when users in more than one region depend on the same self-hosted gateway and the platform team must decide which goal it is paying for: lower latency for nearby users, or continued service when one region fails. Request volume alone rarely settles the question. The same topology can run in either mode, so the decision depends on what users in each region experience today, how long a regional outage can be tolerated, and whether the team can operate a second region at all. If one region serves most users and a single well-run deployment meets the recovery target, a second region adds cost and failure modes without a clear gain.

LiteLLM's multi-region documentation sets three topology rules, and each one shapes the design. First, every region's instances point DATABASE_URL at one shared PostgreSQL database in the primary region, so that database becomes the common write point for the whole gateway, and remote instances pay the network distance to reach it. Second, each region runs its own Redis. The production guide ties Redis to shared rate limits, router state and cache once more than one proxy instance runs. Third, all regions run in the same cloud provider. Confirm in the docs which Redis state stays regional and how a regional Redis outage affects limits and routing, because that answer drives the failover plan.

Active-active suits a case where latency to a nearby region is the main goal. Clients are routed to the nearest region, and every region serves live traffic. Active-passive suits a recovery goal. The second region stays idle behind a DNS failover record and takes traffic only when the first region fails. Both modes use the same topology, so the choice mostly changes how DNS, health checks and standby capacity are run. Before choosing, write down the latency target for each user group, the outage the business must survive, and who will switch DNS and verify the standby region during an incident. Then test whether the standby can take real traffic on short notice.

The primary region is the hard case in either mode. The shared PostgreSQL database holds virtual keys, budgets and spend state that every region depends on, so losing that region can stop writes for the whole gateway even when other regions still answer requests. LiteLLM can send read-only queries to a replica set named in DATABASE_URL_READ_REPLICA while writes go to the primary database, which may reduce load on the primary and help remote reads. Confirm what the read replica can serve, how replication lag affects key and budget checks, and whether the docs describe promoting a database in another region. The topology rules do not answer those questions on their own.

Two conditions apply to every version of this design. All regions must sit in the same cloud provider, so this page does not cover cross-cloud designs. The deployment also needs one Enterprise license that covers every region, with all instances sharing the same LITELLM_LICENSE, LITELLM_MASTER_KEY and LITELLM_SALT_KEY. Confirm the license terms for your region count with LiteLLM before you commit. If those conditions and your recovery target are settled, the next decision is the topology itself, covered in the sections that follow.

Active-active or active-passive: which topology fits your recovery goals

This table compares active-active and active-passive LiteLLM topologies across client routing, database and Redis behavior during failure, router strategy, idle capacity and operations. Read each row against your recovery objectives and your team's capacity to run a failover drill. The main takeaway is that both topologies keep one shared PostgreSQL database in the primary region, so the choice mainly changes traffic handling and recovery steps around that database.

Consideration	Active-active	Active-passive
Client routing	Clients reach the nearest region, and every region serves live traffic at the same time.	Clients use the primary region until a DNS failover record sends them to the idle second region.
Shared PostgreSQL if the primary region fails	Every region writes to the database in the primary region, so its loss affects all regions. Confirm your database recovery path.	The standby region still depends on the primary region's database, so database recovery must happen before failover helps.
Regional Redis during failover	Each region keeps its own Redis for rate limits, router state and cache, so counters remain regional.	The standby region starts with the Redis state it holds. Test how stale or empty state affects limits and cooldowns.
Router strategy choices	Simple-shuffle is recommended. Latency-based can favor the closest deployment. Usage-based, least-busy and cost-based weigh live counters or cost settings.	Priority ordering can hold the standby deployment back until failover. Other strategies have little traffic to act on while it sits idle.
Cost of idle capacity	Little capacity sits idle, but each region still needs its own compute and Redis.	The second region runs idle compute, Redis and network capacity continuously. Ask for these costs listed separately in any quote.
Operational complexity	Configuration drift between regions is the main risk, so one deployment template and synchronized secrets matter.	Failover drills, DNS record management and TTL testing are recurring work that your team must own.
Shared license and keys	One Enterprise license covers every region. All instances need the same LITELLM_LICENSE, LITELLM_MASTER_KEY and LITELLM_SALT_KEY.	One Enterprise license covers every region. All instances need the same LITELLM_LICENSE, LITELLM_MASTER_KEY and LITELLM_SALT_KEY.
Read replica use	Read-only queries can go to a replica set, while writes still go to the primary database.	Confirm whether a replica set helps the standby region during an outage, since writes still go to the primary database.

What carries across regions: licenses, master keys, salt keys and virtual keys

One LiteLLM Enterprise license covers every region in a multi-region deployment, but only if every instance presents the same value. Each regional instance must share the same LITELLM_LICENSE, LITELLM_MASTER_KEY and LITELLM_SALT_KEY. Treat these three values as a single identity for the gateway: they are set once in your secret manager and injected into every regional deployment from that source. If one region is deployed from a stale copy of any of them, that region will not behave like the others, and the mismatch is easy to miss during a regional failover test because the proxy may still answer requests.

Virtual keys, budgets, teams and users live in the PostgreSQL database that every region reaches through DATABASE_URL, so they are visible everywhere by design. A key created through a proxy in one region can be used through a proxy in another, and a spend limit enforced in one region counts against the same budget as traffic from another. This is the behavior you want for a shared budget, but it also means a bad configuration change made in one region changes access in all of them. Plan key administration as a global activity with a named owner, and confirm in a test environment how a budget update made in one region appears in the others, including any delay caused by batched spend updates.

The salt key is different from the master key and must never change once models are added. LiteLLM uses it to encrypt provider credentials stored in the database, so changing it after models have been saved makes those stored credentials unreadable. Rotating LITELLM_MASTER_KEY is a separate operation that does not require re-encrypting stored models. Before you go live, record the salt key in your secret manager with restricted access, confirm that every region loads the identical value, and write a change rule that blocks edits to it. If you ever need a new salt key, plan that as a migration with the vendor's guidance, not as a configuration tweak.

Several features that some regions may depend on sit behind the Enterprise license. The LiteLLM documentation states that SSO is free for up to 5 users from v1.76.0, and that SSO beyond that limit, audit logs, organization and team RBAC, and IP allowlisting require Enterprise. Confirm with LiteLLM which features your deployment needs in every region, because a feature enabled in one region but unlicensed in another will create inconsistent behavior. Also confirm that the open source license terms allow your planned topology. The repository's LICENSE file places content under the enterprise/ directory under a separate license, and the rest under MIT. Read both, then check the enterprise documentation for any terms that apply to running multiple instances under one license.

Ask your LiteLLM contact to confirm three points in writing before you build: that one Enterprise license key is valid across all regional instances in your planned topology, which features are gated in your chosen version, and how license validation behaves if a region cannot reach the license service. Record the answers alongside your key inventory so that the people running failover know which values must match and which features they can rely on in the standby region.

Setup sequence for a multi-region LiteLLM gateway

This sequence takes a LiteLLM gateway from one region to several regions of a single cloud provider, with a shared PostgreSQL database, regional Redis and identical keys in each region. Each step closes with a check you can run, so the team confirms each layer works before the next one depends on it. The result is a gateway that serves clients from more than one region and has a tested path for losing one.

Confirm the cloud provider and primary region
Your team and DeployOpen agree on one cloud provider and one primary region before any infrastructure is created, because the LiteLLM multi-region topology requires every region to run in the same cloud provider. The primary region hosts the shared PostgreSQL database that all regional instances write to. Confirm which regions you need for latency and which obligations, such as data residency rules, limit where prompts, logs and keys may be stored. Done when the provider, the region list and the primary region are recorded in a written architecture decision and approved by the platform owner.
Provision the shared PostgreSQL database
Create one PostgreSQL database in the primary region that every proxy instance will reach through DATABASE_URL. LiteLLM names PostgreSQL as its primary supported database, and virtual keys, budgets and spend records depend on it. Define the backup schedule, point-in-time recovery settings and the owner of restores before go-live, and note that an outage in the primary region also interrupts writes from every region. Done when a test restore completes into a separate instance and a virtual key created before the restore is readable after it.
Provision Redis 7.0 or newer in each region
Deploy one Redis instance in every region and confirm that each runs version 7.0 or newer. LiteLLM requires Redis once more than one proxy instance runs, since shared rate limits, router state and cache need a common store, and the multi-region rules place one Redis in each region. Enable authentication and restrict network access to the proxy subnets. Done when a client in each region writes and reads a test key against its local Redis and the reported server version is 7.0 or newer.
Store the shared keys in a secret manager
Place LITELLM_MASTER_KEY, LITELLM_LICENSE and LITELLM_SALT_KEY in your secret manager, then deliver identical values to every region. The master key must start with sk-, and all instances must share the same license, master key and salt key. Treat the salt key as permanent once models are added, because it protects stored provider credentials. Keep the admin credential separate from the salt key and record who can read each value. Done when every regional instance starts from the same secret versions and a request authenticated with the master key succeeds in each region.
Deploy one Uvicorn worker per pod
Run one Uvicorn worker per pod and scale by adding pods, which is the approach LiteLLM recommends on Kubernetes. Start each worker with the baseline LiteLLM suggests, 1 vCPU and 4 GiB of memory, and set replica counts from load tests in your own environment. Outside Kubernetes, run the equivalent number of proxy processes behind your load balancer and confirm your deployment tooling supports it. Done when the proxy health check responds from every pod and a load test shows requests spread across pods in each region.
Configure DATABASE_URL and Redis per region
Set DATABASE_URL in each region to the shared primary PostgreSQL database, and point the Redis settings at that region's local Redis. Keep these connection values in per-region configuration while the license, master key and salt key stay identical. Confirm that network routes and firewall rules let each region reach the primary database and its own cache. Done when a virtual key created through a proxy in one region can be used through a proxy in another region, and a Redis-backed rate limit test rejects requests once the configured limit is exceeded.
Add the read replica if needed
If reporting or dashboard queries will load the primary database, add a PostgreSQL replica and set DATABASE_URL_READ_REPLICA to it. LiteLLM sends read-only queries to the replica while writes continue to go to the primary database, so the primary remains the write dependency. Confirm the replication lag is acceptable before relying on the replica for any check that depends on recent spend or key data. Done when database metrics or logs show read queries reaching the replica and a newly written spend record appears there within the lag you accepted.
Set routing topology and run a failover drill
Choose active-active routing, which sends clients to the nearest region, or active-passive, where an idle second region sits behind a DNS failover record. Configure the DNS records or global routing policy for the chosen model. Then run a failover drill that takes the primary region's proxies out of service and checks that traffic and virtual key use continue. For active-passive, confirm the standby can reach the primary database or document the promotion steps. Done when the drill results, observed recovery time and any gaps are recorded and accepted by the service owner.

Security risks of a shared database across regions

A LiteLLM multi-region deployment points every region at one shared PostgreSQL database and keeps the same license and keys everywhere. That design creates exposures on the network, in key handling, in regional Redis, on the admin surface and in logs. Each card below names one exposure and the check to run before production.

Cross-region traffic to the primary database

Every region's proxy instances write to one PostgreSQL database in the primary region, so virtual key lookups, budget checks and spend writes cross region boundaries on every request path. Confirm that the connection uses TLS end to end, that the database accepts connections only from the proxy subnets, and that the routes between regions are private links or encrypted tunnels rather than public endpoints.

Shared master and salt keys

All instances must share LITELLM_MASTER_KEY and LITELLM_SALT_KEY, so one leaked value exposes every region. The production guide recommends keeping the master key in a secret manager. Confirm who can read each key, how the values reach each region's runtime, and how a rotation is rolled out to every region at once. The salt key must never change once models are stored.

Blast radius of a compromised regional proxy

A proxy instance holds the database connection string, the shared keys and the provider credentials it needs to call models. If one region is compromised, an attacker may reach the shared database from inside the trusted network path. Check that each proxy runs with a least-privilege database role, that provider keys are scoped per region where the provider allows it, and that you can revoke a region's access without stopping the others.

Regional Redis holding router state

Each region runs its own Redis, which stores shared rate limits, router state and cache data. The production guide requires Redis 7.0 or newer once more than one instance runs. Confirm that Redis is not reachable from outside the proxy network, that authentication and TLS are enabled, and that cached responses or router state cannot leak across tenants or teams that should stay separate.

IP allowlisting for the admin surface

The admin UI and management endpoints are reachable in every region, so each regional load balancer widens the surface that must be controlled. Enterprise IP allowlisting is one control to evaluate, along with SSO and network rules at the load balancer. Confirm which paths are exposed publicly, which administrators can reach them from which networks, and whether the allowlist is enforced at the edge and in the application.

Logs and spend records spanning regions

Spend logs, audit trails and request logs from every region land in one database and one log pipeline, which raises the value of that data to an attacker and may bring it under the data residency rules of more than one jurisdiction. Confirm where each record is stored, who can query it, how long it is retained, and whether prompts or responses are written to the shared store at all.

How failover behaves when the primary region fails

A DNS failover record moves new client connections from the primary region's LiteLLM endpoint to the idle region's endpoint once its health check fails. It does nothing for the data layer. In the multi-region topology, every region's instances point DATABASE_URL at one shared PostgreSQL database in the primary region, so the idle region's proxies can start and answer health checks while still depending on a database that may be the component that failed. Virtual keys, budgets, team settings and spend tracking are all read from and written to that database. Confirm which health check triggers the switch, and measure in your own environment how long clients and resolvers keep the old answer after the record changes.

The routing documentation describes retries, cooldowns after repeated failures to a deployment, and priority ordering for failover between deployments. These mechanisms work between model deployments the proxy can reach. They do not hand off a request that a proxy in the failed region was already serving, so clients must treat a dropped connection as a failure and retry it, and the retry must be safe for their application to repeat. Cooldown state and the shared rate limit and router counters live in each region's own Redis, so the idle region starts with its own state. Confirm with the routing documentation what each region's Redis holds at failover, and whether session affinity keeps a conversation on a region after the switch.

A read replica does not remove the dependency on the primary. LiteLLM can send read-only queries to a replica set configured in DATABASE_URL_READ_REPLICA, but writes still go to the primary database. Key creation, budget changes and spend updates are writes, and at scale LiteLLM batches spend updates to the database every 60 seconds, so updates queued during an outage need an explicit plan. The PostgreSQL high availability design, backups and point-in-time recovery must be specified separately and listed as a dependency of this deployment. Name the database owner, the standby and promotion process, and the restore procedure before the DNS design is considered complete.

Recovery time and recovery point targets must be set by the client from its own business impact and regulatory obligations. The documentation does not supply them, and a target copied from a vendor page or an example is not a commitment your organization can meet. Once targets exist, test them with a drill: take the primary region out of service in a planned window, let DNS move traffic, confirm that keys, budgets and logging work from the idle region, record how long each step takes and which requests failed, then plan and rehearse failback, which must reconcile database writes and regional Redis state. Repeat the drill after each significant change to the topology or database.

Limits to confirm in your environment before you commit

The LiteLLM multi-region topology is simple on paper, but six limits depend on your release line, network, cloud account and data rules. Each card names the check and who should confirm it: vendor documentation, your cloud team or your compliance lead. Settle these before you accept a timeline or a fixed-scope quote.

Release line support

Confirm that the multi-region topology is supported on the release line you plan to run. The LiteLLM releases page lists v1.105.1, published October 14, 2026, and the enterprise documentation describes support for the four most recent stable minor versions. Ask the vendor in writing whether your chosen minor version supports this topology under your Enterprise license terms, and plan your upgrade window against that support horizon.

DNS failover timing

Failover speed depends on DNS as much as on the proxies. In the active-passive pattern, clients reach the idle region through a DNS failover record, so the record TTL, the health check interval and the failure threshold together set how long traffic stays on a failed region. Ask your cloud team to write those values down, compare them with your recovery target, and test a failover in a non-production setup before you rely on it.

Cross-region write latency

Every region writes to one PostgreSQL database in the primary region, so each spend log write crosses the link between regions. The LiteLLM production guide suggests batching spend updates to the database every 60 seconds at scale, which reduces write pressure but leaves the distance between regions in place. Ask your cloud team to measure round-trip time from each secondary region to the primary database at expected write volume, and confirm with the vendor how spend writes affect request latency in your version.

Read replica query behavior

LiteLLM can send read-only queries to a replica set configured in DATABASE_URL_READ_REPLICA, while writes continue to go to the primary database. The benefit depends on which queries your deployment runs and how far the replica lags behind the primary. Ask the vendor documentation which query paths use the replica, then test that a key or budget change made in one region is visible in the places your processes depend on.

Regional service limits

Each region draws on the cloud provider's regional quotas for compute, load balancing, database connections, Redis capacity and network egress. A second region sized only on paper may fail to scale during an incident. Ask your cloud team to confirm the current limits for each chosen region, request increases before go-live, and check that those quotas still cover the load your deployment would carry during a failover.

Regional Redis and residency

Each region runs its own Redis for shared rate limits, router state and cache, and the LiteLLM production guide requires Redis 7.0 or newer once more than one proxy instance runs. Whether that Redis may hold data from a given region depends on your residency rules. Ask your compliance lead which keys, counters and cached values count as regional data, and confirm the placement with the owner of the Redis service.

What do teams ask about a LiteLLM multi-region deployment?

What drives the cost of a LiteLLM multi-region deployment?

The cost follows the number of regions, the managed PostgreSQL and Redis services each one needs, and the design and testing around them. DeployOpen works to a fixed scope, and the quote follows from a written one. Ask for the quote to split one-time work (architecture, build, failover drill, documentation) from recurring items. Recurring items include cloud services in each region, the shared database, Redis, monitoring, upgrades, on-call cover if you buy it, and a LiteLLM Enterprise license if you need one. Each cost has a different payer: cloud charges go to your cloud account, the license to LiteLLM, and implementation to DeployOpen. Confirm which regions are in scope, whether failover testing is included, and which secret manager integration applies.

How long does a LiteLLM multi-region deployment take?

Duration depends on scope, and no single figure applies to every environment. The main drivers are how many regions you run, whether you choose active-active or active-passive, how much cloud networking, DNS and secret management already exists, and how many approvals your change process requires. Active-active adds traffic routing and cross-region state testing. Active-passive adds a DNS failover record and a recovery drill. Work that waits on cloud account access, DNS changes or a decision on recovery targets often sets the timeline more than the build itself. Ask for a written timeline that lists each dependency and the party responsible for it.

Can our own team run LiteLLM across regions without a partner?

Yes, if your team already operates PostgreSQL, Redis and LiteLLM in production and has an owner for the cross-region design. The topology has three rules: every region points DATABASE_URL at one shared PostgreSQL database in the primary region, each region runs its own Redis, and all regions run in the same cloud provider. Check these skills before deciding: running a database failover, operating Redis 7.0 or newer in each region, rotating LITELLM_MASTER_KEY and LITELLM_SALT_KEY safely across all instances, monitoring the gateway, and staffing on-call. If a gap exists, a partner can cover the design or the drill while your team keeps the runbook.

What does our team need to provide for a multi-region LiteLLM project?

Start with cloud account access to create PostgreSQL, Redis, compute and load balancing in each region, plus network paths between regions and to your model providers. You also need DNS control over the zone clients use, because active-active routing and active-passive failover both depend on DNS records. Give DeployOpen access to your secret manager so the master key, salt key and license are stored there and not in configuration files. Decide your recovery targets, meaning how much data loss and how long an outage the business accepts for the gateway, before design starts, since they set the replication and drill design. Name an approver for changes and a person who can attend the failover drill.

Should we run LiteLLM active-active or active-passive across regions?

Choose active-active when clients in several regions need the lowest latency to the gateway and your team can test cross-region behavior. Choose active-passive when the main goal is disaster recovery and a second region can stay idle. In both models, the regions share one primary PostgreSQL database, so the database location and its failover plan matter as much as the pattern. Active-active routes each client to the nearest region through DNS or traffic management. Active-passive keeps the second region idle behind a DNS failover record, so the drill must prove that traffic moves and that the standby can reach the database. Read-only queries can go to a replica set through DATABASE_URL_READ_REPLICA, but writes still go to the primary. Confirm the choice against your recovery targets.

Do virtual keys and budgets carry over to every region?

Yes, when every region uses the same database and the same keys. Virtual keys need PostgreSQL, and each region's instances point at one shared database, so keys, per-key, per-user and per-team budgets, TPM and RPM limits and model restrictions are stored once and read by every region. The keys depend on LITELLM_MASTER_KEY and LITELLM_SALT_KEY, which must match across all instances. LITELLM_SALT_KEY must never change once models are added. Each region's Redis holds its own rate limit and router state, so confirm how counters behave during failover before go-live. Test a key from each region after the build and again during the drill.

Does DeployOpen provide audit reports or certifications for a LiteLLM deployment?

No. DeployOpen plans, builds, hardens, documents and supports the deployment in your infrastructure, and it prepares the systems, controls and evidence that an assessment needs. Audit reports, attestations and certifications are issued by independent auditors and certification bodies, which you choose and pay directly. For the gateway, useful evidence can include the topology, runbooks, access and key controls, logging and retention settings, and the record of the failover drill. Ask your auditor which evidence they need before the build starts so it is captured during the work. Confirm with LiteLLM which audit logging, SSO and other features your Enterprise edition includes.

How DeployOpen scopes and delivers a multi-region LiteLLM gateway

DeployOpen plans and implements self-hosted LiteLLM gateways inside your own cloud accounts, including multi-region topologies with one shared PostgreSQL database in the primary region and a Redis instance in each region. Engagements are fixed-scope, so the topology choice, the failover behavior and the handover materials are agreed in writing before any build starts.

How we scope

Confirm the cloud provider and the regions in scope, since all regions must run in the same cloud provider.
Choose active-active for nearest-region routing or active-passive with a DNS failover record for disaster recovery.
Record which licensing, master key and salt key handling applies across every region before design begins.
Agree in writing whether the Enterprise license, SSO and read replica are in or out of the fixed scope.

How we build

Provision the shared PostgreSQL database and point every region's instances at it through DATABASE_URL.
Deploy regional Redis 7.0 or newer, which the production guide requires once more than one instance runs.
Test routing behavior, cooldowns and failover order using the router settings selected in the design.
Validate that virtual keys, budgets and model access work the same from each region before cutover.

How we hand over

Document the topology diagram, the region-to-database and region-to-Redis mapping, and the failover runbook.
Record where LITELLM_LICENSE, LITELLM_MASTER_KEY and LITELLM_SALT_KEY are stored and who can rotate them.
Deliver tested failover and recovery steps with the evidence from the verification run.
Hand over configuration as code so your team can reproduce each region from the same definitions.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan regional upgrades so every instance stays on a supported LiteLLM release line.
Review database growth, Redis capacity and failover tests on the schedule agreed in the retainer.
Confirm with LiteLLM which support tier, response times and security patch terms apply to your license.