Live casino software
that feels like the floor.

Atmosphere, at scale

Live casino is the fastest-growing part of iGaming because it brings back the social, human feel players miss online. We build the streaming, the interaction layer and the studio integrations that hold the round together — one authoritative game state, one bet window, whatever the player's connection is doing.

Run your own studio or plug into a provider — either way it sits on your platform and wallet.

Live dealer is a broadcast product with a betting engine attached

Every other vertical we build is a game-server problem: slots and table games put the outcome on the server, the client draws it, and the hard parts are throughput and correctness. Live casino is not that. The round happens in a room, in front of a camera, and the software has to carry it to thousands of people fast enough that they can all bet on it fairly. That is a broadcast problem. The stream and the game are two different systems; confusing them is the mistake that costs money.

Where the delay actually comes from

The path is capture → encode → ingest → transport → edge → player, and every hop spends time you do not get back. Encoding needs frames before it emits anything; an adaptive ladder makes the origin render every rung; then the public internet does whatever the player's carrier is doing that evening. Two hops matter more than teams expect:

• Edge delivery. Segmented HTTP delivery quantises time. A player holding a few segments is behind by construction, not by accident.
• The player's jitter buffer. Usually the largest single block of delay, and the one nobody budgets for. It hides network variance by being late.

Latency is a budget: every addition — an extra rung, DRM, a watermark, a hop for compliance recording — draws on the same account.

Why sub-second is the requirement, not low latency

Low latency is a marketing phrase. On a football stream, everyone being twenty seconds behind together is fine — nobody is racing anybody. A live table is different: the betting window closes, and any spread between two players watching the same wheel is an exploitable gap. Two seconds of spread is a two-second arbitrage window against a table you own.

That rules out a transport class. Segment-based delivery — HLS, DASH and relatives — is cache-friendly, cheap and resilient, but its delay floor is segment length times buffer depth, and no tuning brings that into conversational range. WebRTC-class transport delivers at frame granularity with no segment quantisation, which is what a betting window needs. It costs more to run, for reasons the bandwidth section below gets into. You are buying time with money — and on a live table, that is a fair trade.

The server clock settles the round, not the video frame

The most common design error in live casino is treating the stream as the source of truth. The video is a rendering of the round. It is not the round.

Authoritative state lives on a game server with its own timeline: bets open, bets close, result read, result settled. Clients receive those transitions over a separate real-time channel, not by watching pixels. The countdown is drawn against a clock synced to the server, and the server stamps every bet on arrival — anything landing after the close is rejected, whatever the player's screen was showing.

Get it backwards and the player with the fastest stream gets extra thinking time, while the player on a slow connection can be shown a wheel that has already stopped somewhere else. That is not a UX complaint. It is arbitrage on your own table, and the kind of finding that ends a certification conversation early. Two consequences:

• Video aligns to state, never state to video. The UI holds the reveal until the state says a result exists. Late video is a comfort problem. Late state is a liability.
• Client clocks are not evidence. Devices sleep, clocks skew, some clients are hostile. Server-side arrival time is the only timestamp that settles money.

Late-bet policy needs an engineering answer before launch, not after the first complaint: reject silently, reject with a message, or roll into the next round. Pick one, encode it, apply it identically every time.

Reading the physical table

Something has to turn a card face and a wheel pocket into a value the wallet can settle against. Two families of signal do that: optical — cameras and computer vision reading card ranks and wheel sectors — and sensor: a shoe that reads each card as it is drawn, an encoder on the wheel rotor, RFID in the chips. Credible setups run both, because the rule that matters is dual confirmation: never settle on one signal. Take the automated read and an independent second source — a second sensor, or a dealer confirmation on the pit terminal. Agreement settles. Disagreement stops the round.

What happens when the read is wrong

A misread cannot be resolved by whoever is nearest the keyboard. It needs a defined, logged, deterministic path: the round pauses, the pit is alerted, and the round is either corrected before settlement with a full audit trail, or voided with all stakes returned. Dealer error is the same class of event — an exposed card, a no-spin, a ball off the track — and resolves under the game rules you published, identically every time, because "we decided in the moment" is not a defence you can offer a regulator or a player.

So everything is recorded: the frame, the read, the confirmation, the operator who touched it, the settlement. When a player disputes a round six weeks later, the answer has to be a record, not a memory — the same discipline as KYC and AML controls. Treat void and rerun rules as part of the product spec, and confirm the detail per market against its gambling regulations and your test house.

A slot costs nothing to leave running. A live table burns a dealer's shift, a pit position, a studio bay, encoders and a floor manager — whether two people are seated or two thousand. So the number that governs live casino is not RTP or GGR in isolation. It is utilisation: bet volume per table-hour. The levers are mostly operational.

• Unlimited-seat formats scale; seat-limited ones do not. Roulette, baccarat and game shows take any number of viewers on one table hour. Blackjack has boxes — bet-behind is how you attach more players to the same hour.
• Shifts follow markets, not clocks. A table serving one time zone is idle most of the day. Rotas aligned to your markets' peaks are how a fixed cost earns, and table opening should follow live concurrency rather than a schedule set at launch.
• Clean handovers. A 24/7 table is a rota. Dealer changeover has to be a state transition the software understands, not a cut mid-round.

We build custom platforms. Here is where buying still wins.

We do not take a revenue share, and on the casino, the sportsbook and the platform itself we will argue for owning it nearly every time — custom development vs white-label sets out that argument in full.

Live casino deserves a straighter answer. A studio is capital: rooms, tables, lighting, cameras, encoders, redundant links, dealers, pit staff, rota management, and a licence position for the studio itself. Shared third-party tables are already built, staffed and certified, and your marginal cost is a share of the play you send. If you are launching, your live volume is modest, or you are probing a new market, shared supply is the right call — and anyone telling you otherwise is selling you a studio. The build case shows up at volume, and rests on branding and control of the game rules.

One thing should not be rented either way: the platform around the table. The wallet, sessions, bonus engine, responsible-gaming triggers and reporting are your business logic. A live supplier should plug into your platform, never be the reason it belongs to someone else. Rent the table hour if the maths says so. Own the platform regardless.

Bandwidth is a running cost with a multiplier on it

Video egress scales with concurrency and never sleeps: cost tracks bitrate times concurrent viewers times hours. Push a premium rung to everybody and you have multiplied the bill by the ratio of the rungs, for a picture most players are watching on a phone. The ladder is a commercial decision as much as a technical one — serve the rung the device and network can actually use.

This is where real-time transport bites. HTTP caches are cheap because one origin stream fans out to thousands; media servers do not cache like that, so capacity is planned in concurrent viewers per region, not total registrations — an infrastructure decision with a monthly invoice attached. Two things follow. Put media edges near players, not near the studio: a player in São Paulo watching a European studio through a European edge pays for the Atlantic twice. And idle tables should stop costing money — a table nobody is watching still encodes and still egresses if you let it.

The player on a bad connection still has to be able to bet

The failure everyone designs for is the studio going down. The failure that actually happens is one player's train entering a tunnel. In a live round the priority order is: keep the bet, keep the state, keep the audio, then keep the picture — not the reverse.

• The state channel is separate and light. It survives conditions the video cannot. If the picture drops, the player still sees table state, the countdown and their own bet. A working table with no video beats a frozen video with no table.
• Drop rungs early rather than buffer deeper. Inside a betting window an ugly picture is fine; a stale one is not.
• Reconnect into current state, never into a replay. The client asks the server which round it is and renders that. Resuming the stream from where the player left off would show a round that has already settled — and take bets on it.
• Bets in flight need one definite answer. Idempotency keys on placement let the client re-ask without staking twice.

When the table itself fails — encoder dies, studio link drops mid-shoe — the same void rules apply, driven by the state machine rather than the player. Video going away must never leave money in an undefined position.