Updated September 2026 to cover project data regions and EU data residency.
Deploying LiveKit in a specific geographic region requires careful planning. You must evaluate data residency, traffic routing, infrastructure placement, regulatory compliance, and operational visibility.
This guide provides a structured checklist to help you plan a regional deployment. It is intended as a starting point. Always consult the linked documentation for the most current and authoritative guidance.
The LiveKit docs contain authoritative documentation for regions and EU data residency, which supersede this article in the event of contradiction.
Data residency and GDPR in the EULink to this section
If you need to keep your stack in the European Union, for example to meet GDPR data residency requirements, please refer to the EU data residency guide as the authoritative, step-by-step reference.
In summary:
- Select the EU project data region when you create the project.
- Deploy your agents to the
eu-centralregion. - Use LiveKit Inference for your model pipeline. It restricts requests to EU models by default when your agents run in the EU.
Telephony, storage, and provider plugins each need their own configuration, and you also need to accept the LiveKit DPA.
Project data regionLink to this section
Every LiveKit Cloud project is assigned a data region, which determines where LiveKit Cloud stores and processes your project data. This includes session analytics and, if you enable it, agent observability data: traces, logs, metrics, transcripts, and session audio recordings.
LiveKit currently supports the United States and European Union (Frankfurt). For a full list, refer to the documentation for data residency
How to apply: Select the data region when you create the project. The data region is fixed when the project is created and can't be changed afterward. If you selected the wrong region, create a new project with the correct data region and migrate to it.
The data region doesn't control where your agents run or how your users connect to a session.
LiveKit region pinningLink to this section
Region pinning controls which LiveKit media servers are selected for rooms and sessions.
Use region pinning when you have a specific architectural or contractual reason to keep participant media (text, audio, video) on servers in one country or economic area.
Be aware that participants located outside the pinned region may experience increased latency, since they are prevented from connecting to a closer LiveKit region.
More information, including the list of available regions: Region Pinning docs
How to apply: Region pinning is available on the Scale plan or higher. Contact our support team if you need to pin traffic to a specific region. Our team can also help you evaluate redundancy and failover considerations.
Note: Region pinning applies to media servers. It does not automatically cover logs, control-plane metadata, or third-party integrations. Those topics are addressed later in this guide.
Agent hostingLink to this section
Agent hosting determines where your AI agents execute and process data.
This is important when agents handle sensitive or regulated information, including prompts or transcripts that must remain within a specific jurisdiction.
LiveKit supports two agent hosting approaches:
- LiveKit Cloud hosting - Run your agent within the same infrastructure that powers LiveKit Cloud. See the Agent deployment docs for a list of supported regions, which we are continually expanding.
- Self-hosting – Deploy and operate your agents in your own infrastructure. This is appropriate when you need a region that is not yet supported by LiveKit Cloud. See the self-hosted deployments docs for details.
If your required region is supported, LiveKit Cloud hosting is generally recommended for operational simplicity.
Model hostingLink to this section
Voice AI applications rely on multiple models, including STT, TTS, and LLM components. Some deployments use individual pipeline models, while others use real-time multimodal models. You may also optionally include an avatar.
If you have regional regulatory requirements, you must understand where each model processes data. Even if LiveKit media is pinned to a specific region, external model APIs may process requests elsewhere. Ensure your agent hosting and model endpoints are aligned to avoid unintended cross-region data flows.
This section does not cover each model in detail, but your region-restricted options include:
LiveKit InferenceLink to this section
LiveKit Inference can restrict requests to models served from your project data region. This is called inference region restriction:
- For new projects with agents hosted in the EU, region restriction is enabled by default.
- For an existing project, sign in to LiveKit Cloud and select Project → Settings. In the Data and privacy section, set Inference region restriction to Enabled.
Enabling region restriction reduces the set of models you can choose from. The model tables in the LLM, STT, and TTS docs show which models have an EU endpoint, and the Agent Builder shows models that aren't available in your data region as unavailable.
LiveKit also offers regional Deepgram hosting in Mumbai for STT. See the Deepgram docs for more information.
PluginsLink to this section
Plugins send requests directly to the provider, so LiveKit region settings, including inference region restriction, don't apply to them. Configure each provider's regional endpoint yourself. Your relationship with each provider is direct, so also review their DPA and sub-processors.
- Major LLM providers such as OpenAI and Google Gemini offer "inference residency" to restrict processing within defined regions.
- Many enterprise STT and TTS providers support regional hosting.
- Azure OpenAI enables regional deployments within specific Azure regions across LLM, STT, and TTS. Similarly, AWS provides regional hosting across the full AI pipeline.
- Some countries offer locally developed models tailored to national requirements. If your LLM exposes an OpenAI-compatible endpoint, you can use the OpenAI plugin and specify a custom
base_url. - Region-locked self-hosted deployments are possible through providers such as Baseten. You can also run models locally using services such as Ollama.
This is not an exhaustive list. For reliability, consider using multiple providers in combination with a fallback adapter.
SIP pinningLink to this section
SIP pinning controls where PSTN ingress and egress occur with respect to LiveKit.
LiveKit SIP is globally distributed and routes calls through the region closest to their origin by default. If your telephony traffic must remain in a specific country or economic area, for example to comply with local telecom regulations or data residency requirements, you must pin your SIP traffic accordingly.
SIP pinning ensures that calls pass through the LiveKit SIP gateway in the designated region, so be sure to select a carrier who supports that region and consult their documentation for any additional requirements.
More information, including supported regions can be found in our telephony region pinning docs. Also see our documentation for region-specific outbound calls.
How to apply:
- Inbound calls – Use the region-specific SIP endpoint.
- Outbound calls – Specify the region in the trunk configuration.
LiveKit phone numbers are not available in all regions. If the required region is unsupported, you must integrate with an external telephony provider.
Agent ObservabilityLink to this section
Agent Observability stores agent logs, traces, metrics, transcripts, and session audio recordings in LiveKit Cloud. This data might be considered personal data in regulated environments.
Observability data is stored in your project data region. To keep it in the EU, create your project with the EU data region. Customers with strict residency requirements outside of the US or EU should disable agent observability at the project level.
To remove personal data before it's stored, enable PII redaction.
Additional linksLink to this section
The following resources may be helpful when planning a regional deployment:
- The LiveKit trust center includes compliance documentation such as our SOC2 report, BAA agreement, pen test results, and related resources.
- Our legal pages include the list of sub-processors, the data processing addendum, and the list of HIPAA eligible services.
Static IP address supportLink to this section
Some enterprise customers require static IP addresses for firewall allowlisting.
The list of Static IPs is available in the documentation.
Static IP addresses apply only to specific regions and services and if your region is not listed, you must rely on wildcard domains. If a service is not listed in the documentation, it is not guaranteed to receive an IP address within the static block.
Additional data considerationsLink to this section
- Please refer to our DPA for additional information; specific details about region pinning can be found in section 2.5.
- You are responsible for ensuring that any exported data complies with your residency requirements. This includes (but is not limited to) agent logs, session telemetry, or egress.
- EU data residency guidance covers EU-wide residency. Individual countries, including France, Germany, and Spain, might impose requirements beyond GDPR.
- External services your agent calls are outside LiveKit control, so you're responsible for their residency.
Worked examplesLink to this section
Below are example deployment strategies for teams that have decided their media and processing should stay in one place.
| Sensitive data | |
|---|---|
| United States - Data region: US - Agent hosting: US region - Model provider: US-only endpoint - SIP: US gateway pinned to US | Japan - Agent hosting: Tokyo-based infrastructure (self-hosted) - Model provider: APAC endpoint - SIP: Japanese carrier, use endpoints in Asia |
| Europe - Data region: EU region - Agent hosting: EU compute - Model provider: EU endpoint - SIP: EU gateway with EU inbound and outbound pinning | Kingdom of Saudi Arabia - Agent hosting: In-country infrastructure (self-hosted) - Model provider: Endpoint in Saudi Arabia - SIP: Saudi gateway with Saudi inbound and outbound pinning. |
Any other questions?Link to this section
If you have additional questions, please contact us via our contact sales link or join our developer community