Radio hosting for a station that never stops broadcasting.
A podcast site serves files. A radio site sits in front of something continuous, and the page has to keep up with what is happening right now.
Continuous, not on demand.
Everything here differs from on-demand audio because nothing has a beginning, an end, or a fixed URL.
The stream never touches the application
Listeners connect to the streaming server directly. The website hands them a link rather than proxying audio, so a thousand listeners cost the origin nothing at all.
Now-playing polling as primary traffic
Every open player asks what is on every few seconds. That polling outweighs page views by a wide margin and is answered from cache rather than by a database query.
A schedule that turns over on the hour
The current-show panel changes at fixed times whether or not anyone visits. It is driven by a scheduler, so the site is not showing the previous programme at ten past.
Requests and competitions arrive in bursts
A presenter mentions a form on air and it receives a few hundred submissions in ninety seconds. That is a write spike triggered by something invisible to your metrics.
Catch-up alongside the live stream
Recorded shows and podcasts sit next to the live feed as ordinary large media, served from the edge rather than through PHP.
The site tracks something live.
A station's website is a window onto a broadcast. Its correctness is measured in minutes, and its traffic is mostly players asking for an update.
- Listeners handed to the streaming server directly
- Now-playing responses cached with a short lifetime
- Schedule turnover driven by a scheduler
- Catch-up media served from the edge
More metadata requests than pages.
The busiest endpoint on a radio site is not a page. It is whatever the player asks every few seconds, multiplied by everyone listening.
What we change for radio sites
The defining fact is that the interesting content is happening elsewhere, continuously, and the site reports on it.
| Setting | What we do | Why |
|---|---|---|
| Stream delivery | Listeners connected directly to the streaming server | Proxying continuous audio through the application holds a worker per listener for as long as they listen, which no pool survives. |
| Metadata endpoint | Cached with a lifetime measured in seconds | Every open player polls for the current track, so that endpoint receives more requests than the rest of the site combined. |
| Schedule turnover | Driven by a scheduler rather than by page views | The current-show panel must change at the top of the hour whether or not anybody happened to load a page at that moment. |
| On-air submission bursts | Capacity allowed for presenter-triggered spikes | A mention on air produces hundreds of form submissions in under two minutes, from an event that never appears in web analytics beforehand. |
| Catch-up media | Served from the edge as large static files | Recorded programmes are the same delivery problem as any large audio file and should not compete with the live site for workers. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Does the audio stream run through my website?
Why is my site slow with only a few hundred listeners?
My schedule shows the wrong programme. Why?
What happens when a presenter mentions a competition on air?
Keep up with what is on air.
Move the station site across - migration is free, catch-up archive included.