my team has designed a redis where they have set it this way that which ever device was present at that time only had its direct accesss and we dont have direct accesss to it. so i have to design a way such that i can eliminate the use of redis and use a different memory or cache which has some similar functions to redis and which wont add much latency to my livekit setup consider for example one token is generated and we have 5 machines so one machine knows that we have to use this token, but now all 5 machines should use this token for that 1 hour and for this purpose we are using redis but can you give me some alternatives to this instead of redis what can be used

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

No, persistence is not required. In the same region / network No, I dont run any messaging/broker infa No — app handles expiry; store TTL is nice-to-have

Thanks — that’s helpful. Given no persistence, same-region network, no existing broker, and app-handled expiry, here are two practical, low-latency options and short implementation steps. Recommended option — NATS (lightweight pub/sub) • Why: Minimal latency, easy to deploy in-region, built for broadcasting messages to all nodes. • Basic plan: a. Deploy a small NATS cluster (1–3 nodes) in your region. b. When a token is generated, publish a token message (include token value and expiry timestamp) to a subject like

tokens.update

. c. All 5 machines subscribe to

tokens.update

and cache the token in local memory for the hour. d. On token publish, subscribers replace their local token and use the expiry timestamp to evict it (or rely on app TTL). • Benefits: Very low latency, no durable storage required, simple clients in many languages. Simpler zero-infra option — direct broadcast / gossip • Why: No new infra; lowest operational overhead and latency inside the same region. • Basic plan: a. When a machine generates a token, it sends a short HTTP/gRPC message to the other 4 machines (fan-out) containing token + expiry. b. Recipients store token in local memory and enforce expiry locally. c. Optionally add a simple retry/backoff and an acknowledgement to ensure delivery; or use a lightweight gossip library for eventual consistency. • Benefits: Minimal components, immediate propagation, TTL fully handled by app. Other viable choices (if you change requirements) • Hazelcast: distributed in-memory map with events and TTL. • Memcached cluster: fast in-memory KV, but no built-in pub/sub; you'd need an extra broadcast mechanism. • Lightweight cloud pub/sub or Firestore: workable but adds more latency/managed infra. Which would you prefer to try first — NATS or direct broadcast? I can provide example code snippets (HTTP/gRPC or NATS) and a minimal deployment plan. , with interactive elements

give me two best suited options for this

Thanks — based on your constraints (no persistence, same region, no existing broker, app handles expiry), the two best options are: 1) NATS (lightweight pub/sub) • Why: Extremely low latency, simple to deploy in-region, native pub/sub so token broadcasts hit all machines immediately. • Pros: Minimal infra (1–3 node cluster), many client libraries, built-in subjects for fan‑out, JetStream optional if you later need persistence. • Cons: Adds a small broker to run; slight operational overhead versus pure peer messaging. • Implementation (high level): a. Deploy a small NATS cluster in your region. b. Token generator publishes message to subject

tokens.update

containing

{ token, expiry }

. c. All 5 machines subscribe to

tokens.update

, update their local in‑memory cache on receive, and enforce expiry locally. d. Optionally add simple authentication and TLS for security. 2) Direct broadcast (fan‑out) via HTTP/gRPC (peer-to-peer) • Why: No new infra; lowest operational footprint and lowest added latency inside the same network. • Pros: No broker to manage, trivial to implement, works well in same‑region networks. • Cons: You must implement best‑effort delivery, retries/acks if needed, and handle machines that are down during broadcast. • Implementation (high level): a. Each machine exposes a small endpoint (HTTP/gRPC) to accept token updates. b. When a token is generated, the originating machine POSTs/gRPCs the token+expiry to the other 4 machines (fan‑out). c. Recipients store token in local memory and enforce expiry locally. d. Optionally implement retries/backoff, idempotency, and acknowledgements; or use a lightweight gossip library for eventual consistency. Which one would you like sample code or deployment steps for first — NATS or direct broadcast? , with interactive elements

are these choices cost effective or will increase the costs

Thanks — I’ll explain cost impact for the two options (NATS and direct broadcast) and the main trade-offs. NATS (lightweight pub/sub) • Cost drivers: running a small cluster (VMs/containers), network egress, monitoring, and occasional maintenance time. • Typical cost impact: low — a 1–3 node cluster using small VMs or containers is inexpensive in-region; resource usage is minimal because messages are tiny. Expect a small recurring infra cost and modest operational overhead. • Trade-offs: adds a broker to manage (availability concerns, TLS/auth set up). Gives reliable, low-latency broadcasting with little development effort. Direct broadcast (HTTP/gRPC fan‑out) • Cost drivers: none for new infra (uses existing machines), slight CPU/network overhead on the generating node for fan‑out and on recipients to process messages. • Typical cost impact: minimal to zero — no extra servers; only marginal increase in CPU/network on existing machines. • Trade-offs: you must implement retries/acks and handle edge cases (downed nodes) yourself; development and testing time is the main cost. Summary recommendation • If you prefer minimal operational work and built-in reliability, NATS adds a small recurring cost but simplifies development. • If you want the lowest monetary cost and can handle delivery logic in your app, direct broadcast is the most cost-effective. If you want, I can estimate resource sizing (VM sizes, throughput impact) for your 5-machine setup to give a rough monthly cost. Which would you like? , with interactive elements

also tell me these are good alternatives for redis or not

Short answer: Yes — both NATS and direct broadcast are good alternatives to Redis for your token-sharing use case given your constraints. Why they’re suitable • NATS: Provides native pub/sub like Redis Pub/Sub, with lower operational overhead than Redis when used only for messaging. It broadcasts updates to all subscribers with very low latency, so it matches Redis’s real-time propagation behavior. • Direct broadcast (HTTP/gRPC/gossip): Achieves the same end result without extra infra by pushing the token from the generator to all peers. It’s the simplest and lowest-cost approach and adds virtually no latency when all machines are in the same region. Where they differ from Redis • Persistence: Redis can persist keys and supports TTL at the store level. You said persistence isn’t required and your app handles expiry, so store-level persistence/TTL from Redis isn’t needed. NATS (without JetStream) and direct broadcast do not provide durable storage; JetStream can add durability if you later need it. • Built-in TTL/KV semantics: Redis is a KV store with TTL. NATS is a messaging system (no KV/TTL by default). Direct broadcast relies on your app’s local cache and expiry logic. If you want store-level TTL, consider Hazelcast or a small Memcached cluster (but those change the trade-offs). • Delivery guarantees: Redis Pub/Sub and NATS deliver messages to connected subscribers in real time. Direct broadcast requires you to implement retries/acks for machines that are temporarily unreachable. Recommendation recap • Use NATS if you want a managed pub/sub broker with minimal dev effort and very low latency. • Use direct broadcast if you want the cheapest, lowest-latency solution and are comfortable adding simple delivery/retry logic in your app. If you want, I can provide: • a minimal NATS publish/subscribe code example, or • a short HTTP/gRPC fan‑out example with retry/ack patterns. Which one would you like?, with interactive elements

• What happens if machine #3 restarts at minute 30? With pure pub/sub, it missed the original broadcast and has no way to learn the current token. • What if you scale to 6 machines later? The new one joins with empty state. • Is the token generated once and reused, or is there a stream of tokens?

Thanks — I’ll address each concern and show how to handle them for both recommended options (NATS and direct broadcast). Then I’ll state which small additions cover your edge cases. 1) Missed broadcasts on restart (machine #3 restarts at minute 30) • NATS (plain): If a subscriber is down during the publish, it misses the message and won’t learn the token. • NATS (JetStream): Use JetStream and publish the token as a message to a stream with a short retention window. When machine #3 restarts it can pull or consume the last message to recover the current token. • Direct broadcast: A restarted peer has no built‑in way to learn missed broadcasts. Mitigate by adding a lightweight recovery endpoint or pull flow (see below). 2) New nodes joining later (scale to 6 machines) • NATS (plain): New subscriber only receives future publishes. Use JetStream or a small bootstrap API to provide current token on join. • Direct broadcast: New node starts empty. Provide a bootstrap endpoint so new nodes request the current token from a designated node (or use leader election to find the source). 3) Token lifecycle: single reuse vs stream of tokens • If token is generated once and reused for the hour: simpler — you just need a way for nodes to learn the single current token and respect expiry. • If tokens are generated frequently (a stream): treat tokens as events. Streaming makes durability/replay (JetStream or a short-lived store) more useful so late joiners can catch up. Practical, minimal additions to cover your edge cases • Use ephemeral persistence for last-known token: ◦ NATS + JetStream with retention of the latest message (or max-age ~1h): solves missed broadcasts and new-joiners without full durable storage. ◦ Direct broadcast + small bootstrap API: pick one machine as the authoritative token provider (or use simple leader election). New/restarted nodes call GET /current-token on startup; the provider returns token+expiry. Keep the provider state only in memory. • Add idempotency and TTL: ◦ Include token ID and expiry in messages; subscribers ignore older tokens. ◦ Local in-memory cache on each node with app-handled expiry. • Simple health/retry: ◦ For direct broadcast, implement retries with exponential backoff and optional ACK from recipients. If a node is unreachable, the generator can retry or the restarted node can pull on boot. Recommended concrete choices given your constraints • If you want minimal infra and robust recovery with almost no dev work: NATS + JetStream, stream size = 1 message (or max-age = 1h). New/restarted nodes can read the latest message and subscribe for updates. • If you want zero extra servers: direct broadcast + bootstrap endpoint on one node. On restart or scale-up, nodes call the bootstrap endpoint to get the current token, then subscribe to future broadcasts. If you tell me whether tokens are single-per-hour or frequent streams, I’ll give a one-page implementation sketch for either: • NATS + JetStream config and sample publish/consume flow, or • Direct broadcast endpoints, startup pull logic, and retry/ack pseudocode. Which do you want?, with interactive elements

how about using this Valkey/KeyDB/Dragonfly

Thanks — I can compare Valkey, KeyDB, and Dragonfly for your token-sharing use case. I need two quick answers to keep the recommendation precise: 1. Are tokens single-per-hour (one active token at a time) or a frequent stream of tokens/updates? 2. Do you require that a restarted or newly joined node must recover the current token (yes/no)? Answer those and I’ll give a concise comparison and a clear recommendation. , with interactive elements

one token that should handle the app for one hour which will allow all the agents and callers to join no

Thanks — you said one token reused for 1 hour and restarted/new nodes do NOT need to recover past missed broadcasts. Given that, here’s a concise comparison and recommendation for Valkey, KeyDB, and Dragonfly as Redis alternatives for your use case. Quick summary (fit for a single 1-hour token, same region, low-latency) • KeyDB ◦ Fit: Good — KeyDB is a Redis-compatible, drop-in alternative with similar low-latency KV operations and optional multi-threading for higher throughput. ◦ Persistence/Recovery: Supports Redis-like RDB/AOF if needed, but can be run in-memory only. Missed pub/sub messages are not recoverable unless using persistence + read-on-join patterns. ◦ Operational cost: Similar to Redis; can run on same VM sizes. Slightly higher CPU utilization possible if you enable multi-threading. ◦ When to pick: If you want Redis compatibility (minimal code changes) and might want persistence/replication later. • Dragonfly ◦ Fit: Designed as a Redis-compatible, low-latency in-memory datastore optimized for modern workloads. Good raw performance for KV and pub/sub. ◦ Persistence/Recovery: Has persistence options; pub/sub is ephemeral like Redis (missed messages not auto-recovered). ◦ Operational cost: Comparable to Redis/KeyDB; performance efficiencies may reduce resource needs. ◦ When to pick: If you want high-performance Redis semantics and efficient memory/CPU use. • Valkey ◦ Fit: Not a direct Redis clone; if you mean lightweight key/value stores branded as Valkey, support and ecosystem vary. It may provide simple KV with low latency but fewer compatibility guarantees. ◦ Persistence/Recovery: Varies by implementation; may lack full Redis-like feature parity (pub/sub, TTL semantics). ◦ Operational cost: Potentially lower if very lightweight, but consider integration effort. ◦ When to pick: Only if you’ve vetted the specific Valkey implementation and accept less compatibility. How they compare to your needs (single token, no recovery required) • All three can serve as a low-latency in-memory KV to store the current token with TTL. For pure pub/sub delivery, they behave like Redis: subscribers that are down will miss broadcasts. • Because you don’t require recovery on restart/new join, a simple publish (or set+publish) and local in-memory caching on each node is sufficient. • If you want the simplest operational footprint and zero new infra, direct broadcast (HTTP/gRPC) is still cheapest. If you prefer a centralized in-memory store with Redis semantics (TTL, atomic set/get), KeyDB or Dragonfly are the closest drop-in choices. • Valkey may be viable only after confirming feature parity (TTL, atomic ops, pub/sub) and client support for your stack. Recommendation • If you want Redis compatibility with minimal code change: choose KeyDB. • If you want best-in-class performance with Redis API compatibility: choose Dragonfly. • If you prefer minimal infra and cost: keep direct broadcast or lightweight in‑memory KV on one node and have others pull on startup. If you want, I can: • Provide a minimal set+publish pattern and subscriber code for KeyDB or Dragonfly, or • Sketch the direct broadcast + startup pull flow (no new infra). Which would you like?, with interactive elements

one thing to note is i am deploying all of these on livekit cloud

Thanks — I’ll address this for LiveKit Cloud. Short answer: You cannot deploy custom services (Valkey/KeyDB/Dragonfly) inside the LiveKit Cloud managed environment. So you have two practical choices: • Host a small external broker/kv instance in the same region (recommended) ◦ Run KeyDB or Dragonfly on a small VM or container alongside your app infra in the same region. They provide Redis-compatible KV + TTL semantics and are drop‑in for set/get + publish patterns. ◦ Or run a lightweight pub/sub like NATS (recommended for pure broadcast) and keep token state only in memory on each LiveKit-connected app server. Use NATS to publish token updates; subscribers cache it locally and enforce expiry. ◦ Benefit: low latency (same region), TTL or pub/sub semantics, and you control availability. • Keep zero extra infra on LiveKit Cloud (cheapest, simplest) ◦ Use direct broadcast + bootstrap: the token generator fan‑outs token via HTTP/gRPC to your other app servers (or expose a bootstrap GET /current-token). Each server caches the token in memory and enforces expiry. ◦ Benefit: no new servers to run; minimal cost. Trade-off: you must handle retries/acks and leader/bootstrap logic. Recommendation for your single-token-for-1-hour use case: • If you want minimal dev work and Redis semantics (TTL, atomic set/get): host KeyDB or Dragonfly externally in-region and use set+publish. • If you want the simplest, lowest-cost option with minimal infra: use direct broadcast + a bootstrap endpoint on one node (app handles expiry). If you want, I can provide: • a tiny KeyDB or Dragonfly set+publish example, or • a direct broadcast + bootstrap HTTP/gRPC snippet and retry/ack pattern. Which would you like? Sources: Announcing LiveKit Cloud | LiveKit | Announcing LiveKit Cloud | LiveKit, with interactive elements

no i want you to give me all the available options based on what you know now

Thanks — I’ll list all viable options for sharing one token (valid ~1 hour) across your LiveKit Cloud-connected machines, given: same region, no persistence required, app handles expiry, and you can’t run services inside LiveKit Cloud. For each option I’ll give pros/cons, cost impact, and how it handles restarts/new nodes. 1) Direct broadcast (HTTP/gRPC fan‑out) • What: Token generator POSTs/gRPCs token+expiry to the other machines directly. • Pros: Zero extra infra, lowest cost and latency in‑region, simple. • Cons: You must implement retries/acks, idempotency, and bootstrap for new nodes. • Restart/new node: Add a bootstrap endpoint (GET /current-token) on one node so restarted/new nodes pull current token on startup. • Cost: Minimal (no new servers), CPU/network overhead on existing nodes. 2) Peer gossip / lightweight P2P • What: Nodes gossip token updates among themselves (UDP, libp2p, or gossip lib). • Pros: No broker, resilient, scalable to more nodes. • Cons: More complex to implement (membership, anti-entropy), eventual consistency. • Restart/new node: Anti-entropy / pull-on-join lets new nodes converge. • Cost: Minimal infra; dev effort higher. 3) NATS (plain) • What: Small NATS cluster for pub/sub; publisher sends token to subject; subscribers receive updates in real time. • Pros: Extremely low latency, easy pub/sub semantics, many clients, small cluster footprint. • Cons: Adds a broker to run; plain NATS does not persist missed messages. • Restart/new node: If down during publish, it misses the token (no recovery) — add bootstrap endpoint or use JetStream. • Cost: Low recurring cost for 1–3 small nodes. 4) NATS + JetStream • What: Same as above but use JetStream to retain last message (max-age ~1h or last‑msg). • Pros: Low latency + ability for restarted/new nodes to fetch the latest token on join without full persistence. • Cons: Slightly more resources/config; still lightweight compared to heavy brokers. • Restart/new node: Can consume the last message on startup to recover the token. • Cost: Low-to-moderate (small cluster). 5) Kafka • What: Durable distributed log used as pub/sub with retention. • Pros: Strong durability, ordering, and replay; good for high-scale streaming. • Cons: Higher operational cost and latency vs NATS; heavier to manage for a tiny workload. • Restart/new node: Can read latest message from topic on join. • Cost: Higher (more nodes, Zookeeper/Controller overhead or managed service cost). 6) RabbitMQ • What: Broker with exchanges (fanout/topic) to broadcast tokens. • Pros: Mature, flexible routing, can be clustered or federated. • Cons: More operational complexity than NATS for low-latency pub/sub. • Restart/new node: Missed messages if plain pub/sub — use queue/binding or persistent messages and a bootstrap flow. • Cost: Moderate (cluster nodes). 7) Redis (existing) / KeyDB / Dragonfly / Valkey (Redis-compatible stores) • What: In‑memory KV with TTL + pub/sub support. • Pros: Familiar APIs, TTL semantics, set/get atomicity, many client libs. • Cons: Pub/sub is ephemeral (missed messages), you’d still need bootstrapping for missed tokens unless you store the current token key and have nodes GET on start. • Differences: ◦ KeyDB: Multi-threaded Redis-compatible — drop-in, similar costs to Redis. ◦ Dragonfly: High-performance Redis-compatible alternative, efficient memory/CPU. ◦ Valkey: Community-driven Redis-compatible fork/variant — check parity and support. • Restart/new node: Use GET / key on join to read current token (store token with TTL); pub/sub only for updates. • Cost: Similar to Redis; moderate if you run a small instance in-region. If you already run Redis-compatible infra, minimal extra cost. 8) Managed cloud cache / pubsub (Firestore/Realtime DB, AWS ElastiCache, AWS SNS/SQS, Google Pub/Sub, Azure Service Bus) • What: Managed services offering KV/real-time or pub/sub/eventing. • Pros: No infra to manage, high availability, built-in SDKs. • Cons: Potentially higher cost, slightly higher network latency than in‑region brokers; varying semantics (SNS is pub/sub, SQS is queue). • Restart/new node: Use store read (Firestore/DynamoDB) or topic retention features to recover. • Cost: Varies—can be higher than self-hosted lightweight brokers for constant workloads. 9) Single authoritative KV on one app node (bootstrap + set+publish) • What: Keep token in memory on a chosen authoritative app node; others pull on startup and listen for pushes. • Pros: Zero extra servers, simple: authoritative node handles set and fan‑out. • Cons: Single point of failure unless you add failover/leader election. • Restart/new node: New nodes pull from authoritative node on join. • Cost: Minimal. Decision guidance for your constraints (one token for 1 hour, same region, no required persistence, app handles expiry) • Cheapest / simplest: Direct broadcast or single authoritative KV with a bootstrap GET endpoint. • Best balance of reliability and low operational overhead: NATS (1–3 node) or NATS+JetStream if you want automatic recovery of the last token. • If you want Redis API compatibility (TTL, get/set) with minimal code change: KeyDB or Dragonfly as an external in‑region instance; have nodes GET token on start and subscribe/publish for updates. Suggested immediate next steps I can provide • Minimal code snippet for Direct broadcast (HTTP/gRPC) with retry + bootstrap. • Minimal NATS publish/subscribe example (with JetStream bootstrap flow). • Minimal KeyDB/Dragonfly set+get+publish snippet. Which snippet would you like next? , with interactive elements

do one thing give me a summary for all that we have tried and why that is ruled out

Thanks — below is a concise summary of every option we discussed, what we tried, and why each was ruled out or kept given your constraints (LiveKit Cloud, same region, one token reused for 1 hour, app handles expiry, no services deployable inside LiveKit Cloud). Kept / recommended • Direct broadcast (HTTP/gRPC fan‑out) ◦ Why considered: Zero new infra, lowest latency, cheapest. ◦ Status: Kept. Recommended if you accept implementing simple retries/acks and a bootstrap GET for restarts/new nodes. ◦ Tradeoffs: You must handle delivery, idempotency, and bootstrapping yourself. • NATS (plain) ◦ Why considered: Lightweight, very low‑latency pub/sub; small infra footprint. ◦ Status: Kept. Good balance of low latency and developer ergonomics if you’ll run a tiny external broker in‑region. ◦ Tradeoffs: Missed messages on restart unless you add recovery. • NATS + JetStream ◦ Why considered: Adds ability to fetch the last message (max-age ~1h) so restarted/new nodes recover the current token. ◦ Status: Kept. Best if you want broker-backed simple recovery without heavy infra. ◦ Tradeoffs: Slightly more config/resources than plain NATS. • Single authoritative app node (bootstrap + set+publish) ◦ Why considered: No extra servers, simple bootstrap flow for new/restarted nodes. ◦ Status: Kept. Good zero-infra alternative if you accept a single-authority approach (add simple failover if needed). ◦ Tradeoffs: Single point of failure unless you add leader election. Kept but typically heavier than needed for your case • KeyDB / Dragonfly (Redis‑compatible stores) ◦ Why considered: Drop‑in Redis semantics (TTL, set/get, pub/sub) and low latency. ◦ Status: Kept as viable alternatives if you want Redis API compatibility. ◦ Tradeoffs: Requires running external instance; pub/sub is ephemeral (so use GET-on-start for bootstrapping). Operational cost similar to Redis. • Managed cloud cache / pubsub (Firestore, DynamoDB+SNS, Google Pub/Sub, ElastiCache) ◦ Why considered: Fully managed, reliable, built‑in SDKs and retention options. ◦ Status: Kept as an option if you prefer managed services and are okay with marginally higher latency/cost. ◦ Tradeoffs: Higher cost and potentially more latency than in‑region brokers. Ruled out (or not recommended) and why • Using Redis inside LiveKit Cloud ◦ Why considered: Matches your current Redis-based flow. ◦ Why ruled out: You cannot deploy custom services inside LiveKit Cloud managed environment — so Redis hosted inside LiveKit Cloud isn’t possible. External Redis still works but adds infra and cost. • Heavy streaming infrastructure (full Kafka cluster) ◦ Why considered: Durable replay/ordering if you had frequent streams. ◦ Why ruled out: Overkill for a single hourly token — higher latency, cost, and operational complexity. • Memcached (alone) for pub/sub replacement ◦ Why considered: Lightweight in‑memory KV. ◦ Why ruled out: No built‑in pub/sub and weaker feature set (no TTL events); would need extra broadcast mechanism, reducing benefit. • Valkey (uncertain) ◦ Why considered: Mentioned as a Redis alternative. ◦ Why ruled out/needs vetting: Valkey implementations and parity vary; must validate feature parity (TTL, pub/sub) and client compatibility before using. Not recommended without confirmation. Final practical recommendation (one line) • If you want absolute minimum cost/infra: Direct broadcast + bootstrap endpoint. • If you want simple, reliable low‑latency messaging with optional recovery for restarts: Run a tiny NATS cluster and use JetStream (max‑age ~1h) or plain NATS plus bootstrap endpoint. • If you want Redis API compatibility: Host KeyDB or Dragonfly externally and use set-with-TTL + GET-on-start + publish for updates. If you want, I’ll now produce a minimal implementation snippet for any one of these (direct broadcast, NATS + JetStream, KeyDB/Dragonfly set+get+publish). Which one should I show? , with interactive elements

but these cannot be used on livekit cloud so how can you say that its a possible option

Thanks — good point. You’re right: you cannot run custom services inside the LiveKit Cloud managed environment. I’ll be explicit and practical. What is NOT possible inside LiveKit Cloud • You cannot deploy Redis, KeyDB, Dragonfly, NATS, Kafka, or any custom broker inside the LiveKit Cloud managed runtime. What is possible and practical given that constraint • Host the cache/broker externally in the same region as your app and LiveKit edge (recommended). Options: ◦ Run a small external NATS cluster (or NATS+JetStream) in-region for low-latency pub/sub. ◦ Run an external KeyDB or Dragonfly instance in-region for Redis-compatible KV + TTL. ◦ Use a managed cloud cache/pubsub (ElastiCache, Memorystore, Google Pub/Sub, Firestore, DynamoDB+SNS) in the same region. • Zero-infra alternative (runs entirely on your app nodes): ◦ Direct broadcast / authoritative node + bootstrap endpoint: token generator fan‑outs token to your app servers (HTTP/gRPC) and new/restarted nodes pull from the bootstrap endpoint on start. Why these are the practical options • LiveKit Cloud is managed and won’t host your custom services; but LiveKit Cloud edges and your app servers are reachable from same-region infra you control. • Running an external lightweight broker or cache in the same region preserves the low latency you need while keeping infra separate from LiveKit Cloud. • If you want zero extra infra cost, the direct broadcast + bootstrap pattern achieves the requirement with no external servers. Recommended next steps (pick one) • If you want reliability + minimal dev work: I’ll give a small NATS + JetStream setup and sample publish/consume flow (max-age ≈ 1h). • If you want Redis API compatibility with minimal code change: I’ll give KeyDB/Dragonfly set-with-TTL + GET-on-start + publish example. • If you want zero infra: I’ll give a direct broadcast + bootstrap HTTP/gRPC snippet with retry/ack patterns. Which of these three do you want the implementation snippet for? , with interactive elements

Recommended next steps (pick one) • If you want reliability + minimal dev work: I’ll give a small NATS + JetStream setup and sample publish/consume flow (max-age ≈ 1h). • If you want Redis API compatibility with minimal code change: I’ll give KeyDB/Dragonfly set-with-TTL + GET-on-start + publish example. • If you want zero infra: I’ll give a direct broadcast + bootstrap HTTP/gRPC snippet with retry/ack patterns. is thats not possible on livekit cloud then why these options again

You’re right to call this out — thanks. Quick, clear answer: • You cannot run custom services (Redis, KeyDB, Dragonfly, NATS, Kafka, etc.) inside LiveKit Cloud. Those were suggested as viable alternatives only if you host them yourself outside LiveKit Cloud (in the same region) or use managed cloud services. Practical, feasible choices given LiveKit Cloud • Host externally (same region) — low latency, recommended: ◦ Run a small NATS (or NATS+JetStream) cluster externally for pub/sub. ◦ Or run an external KeyDB/Dragonfly instance for Redis-like KV + TTL. ◦ Or use a managed cloud cache/pubsub in the same region (ElastiCache, Memorystore, Firestore/DynamoDB+SNS, Google Pub/Sub). ◦ These are feasible because LiveKit Cloud edges and your app infra can reach services you run in-region. • Zero-infra option (fully possible inside your app infra): ◦ Direct broadcast / authoritative node + bootstrap endpoint: generator fan‑outs token to your app servers and new/restarted nodes pull from bootstrap. No external broker needed. Why I kept suggesting external brokers earlier • They match the pub/sub or KV+TTL semantics you wanted with low latency; I assumed you could host them externally. That assumption is valid only if you accept running them outside LiveKit Cloud (in your cloud account/region). What I’ll do next • I won’t re-suggest in-Cloud deployment of these services. Tell me which of the two realistic paths you want to implement now: ◦ External service (NATS + JetStream or KeyDB/Dragonfly) — I’ll give a concise deployment + code snippet for publish/subscribe or set/get+publish. ◦ Zero-infra direct broadcast + bootstrap — I’ll give a concise HTTP/gRPC snippet with retry/ack and startup pull. Which one do you want? , with interactive elements