We are evaluating LiveKit Cloud on the Build plan for an application that currently relies on a provider-enforced finite session lifetime. We need the media service to terminate an active participant or the entire room at a predetermined absolute deadline, including native DataTracks, without a successful management API call at that time. The deadline must continue to apply while our backend or the management endpoint is unavailable and while an already connected client is receiving refreshed tokens. Expired original or refreshed tokens must not permit rejoining after the deadline.
We have tested immediate RemoveParticipant with an explicit revoke_token_ts: active clients disconnect, and original and refreshed tokens are rejected, including for departed and never-joined identities. We understand that token exp governs initial admission and empty/departure timeouts govern rooms without participants. Those controls do not establish the active deadline above.
Does LiveKit Cloud provide a supported participant or room deadline capability that preserves this behavior on the existing Build plan? If so, please identify the exact API or supported configuration, refresh/reconnect semantics, and how the deadline behaves during management-plane failure. If the capability requires another tier or resource, please explain its terms and cost without making account changes. We have not authorized a tier upgrade or additional infrastructure.
A scheduled backend removal or client-only lease does not satisfy this particular requirement. If the guarantee is not supported, please confirm that explicitly so we can make an informed architecture and product-policy decision.
Not staff, but from the public API surface the answer looks like no, and it’s worth saying plainly so you can plan around it.
CreateOptions / RoomConfiguration exposes only emptyTimeout, departureTimeout, maxParticipants, playout delay settings, metadata, egress and agent dispatch. There is no absolute deadline or max session duration field anywhere in it. The two timeouts you already identified are the only time-based controls, and both are about empty rooms, not active ones.
This is not plan-gated, it is simply absent from the room API, so a tier change would not get you it. Worth knowing before you evaluate any upgrade.
Your requirement sounds like Twilio Video’s max_participant_duration, which has no LiveKit equivalent today. Feature request #274 on the React Native SDK asks for the same thing and the answers there confirm the only options are a scheduled backend call to delete the room, or a client-side timer, both of which you have already ruled out.
Since you need a definitive answer for an architecture decision, I would flag this for LiveKit staff to confirm rather than treating a community reply as final. But I would not expect the answer to differ.
Thank you for distinguishing the public API evidence from a staff confirmation. That matches the documented controls we have found.
Could LiveKit staff confirm whether any supported Cloud-side participant or room deadline exists, on Build or another tier, that terminates active native DataTracks at the predetermined deadline even if our backend or the management endpoint is unavailable? If none exists, an explicit confirmation would let us make the architecture decision without mistaking token expiry, scheduled removal, or a client timer for an equivalent guarantee.
We will preserve our existing provider-enforced expiry and will not change plans or enable the replacement on the basis of an unverified equivalent.
On the DataTracks part specifically, that may be less of an open question than it looks.
Data tracks travel over WebRTC data channels. The docs describe frames being split into data channel packets, and flush as waiting until queued packets reach the underlying data channel. They also list “the room has disconnected” as one of the two conditions that cause tryPush to fail. So terminating the participant terminates its data tracks. There is no separate data track lifetime to worry about.
The one thing that could have been a hole is that data tracks are automatically re-published and re-subscribed after a reconnection. But that path needs a valid token, and you have already confirmed that both original and refreshed tokens are rejected after revoke_token_ts. So it closes too.
That leaves a single question for staff, which might get you a faster answer: is there any way to have LiveKit fire RemoveParticipant with revoke_token_ts at a stored future timestamp, without your backend being reachable at that moment. The enforcement primitive already does what you need. Only the scheduling is missing.
To specifically answer your question, no there is no “hard deadline” feature for participants or rooms and others with this requirement I have seen solve the issue in the same way you described in the second paragraph of your question.
Yes, that is a gap. I haven’t seen this before - if it were me I might add resilience to my backend infrastructure so if my management endpoint went offline a backup could detect it and terminate the rooms preemptively.