Thanks — I’m responding to your question about where composite egress runs and whether it lives on the agent server in self-hosted setups. Short answer • Composite egress is a separate participant in the room, but it does NOT run inside the agent process. • It runs as its own egress worker/service. If you self-host and you deploy the LiveKit egress service, then those egress workers run on your hardware. If you don’t deploy the egress service, composite egress will not run on your agent machines. How it works (high level) 1. When you start a room composite egress, the egress service launches a dedicated worker process. 2. That worker: ◦ Starts a headless Chrome instance, ◦ Joins the LiveKit room as a hidden participant, ◦ Renders the room using a template (prebuilt or custom), ◦ Captures audio/video from the browser, ◦ Encodes and exports the result to the target (file, RTMP, etc.). 1. The egress worker runs independently of the LiveKit SFU and any agent participant processes. It’s a standalone component managed by the egress service. What this means for self-hosting • To have composite egress run on your infrastructure, you must deploy the LiveKit egress service alongside the LiveKit server and agents. • If you deploy the egress service on your servers, the egress workers will run on that hardware. • If you rely on a hosted LiveKit egress (or don’t deploy egress), the workers will run wherever that egress service is hosted (not on your agent machines). If useful, I can: • Walk you through the egress service deployment options for self-hosting. • Show configuration steps to ensure egress workers run on specific nodes (e.g., resource sizing, placement). • Explain how to secure or limit the egress service when deployed on your infrastructure. Which of those would you like next? Sources: Universal Egress