EU data residency

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.

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 model pipeline; it restricts requests to EU models by default when your agents run in the EU.

The agent starter templates 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.

What you need to configure

The following table summarizes each layer that stores or processes data, and how to restrict it to the EU:

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  and select Project → 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  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:

Pass the --region flag when you create the deployment:

lk agent create --region eu-central

You can also set the region when you initialize a project from a starter template:

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 deploy by default to the agent hosting region mapped to your project data region. For full instructions, see Deployment 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:

<sip-subdomain>.eu.sip.livekit.cloud

Replace <sip-subdomain> with your SIP URI subdomain, which is your project ID without the p_ prefix. You can find your SIP URI on the Project settings  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.

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:

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.

Step 4: Restrict inference to the EU

LiveKit Inference routes STT, LLM, and TTS 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 pinnning.

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 , 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, models that aren't available in your data region are shown as unavailable. For model availability, see the LLM, STT, and TTS 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 .

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  (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 , which incorporates it by reference. Enterprise customers sign a separate DPA.
• Review the LiveKit sub-processor list  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, 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.

If you capture session data through the Agents SDK instead, use data hooks and send the output to a destination you control in the EU. 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. 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  page. To change them, contact LiveKit support.

Protocol-based region pinning supports the following EU region:

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 <sip-subdomain>.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.