Ingress "enabled" flag accepted but not persisted or enforced on LiveKit Cloud (both CreateIngress and UpdateIngress)

Egress / Ingress
,
1

We’re using LiveKit Cloud for RTMP ingress. The ingress enabled flag appears to be silently discarded by Cloud on both CreateIngress and UpdateIngress: the API accepts the request and echoes enabled: false back in the response, but an immediate ListIngress shows the field absent, and pushing with the stream key still succeeds.

Repro A (UpdateIngress):

  1. Create RTMP ingress, push stream → PUBLISHING (baseline OK)
  2. Stop push → INACTIVE
  3. UpdateIngress(enabled=false) → response echoes enabled: false
  4. ListIngress immediately → enabled field missing (HasField=False)
  5. Re-push with the same stream key → BUFFERING → PUBLISHING (not rejected)

Repro B (CreateIngress):

  1. CreateIngress(…, enabled=false) → response echoes enabled: false
  2. ListIngress immediately → enabled field missing
  3. Push to this never-enabled ingress → BUFFERING → PUBLISHING (not rejected)

Client side verified: Python livekit-api 1.1.0 / livekit-protocol 1.1.1; HasField(“enabled”)=True on the outgoing requests (explicit presence), so the field is correctly serialized on the wire.

Expected behavior per livekit_ingress.proto: “The default value is true and when set to false, the new connection attempts will be rejected.” The open-source implementation does this: livekit/livekit pkg/service/ingress.go persists req.Enabled on update, and livekit/ingress rejects new sessions when disabled (PR #319 (Reject ingress if Enabled flag is false by Rajiv91 · Pull Request #319 · livekit/ingress · GitHub), merged Jan 2025). Cloud behavior diverges from OSS.

Impact: With reusable RTMP ingresses we cannot block re-publishing after a live session ends; if the encoder (e.g. OBS) keeps pushing, transcoding continues to bill. DeleteIngress is currently the only reliable way to stop it, at the cost of stream key persistence across sessions.

Tested on 2026-07-03 and 2026-07-06 (UTC). Happy to share project ID, ingress IDs and exact timestamps privately.

Is this a known Cloud limitation, and is a fix planned?

2

Thank you for reporting, the team are working on a fix for this and I’ll update here when I have more information.

3

The fix has been fully deployed as of today. @terry.l please let us know if you still have issues with the flag.