Thanks — I’m responding to your questions about Saudi Arabia (KSA) data residency, agent deployment, WebRTC, and the minimum compliant setup. Short answers • Agent deployment in KSA: Yes — agents can be deployed to the

sa

region. • WebRTC in KSA: Yes — WebRTC can be restricted to KSA using region pinning (Scale plan or higher). • If you cannot or choose not to use Cloud in KSA: you can self-host agents and/or the LiveKit server in KSA to meet residency needs. What you can do and how to configure it 1) Agent deployment in KSA • Available: Yes. • How to specify: when creating an agent use the region flag:

lk agent create --region sa

Or set the region in your

livekit.toml

agent configuration if using templates/automation. 2) WebRTC pinned to KSA • Available: Yes. • How to enforce: enable protocol-based region pinning for your project (requires Scale plan or higher). Once enabled you specify allowed regions (e.g.,

sa

) so signaling and media are restricted to that region for client connections. • SIP note: if you use SIP, use the regional SIP endpoint format (

{subdomain}.sa.sip.livekit.cloud

) or set

destination_country: "sa"

for outbound calls to ensure KSA routing. 3) Using self-hosted agents with Cloud WebRTC (if you don’t deploy Cloud agents) • You can run self-hosted agents and still use a WebRTC server deployed in KSA. • Ensure your LiveKit server nodes and supporting infra (Redis, turn/TURN, load balancer) are deployed inside KSA and use region-aware node selection so traffic remains in-region. 4) If neither Cloud agent nor Cloud WebRTC in KSA meets your needs • Then self-host both agent and LiveKit server inside KSA. This gives full control and ensures no cross-border data flow. Minimum viable setup for KSA compliance Option A — LiveKit Cloud (minimal if acceptable): • Subscribe to Scale plan or higher. • Deploy agents with

--region sa

. • Request/enable protocol-based region pinning for your project (so WebRTC is pinned to

sa

). Result: agents, signaling, and media stay in KSA. Option B — Full self-host (if you need full sovereignty): • Self-host agents and LiveKit server in your KSA infrastructure. • Deploy Redis, TURN, and any storage in-region. Result: full in-region control. Quick clarifying question • Do you plan to use LiveKit Cloud (Scale plan) or do you prefer full self-hosting? That will determine the exact steps I should give next (Cloud setup + pinning steps vs. self-host deployment checklist). Sources: livekit/livekit_composite | DeepWiki | Region pinning | LiveKit docs | SIP cloud and region pinning | LiveKit docs | Distributed Setup | LiveKit docs | LiveKit Cloud Architecture | LiveKit docs