Castopod

Last reviewed Sep 13, 2026 · 850 words

Castopod solves the other podcast problem. Every popular self-hosted "podcast" app is a player for shows other people make; Castopod is the thing that makes the show, hosting your audio, generating the RSS feed that Apple Podcasts and Spotify pull from, counting downloads to the IAB standard, and publishing every episode to the fediverse as a post people can reply to from Mastodon. If you are a listener, close this tab and go to Audiobookshelf. If you produce a show and are paying Buzzsprout or miss what Anchor used to be, the 1,000-star project is the serious open-source answer, and it has two setup decisions that cannot be undone casually.

The stack is ordinary PHP, which is a compliment

Castopod is a CodeIgniter 4 application: PHP, MariaDB or MySQL, and an optional Redis for caching. The official Docker image bundles PHP-FPM and the app, so a compose file is the app container, a database container and your reverse proxy. The catalogue's "requires database setup" is the whole of the extra work. Give it the 1 GB of RAM listed and it idles well under that; transcoding is not something it does, since you upload finished MP3s.

The environment variables that matter on first boot are the database credentials, CP_BASEURL, and CP_ANALYTICS_SALT. Generate the salt once with something random and never rotate it, because it is what turns listener IPs into the anonymised identifiers behind your download counts; change it and your unique-listener history breaks.

Pick the base URL as if it were permanent

CP_BASEURL becomes the domain in every enclosure URL in every RSS feed you publish. Podcast directories cache those URLs, listeners' apps have already downloaded from them, and your ActivityPub identity is bound to that domain. Moving from pod.example.com to example.com/podcast later is possible with redirects, but every link ever shared points at the old host. Decide the domain, get HTTPS in front of it with Caddy or whatever you already run, and only then create the first podcast.

The same permanence applies to the show's feed URL. Directories let you change it, but every change is a redirect you must maintain forever.

Federation is the feature nobody else has

Each podcast on your instance is an ActivityPub actor. Publishing an episode publishes a post; anyone on Mastodon can follow @[email protected], boost it, and reply, and those replies appear as comments under the episode on your site. No other hosting platform, free or paid, does this natively. It also means your instance is a small fediverse server with all that implies: an inbox that receives remote activity, and a reason to keep the software updated.

Podcasting 2.0 support is the other reason people choose it over the incumbents: chapters, transcripts, per-episode persons, funding tags, and value-for-value entries all go straight into the feed, and Castopod tracks the namespace closely because the project's maintainers are involved in it.

Analytics without a tracker

Download statistics are computed server-side from requests to the audio files, filtered and deduplicated in line with the IAB podcast measurement guidelines, which is the number sponsors ask for. You get listeners per episode, per country, per app, and per platform without a cookie or a third-party pixel. This only works if the audio is served through Castopod. Which brings up the bill.

Bandwidth is the real cost of leaving a host

A show with 2,000 downloads per episode of a 50 MB file moves 100 GB per episode. Four episodes a month is 400 GB, which is fine on a dedicated server with unmetered transfer and a bad idea on a home connection or a cloud VM charging per gigabyte. Castopod can store media on S3-compatible storage, which spreads the cost, but make the arithmetic before you migrate a show with an audience. This is the thing hosted platforms actually sell you: not the upload form, the egress.

Migration in is a feed import: point Castopod at your existing RSS and it pulls episodes, artwork and metadata. Migration out is the same feed the other way, and your data is in a MariaDB database and a media folder you can read. Compared with the media server category at large, this is one of the more portable setups.

What I'd do

Host Castopod on a VPS or dedicated box with generous transfer, not at home. Fix the domain first, set the analytics salt once, put Caddy in front, and import your existing feed before announcing anything. Turn on federation and post the show's fediverse handle in the episode notes. If your audience is small, the whole thing costs a database and a few euros of server a month. If it grows past a few thousand downloads per episode, move media to object storage and keep the app where it is. For a producer, it is the best self-hosted option and not a close call; for a listener, it is the wrong category.