Closer to every show: our summer network upgrade
PulseMesh time servers now run in four regions and songs are cached at hundreds of edge locations, so phones lock on faster, hold sync more steadily, and load songs quickly on your busiest night. Nothing to install or update.
PulseMesh Team
Over the summer we rebuilt the two parts of PulseMesh that sit between your show and a viewer's phone: the time servers that keep every phone on your show's timeline, and the network that delivers your songs. Both now live much closer to wherever your display is.
There's nothing to install or update. If you run a show on PulseMesh, it's already working for you.
Why distance matters for sync
A phone works out where it is on your show's timeline by trading quick timing messages with a PulseMesh time server, and it keeps doing that for as long as it's listening. Every one of those messages has to cross the internet and come back. The longer and bumpier that trip, the noisier each measurement is and the longer it takes a phone to settle.
Until this summer, every PulseMesh time server was in the US. For a display in the UK or Australia, every timing message crossed an ocean and back.
Time servers in four regions
PulseMesh time servers now run in Los Angeles, Virginia, Germany and Australia, and phones reach a nearby one automatically. Shorter trips mean phones lock onto your show faster when a viewer arrives, and hold sync more steadily while they listen.
The player also doesn't bet everything on a single server. It tries more than one and keeps whichever answers best, so a slow path or a busy server doesn't leave a viewer stuck. We'll add regions as traffic grows.
Your songs live near your show
PulseMesh delivers your songs to each phone ahead of playback, so the network isn't in the critical path when the music starts. That means how fast a song arrives decides how quickly a new viewer is ready to listen.
Songs used to come from a single US datacenter. Now they're cached across a global edge network with hundreds of locations, so there's one close to your display. The first time a song is played in an area, the nearby cache fills; after that, phones near your show are served from it. Songs load fast and stay fast, even on your busiest night, when a street full of cars all tune in at once.
Proven at scale in July
This is the network that ran the fireworks show at the 2026 National Jamboree on July 26: an open-air event with about 12,000 people watching, spread across a large site on event Wi-Fi and three different cellular networks. At the peak, 1,291 devices were playing the soundtrack in sync.
The full field report covers what the site was like, how the audio held together, and how we count those numbers.
For the technical folks
- Anycast time servers. One address, announced from every region, so each phone's traffic lands on a nearby server.
- WebTransport first, WebSocket fallback. Phones sync over WebTransport (QUIC over UDP) where the browser and network allow it, and fall back to WebSocket over TCP where they don't.
- Endpoint racing. The player fetches a small config listing the servers it may use, tries more than one, and keeps the best. That config is also how we add regions or shift traffic without shipping an app update.
- Audio at the edge. Songs are served through Cloudflare Workers with edge caching in front of our storage.
What's next
More regions as traffic grows, and more updates over the next few weeks as we head into the holiday season. If you have questions about how any of this works for your display, get in touch.