Architecture
Cloud Portability
The proof that the design is cloud-agnostic: the same LiveKit logic and bootstrap deploy to Azure and GCP, with only the provider resource wiring differing.
The portability proof
The modules in infra/shared contain no cloud-provider SDK — just the logic to generate the LiveKit artifacts and the cloud-init bootstrap. Both the Azure and GCP stacks import them verbatim. The only per-cloud code is the resource wiring (how you ask each provider for a VM, a network, and a firewall).
What differs per cloud
| Concern | Azure | Google Cloud |
|---|---|---|
| Provider | azure-native | @pulumi/gcp |
| Compute | VM (eastus) | GCE (us-east1) |
| Network | VNet + NSG | VPC + Firewall |
| Signal URL | lk.az.involvelxp.com | lk.gcp.involvelxp.com |
| LiveKit logic | shared | shared |
| cloud-init | shared | shared |
| DNS (Cloudflare) | shared | shared |
Identical behavior, verified
Both deployments pass the same checks — valid TLS, a healthy signal endpoint, and real WebRTC media with zero packet loss. See Testing & Verification for the evidence.
Why this matters
Healthcare customers often have strong opinions about where data lives. Being able to stand up an identical stack on a different cloud — or in a specific region — without rewriting the platform is a real commercial advantage, and it avoids lock-in.