Podcast hosting where the feed never goes down.
For a podcast the most-requested URL is not a page. It is the feed, polled relentlessly by apps that never read a word of your site.
The feed is the product.
Everything a podcast site does at scale happens at two URLs: the RSS feed and the audio file.
A feed polled by thousands of apps
Podcast clients re-fetch your feed on a schedule whether or not anything changed. Answered from cache with correct validators, most of those requests never wake WordPress at all.
Audio that streams, not downloads
Episodes are served with range requests, so a player fetches the part it needs and can seek without pulling the whole file. Nothing occupies a PHP worker while somebody listens.
Release day handled at the edge
A new episode brings a burst as apps notice at once. That burst hits the edge cache rather than the origin, so publishing is uneventful.
Storage that grows with the back catalogue
A weekly show is a few gigabytes a year and never shrinks. Storage is part of the plan and can be topped up without moving anything.
Show notes recoverable
The audio may live elsewhere, but the episode posts, transcripts and artwork live here - and are in the daily backup.
Apps are your biggest audience.
Most of your traffic is software rather than people: clients polling a feed on a timer. It is the cheapest traffic to serve correctly and the most expensive to serve badly.
- Feed answered from cache and revalidated cheaply
- Audio streamed with seek support
- Storage sized for the back catalogue
- Release-day polling absorbed at the edge
One feed, thousands of pollers.
Podcast traffic is repetitive by design, which makes it almost entirely cacheable - provided the feed sends the headers that let a client skip the download.
What we change for podcasts
Two URLs carry almost all the load, and both are static between publishes.
| Setting | What we do | Why |
|---|---|---|
| Feed caching | Cached with validators, purged on publish | Podcast clients poll on a timer regardless of changes, and a correctly validated feed answers most of those without rendering anything. |
| Audio delivery | Range requests, served from the edge | Without range support a player cannot seek, and every listen ties up a worker for the length of the episode. |
| Storage | Sized for a growing back catalogue | Archives only ever get bigger, and a show that has to delete old episodes has a hosting problem rather than an editorial one. |
| Publish purge | Feed and episode page only | A release should invalidate the two things that changed, not discard every warm cache entry on the site. |
| Artwork | Optimised on upload | Cover art is delivered large to directories and small to players, from one original. |
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.
Should I host the audio files here?
Why is my feed slow when the site is fine?
What happens on release day?
Can listeners skip ahead in an episode?
Publish without watching the dashboard.
Bring the show across. Migration is free, back catalogue included.