Introducing Private Links on LiveKit

An agent's impact comes from both its overall performance and the complexity of the tasks it executes. Low latency combined with high scalability and reliability enable enterprise-wide deployment of humanlike agents, but those agents can only perform complex, high-value tasks if they have access to internal data and systems that provide context and enable taking actions.

This puts enterprises in regulated industries like financial services or healthcare in something of a bind if they lack a secure way to enable that access: they can deploy agents for superficial, lower-value use cases, or build and maintain their own secure connections to enable deeper access.

Private Links solve this dilemma by letting you make private requests to sensitive internal resources via your cloud network. With Private Links, you can unlock complex use cases for LiveKit-hosted agents — the gold standard in low latency, scalability, and reliability — without maintaining any public IPs, inbound firewall rules, or VPN infrastructure.

How Private Links work#

Private Links work via a fully-managed, encrypted tunnel between your agents and your cloud network. When you create a Private Link, LiveKit provisions a gateway in a LiveKit-managed VPC in the same cloud region as your resource and connects it to your VPC via the cloud provider's native private connectivity.

When your agent makes a request, it connects to a generated .link hostname that only resolves from your deployed agent environment. That traffic is routed through an encrypted WireGuard tunnel to a LiveKit gateway running in the same cloud region as your resource. The request then enters your VPC via AWS PrivateLink or Azure Private Link and reaches your service through your load balancer.

A Private Link request travelling from a customer agent pod in a LiveKit data center through a secure connection to a WireGuard gateway server in LiveKit's AWS VPC, then into the customer's VPC via AWS PrivateLink and a Network Load Balancer — This diagram is illustrative and shows the AWS path.

Your resources are never exposed to the public internet, and you have nothing to maintain. You approve the connection once on your side, and LiveKit manages everything else.

Private Links strictly support TCP-based connections secured with TLS. Connections must negotiate TLS before app data is requested, including protocols like PostgreSQL that use their standard TLS handshake. Insecure TCP and general UDP traffic aren't supported.

Setting up Private Links#

You can set up Private Links via the LiveKit CLI or in the LiveKit Dashboard. More extensive documentation is available for AWS and Azure.

Before starting, confirm you have:

A LiveKit Cloud project configured in the LiveKit CLI.
A LiveKit agent deployed in the target LiveKit region.

On AWS#

Put a Network Load Balancer in front of your service, with a listener on the port your agent needs. AWS PrivateLink endpoint services require an NLB.
Create a VPC endpoint service pointing at that NLB, leave acceptance required turned on, and copy the service name it returns.
Grant LiveKit access to the endpoint service by allowing the principal arn:aws:iam::266092630715:root. Scoping to just this principal means only the expected LiveKit connection can reach your service.
Create the link with the CLI, passing the endpoint service name. --region is your LiveKit agent region; the AWS region is derived automatically from the service name. Save the returned Private Link ID.
```
1lk --project <project-name> agent private-link create \
2  --name <link-name> \
3  --region <livekit-region> \
4  --port <service-port> \
5  --endpoint '<vpc-endpoint-service-name>'
```
Back in AWS, accept the new pending endpoint connection from account 266092630715.

On Azure#

Copy the Resource ID of the resource your agent needs to reach, along with the Azure region it lives in.
Create the link with the CLI, specifying both your LiveKit agent region (--region) and the Azure region (--cloud-region) hosting the resource. --port must match your service's listening port. Save the returned Private Link ID.
```
1lk --project <project-name> agent private-link create \
2  --name <link-name> \
3  --region <livekit-region> \
4  --cloud-region <azure-region> \
5  --port <service-port> \
6  --endpoint '<azure-resource-id>'
```
In Azure, approve the new pending private endpoint connection.

For both clouds#

Wait for the link to report healthy, either from the CLI or in the dashboard under Agents → Private links, where you'll also find the generated .link hostname.
```
1lk agent private-link health-status --id <private-link-id>
```
Test connectivity from a deployed agent in the same LiveKit region. The .link hostname won't resolve from your laptop.

Additional considerations#

Private Links are priced at $50 per link, plus $0.10 per GB of bandwidth transmitted in both directions.
Each project is currently limited to 3 Private Links per region. Contact LiveKit support if you need more.
Private Links are available in a handful of regions today. Your LiveKit agent must be in the same LiveKit region as your LiveKit Private Link for connections to work. The available LiveKit regions are eu-central and us-east.

Region	LiveKit region
US East	`us-east`
EU Central	`eu-central`

LiveKit supports connecting via Private Link to the following AWS and Azure regions today. If your cloud provider region isn't listed, contact LiveKit support to request availability.

Region	AWS region
US East	`us-east-1`
US West	`us-west-2`
EU Central	`eu-central-1`

Getting started#

Private Links are available today for US and EU-deployed agents on LiveKit Cloud. You can create your first link via the LiveKit CLI as shown above, or in the LiveKit Dashboard under Agents → Private links.

For more detailed setup and troubleshooting steps, see the Private Links documentation and its setup guides for AWS and Azure, and share your feedback in the LiveKit Community.

09.01.2026