LiveKit docs › Manage & Deploy › Administration › Regions › EU data residency --- # EU data residency > Configure LiveKit to keep your agent stack and its data within the European Union for GDPR data residency requirements. ## Overview Keeping a LiveKit stack within the European Union, for example to meet GDPR data residency requirements, means restricting each layer of the stack to EU regions. Each layer handles a different type of data and has its own region control, so you configure them independently. > ℹ️ **Applies to LiveKit Cloud** > > The region controls in this guide, including the project data region, agent hosting region, and inference region restriction, are LiveKit Cloud features. If you self-host LiveKit, you control where data is stored and processed through your own infrastructure. For a new project, three settings cover most of the work: 1. Select the EU project data region when you create the project. 2. Deploy your agents to the `eu-central` region. 3. Use LiveKit Inference for your STT, LLM, TTS, and realtime models. It restricts requests to EU models by default when your agents run in the EU. The [agent starter templates](https://docs.livekit.io/agents/start/voice-ai.md#starters) can be deployed to the EU, so you can stand up an EU-resident project from the start. Everything else depends on which products you use: telephony, storage, and provider plugins each need their own configuration. > ℹ️ **This topic describes product configuration** > > This topic describes the region controls LiveKit offers and how to configure them. It doesn't determine whether your app meets GDPR or any other regulation. Confirm your obligations with your own legal and compliance team, and see the [LiveKit Data Processing Addendum](https://livekit.com/legal/data-processing-addendum) for contractual terms. ## What you need to configure The following table summarizes each layer that stores or processes data, and how to restrict it to the EU: | Layer | What it controls | How to restrict to the EU | | [**Project data region**](#project-data-region) | Session analytics and agent observability data, including transcripts, session audio recordings, traces, and logs. | Select the EU data region when you create the project. | | [**Agent deployment**](#agent-deployment) | Where agent compute runs. | Deploy agents to the `eu-central` region. | | [**Telephony**](#telephony) | Inbound and outbound phone calls. | Use the EU regional SIP endpoint and set `destination_country` to an EU country code. | | [**LiveKit Inference**](#inference) | STT, LLM, TTS, and realtime requests that LiveKit routes on your behalf. | Enabled by default when your agents run in the EU; also configurable in project settings. | | [**Provider plugins**](#inference) | STT, LLM, and TTS requests your agent sends directly to a provider. | Configure each provider to use its EU regional endpoint. | | [**Your own storage**](#storage) | Where LiveKit Egress writes output, and where exported session data goes. | Upload to a storage bucket in an EU region. | | [**Legal**](#legal) | Data processing terms and sub-processors. | Accept the LiveKit DPA and review the sub-processor list. | > ℹ️ **Media transport isn't required for GDPR** > > Media transport is handled separately. LiveKit Cloud routes media over the shortest available path and doesn't retain it, so media can transit servers outside the EU without being stored there. Restricting that routing is an optional hardening step rather than a requirement, and can increase latency. To learn more, see [Restrict media transport to the EU](#media-transport). ## Step 1: Select the EU project data region The project data region determines where LiveKit Cloud stores and processes your project data. This covers both session analytics and, if you enable it, agent observability data: traces, logs, metrics, transcripts, and session audio recordings. Select **European Union (Frankfurt)** as 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 the data region is outside the EU, this data is stored in that region instead. Agent observability is separate from the data region and captures traces, transcripts, and audio from agent sessions for debugging. To review these settings, sign in to [LiveKit Cloud](https://cloud.livekit.io) and select **Project** → **Settings** → [**Observability**](https://cloud.livekit.io/projects/p_/settings/observability). Turning it off reduces what LiveKit stores, but doesn't change where data is stored. ### If you selected the wrong region The project data region is immutable, so an existing project can't be moved to the EU. You have two options: - Create a new project with the EU data region and migrate to it. - Contact [LiveKit support](https://cloud.livekit.io) to discuss your options. ## Step 2: Deploy agents to the EU Agent deployment controls where your agent code runs. Deploy your agents to the `eu-central` region so agent compute stays in the EU. The following EU region is available for agent deployment: | Region code | Location | | `eu-central` | Frankfurt, Germany | Pass the `--region` flag when you create the deployment: ```shell lk agent create --region eu-central ``` You can also set the region when you initialize a project from a starter template: ```shell lk agent init my-agent --template agent-starter-python --region eu-central ``` An agent is assigned its region on first deployment, and the assignment can't be changed afterward. To move an agent to another region, create a new deployment. Agents you create with the [Agent Builder](https://docs.livekit.io/agents/start/builder.md) deploy by default to the agent hosting region mapped to your project data region. For full instructions, see [Deployment regions](https://docs.livekit.io/deploy/admin/regions/agent-deployment.md#regions). Agent hosting controls where your agent code runs, not where media flows. Any external API calls your agent makes, such as to your own backend, a database, or a third-party service, originate from the EU deployment region but terminate wherever that service is hosted, which LiveKit can't restrict. ## Step 3: Configure telephony for the EU LiveKit SIP is a globally distributed service that routes calls through the region closest to their origin by default. To keep telephony traffic in the EU, configure both directions explicitly. ### Inbound calls Configure your SIP trunking provider to send traffic to the EU regional endpoint instead of the global endpoint: ``` .eu.sip.livekit.cloud ``` Replace `` with your SIP URI subdomain, which is your project ID without the `p_` prefix. You can find your SIP URI on the [Project settings](https://cloud.livekit.io/projects/p_/settings/project) page. If your provider routes traffic through its own edge locations, set that edge to a European location as well. For example, on a Twilio Elastic SIP Trunk, set the origination SIP URI to the EU endpoint and set the trunk region to a European edge such as Dublin or Frankfurt. For provider setup and endpoint formats, see [Region pinning for telephony](https://docs.livekit.io/telephony/features/region-pinning.md). ### Outbound calls By default, when you place an outbound call using the `CreateSIPParticipant` API, the call originates from the region where you make the API request. To originate the call from a server in the EU, set the `destination_country` parameter on your trunk configuration to an EU country code. This works with both inline trunk configuration and stored outbound trunks. The `destination_country` parameter accepts the following EU country codes: | Country | Country code | LiveKit region location | | France | `fr` | Marseille | | Germany | `de` | Frankfurt | Two behaviors matter for data residency: - If the country code doesn't match a supported region, the parameter has no effect and calls are routed using default behavior. Use only the codes in the preceding table, in lowercase. - If the preferred region is offline, calls originate from another nearby region, which might be outside the EU. For the current list of supported regions, see [Destination country for outbound calls](https://docs.livekit.io/deploy/admin/regions/endpoints.md#destination-country). > 🔥 **SIP traffic ignores protocol-based region pinning** > > Protocol-based region pinning doesn't apply to SIP. A SIP connection that lands outside the pinned region is rejected but not retried, so you must configure the EU regional endpoint explicitly. ## Step 4: Restrict inference to the EU [LiveKit Inference](https://docs.livekit.io/agents/models/inference.md) routes STT, LLM, TTS, and realtime requests through LiveKit's infrastructure. Not every model is served from the EU. To restrict inference requests to models in the EU, enable inference region pinning. For a new project with agents hosted in the EU, inference region restriction is enabled by default. To turn it on for an existing project, sign in to [LiveKit Cloud](https://cloud.livekit.io), and select **Project** → **Settings**. In the **Data and privacy** section, set **Inference region restriction** to **Enabled**. Enabling inference region pinning reduces the set of models you can choose from. In the [Agent Builder](https://docs.livekit.io/agents/start/builder.md), models that aren't available in your data region are shown as unavailable. For model availability, see the [LLM](https://docs.livekit.io/agents/models/llm.md), [STT](https://docs.livekit.io/agents/models/stt.md), [TTS](https://docs.livekit.io/agents/models/tts.md), and [realtime](https://docs.livekit.io/agents/models/realtime.md) topics. If you need explicit control over which endpoint a provider uses, call the provider directly through its plugin instead of routing through LiveKit Inference, and configure the EU regional endpoint that provider offers. Provider plugins send requests straight to the provider, so LiveKit region settings don't apply to them. If you have questions about model availability by region or per-model restrictions, [contact LiveKit support](https://cloud.livekit.io). ## Step 5: Accept the DPA and review sub-processors Configuration alone doesn't cover the contractual side of GDPR. Complete the following: - Accept the [LiveKit Data Processing Addendum](https://livekit.com/legal/data-processing-addendum) (DPA), which covers GDPR terms and EU Standard Contractual Clauses for cross-border transfers. Self-serve customers accept the DPA through the click-through [Terms of Service](https://livekit.com/legal/terms-of-service), which incorporates it by reference. Enterprise customers sign a separate DPA. - Review the [LiveKit sub-processor list](https://livekit.com/legal/sub-processors) and confirm that the sub-processors LiveKit uses meet your requirements. - Verify the same for any third-party providers you use directly, including STT, LLM, TTS, and storage vendors, since those relationships are between you and the provider. ## Optional: Configure external storage in the EU If you use [LiveKit Egress](https://docs.livekit.io/transport/media/ingress-egress/egress.md), it writes its output to a storage bucket that you specify. The region of that bucket determines where those files are stored. To keep egress output in the EU, use a bucket in an EU region: - Amazon S3: a region such as `eu-central-1`. - Google Cloud Storage: a region such as `europe-west1`. - Azure Blob Storage: a region such as `westeurope`. Confirm that the encryption and access policies for the bucket meet your own requirements. For configuration details, see [Egress outputs](https://docs.livekit.io/transport/media/ingress-egress/egress/outputs.md). If you capture session data through the Agents SDK instead, use [data hooks](https://docs.livekit.io/testing/observability/data.md) and send the output to a destination you control in the EU. To learn more about where each kind of observability data is stored, see [Data residency](https://docs.livekit.io/testing/observability/data-residency.md). Configure any third-party observability tools, such as analytics or tracing backends, to use their own EU data residency options. ## Optional: Restrict media transport to the EU Media transport pinning is a hardening step, not a GDPR requirement. LiveKit Cloud doesn't retain media, and it routes media over the shortest available path, so media can briefly transit a server outside the EU without being stored there. Restricting routing to the EU can increase latency for users outside the EU, so enable it only if your requirements call for it. Complete the previous steps first. Your end-user clients and your Cloud-hosted agents each open their own connections to LiveKit servers, and by default those connections use the closest available server. To keep both in the EU, enable [protocol-based region pinning](https://docs.livekit.io/deploy/admin/regions/region-pinning.md). Region pinning is available on the Scale plan or higher, and LiveKit must enable it for your project. When it's enabled, a connection to a server outside the EU is rejected and automatically retried on an EU server, so an agent deployed to `eu-central` can't fall back to a region outside the EU. You can see the current pinned regions on your [project settings](https://cloud.livekit.io/projects/p_/settings) page. To change them, contact LiveKit support. Protocol-based region pinning supports the following EU region: | Region code | Locations | | `eu` | France, Germany | Region pinning covers signaling and media transport, but not SIP traffic, inference requests, or agent compute. Configure each of those separately. ## Known limitations Keep the following in mind when you plan an EU deployment: - This topic 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. ## Compliance checklist Use the following checklist to confirm your configuration: - **Project data region**: The project uses the EU data region. - **Agents**: All agents run in `eu-central`. - **Telephony**: Inbound traffic uses `.eu.sip.livekit.cloud`, and outbound trunks set `destination_country` to `fr` or `de`. - **Inference**: Confirm inference region restriction is enabled, or provider plugins use EU endpoints. EU inference is auto-enabled for EU-hosted agents. - **Legal**: You accepted the DPA and reviewed the LiveKit and third-party sub-processor lists. - **External storage** (optional): Egress uploads to a bucket in an EU region, and exported session data goes to an EU destination. - **Media transport** (optional): If you need it, EU region pinning covers both client and agent transport. ## Additional resources The following pages provide full detail for each layer of the stack. - **[Region pinning](https://docs.livekit.io/deploy/admin/regions/region-pinning.md)**: Restrict network traffic to a specific region. - **[Agent deployment](https://docs.livekit.io/deploy/admin/regions/agent-deployment.md)**: Deploy agents to specific regions. - **[Region pinning for telephony](https://docs.livekit.io/telephony/features/region-pinning.md)**: Isolate inbound and outbound calls to a region. - **[LiveKit Inference](https://docs.livekit.io/agents/models/inference.md)**: Access STT, LLM, TTS, and realtime models. - **[Egress outputs](https://docs.livekit.io/transport/media/ingress-egress/egress/outputs.md)**: Configure storage destinations for egress output. - **[Observability overview](https://docs.livekit.io/testing/observability.md)**: Collect transcripts, traces, and session audio recordings. --- This document was rendered at 2026-10-18T00:27:31.015Z. For the latest version of this document, see [https://docs.livekit.io/deploy/admin/regions/data-residency.md](https://docs.livekit.io/deploy/admin/regions/data-residency.md). To explore all LiveKit documentation, see [llms.txt](https://docs.livekit.io/llms.txt).