what are the steps needed to self-host livekit recording agents? what is it needed to self-host the whole stack?

Thanks for reaching out, Mohammed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

we are using kubernetes

Thanks — since you’re on Kubernetes, here’s a Kubernetes‑focused plan with concrete, ordered steps and examples to self‑host LiveKit recording agents and the full LiveKit stack. I’ll include what to deploy, important config, and operational tips. If you want, I can provide Helm values and sample manifests next. Before we start: do you already have a Kubernetes cluster (provider, node sizes, GPU nodes)? Also tell me which storage you’ll use for recordings (S3-compatible or persistent volumes). That will let me give exact YAML/Helm snippets. 1) Components to run on Kubernetes • livekit-server (the SFU/media server) • livekit-egress (recording/egress service) • Redis (Pub/Sub for egress coordination) • recording agents (your agent containers built from LiveKit Agents SDK) • Optional: object storage (S3 or S3-compatible), ingress controller, cert-manager, monitoring (Prometheus/Grafana), and a load balancer 2) High-level architecture & responsibilities • livekit-server: handles rooms, signaling, and SFU media • livekit-egress: receives egress jobs via Redis, runs GStreamer/Chrome for transcoding/compositing • Redis: pub/sub message bus between livekit-server and egress/agents • Agents: connect outbound to livekit-server to join rooms and perform recording/transcription/AI tasks • Storage: recordings uploaded to S3 or stored in a PVC depending on configuration 3) Cluster & node requirements • Standard nodes for server, Redis, agents • For egress/transcoding, use nodes with GPUs if you want hardware encoding (install NVIDIA drivers + device plugin) • Open UDP and TCP at your cloud/firewall level for the LiveKit service (K8s service/ingress handles external exposure) • Recommended: Autoscaling for agent/egress replicas; node pools for GPU vs CPU workloads 4) Networking, domain & TLS • Create a DNS record for your LiveKit hostname (e.g., livekit.example.com). • Use an ingress controller (NGINX/Traefik) or a LoadBalancer service exposing ports. • Terminate TLS via cert-manager and Let’s Encrypt, or provide your TLS certs to the ingress. • Ensure UDP traffic is forwarded for WebRTC (LoadBalancer or NodePort with external UDP support). 5) Deploying livekit-server on Kubernetes (short path) • Use the official LiveKit Helm chart (livekit-helm). • Key Helm values to set: ◦

app.livekitKeys

or env vars: API key:secret ◦ `ingress.hosts[0].host`: your domain ◦ Configure service type (LoadBalancer) and UDP port mapping for WebRTC (typically 7882) • Post-deploy: verify pods are Running and service endpoints are reachable; test a client connecting to the domain. 6) Deploying Redis • Deploy a managed Redis or a Kubernetes Redis (Helm chart like bitnami/redis). • Ensure Redis is reachable by

livekit-egress

and by any component that needs pub/sub. 7) Deploying livekit-egress (recording) • Deploy egress as its own Deployment/StatefulSet. • Environment/config: ◦ Redis connection string ◦ Object storage credentials (S3_BUCKET, S3_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) if using S3 ◦ Any GStreamer/Chrome flags and temp storage path (PVC) • If using GPU acceleration: ◦ Use node selector/taints for GPU nodes ◦ Add NVIDIA device plugin DaemonSet and set resources.requests/limits for GPUs • Make egress autoscalable if you expect concurrent egress jobs 8) Build & deploy recording agents • Build agents using the LiveKit Agents SDK (Node or Python) and create a Docker image. • Provide env vars/secrets to agent pods: ◦

LIVEKIT_URL

,

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

◦ Any AI provider keys (Deepgram, OpenAI, etc.) • Deploy agents as a Deployment with HorizontalPodAutoscaler (HPA) for scale. • Agents do not require inbound ports; they must be able to reach the LiveKit server URL. 9) Secrets & configuration • Use Kubernetes Secrets for API keys and AI credentials. • Use ConfigMaps for non-sensitive configuration (agent names, dispatch settings). • If you want to rotate secrets without redeploying containers, implement a secret-sync or use tools like External Secrets. 10) Job dispatch & token scopes • Ensure livekit-server is configured so it can dispatch jobs to agents/egress: ◦ Agent dispatch is matched by

agent_name

and permissions in your token. ◦ Tokens must include proper grants (roomJoin, canPublish, canSubscribe) for agents. • Validate by issuing a job from server and watching agent logs for job receipt. 11) Storage for recordings • Recommended: S3-compatible storage (AWS S3, MinIO). • Configure egress with proper S3 credentials and bucket; ensure network access from egress pods to S3. • Alternative: Use PVCs for temporary storage then move files to object storage. 12) Observability & monitoring • Expose metrics via Prometheus (livekit exposes Prometheus metrics). • Collect logs (ELK/Fluentd) from server, egress, and agents. • Set alerts for pod restarts, high CPU/GPU usage, Redis latency, and egress failures. 13) Example next steps I can provide • Helm values.yaml for livekit-server tailored to your cluster and domain. • Deployment manifest examples for livekit-egress with Redis and S3 env config. • Sample Deployment + HPA for an agent, plus a Dockerfile starter for Node/Python agents. • GPU node YAML and instructions to enable NVIDIA drivers and device plugin. If you tell me: • Your Kubernetes provider (EKS/GKE/AKS/self-hosted), • Whether you’ll use S3 or PVC for recordings, • If you plan to use GPU nodes for egress, I’ll provide the specific Helm values and sample manifests for those choices. Which details do you want first?