Castopod: self-hosted podcast publishing with Podcasting 2.0 features
Castopod is an open-source hosting platform made for podcasters who want engage and interact with their audience. Synchronized read-only mirror of https://code.castopod.org/adaures/castopod
At a glance
- What is it?
- Castopod is an AGPL-3.0 podcast hosting platform written in PHP on CodeIgniter 4, positioned for podcasters who want to own their feed and use Podcasting 2.0 features rather than rent space from a commercial host.
- Who is it for?
- Castopod fits podcasters who are comfortable running a PHP application and want their feed, analytics and audience interaction on infrastructure they control, and it fits engineers evaluating Podcasting 2.0 tooling. It does not fit anyone who wants a managed host with no server to maintain, or a team without PHP deployment experience.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 102 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Castopod is for, and who it is not for
Castopod is a podcast hosting solution, not a podcast player, editor or directory. The repository describes it as free and open-source software aimed at podcasters who want to engage and interact with their audience, and the topic list on the repository includes analytics, hosting, self-hosted and podcasting20. That combination is the pitch: you run the server, you keep the feed, and you get audience-facing features that a plain static RSS file does not offer.
The audience is narrower than "podcasters" as a group. Someone who publishes two episodes a month and has no interest in server administration is not the target reader of a PHP application with a database and a web root. The realistic adopter is a podcaster or small network that already pays for a VPS, or an engineer who wants a working Podcasting 2.0 implementation to inspect. The repository topics point at the same conclusion: self-hosted and hosting appear alongside podcasting20, so the project assumes you are supplying the machine.
One structural detail matters before anything else. This GitHub repository is a synchronized read-only mirror of the project's own GitLab instance at code.castopod.org. The README states plainly that any contribution made on a repository other than the original will not be accepted. If you intend to send patches, open issues or propose changes, the mirror is the wrong place to do it. The mirror is useful for reading the code and the licence, not for participating.
The stack you are actually deploying
The primary language is PHP, and the topic list names codeigniter4, so the application is built on the CodeIgniter 4 framework rather than on a bespoke router or a Symfony or Laravel base. That choice has practical consequences for anyone maintaining it. CodeIgniter 4 has its own conventions for routing, configuration files, migrations and the service container, and a developer who knows Laravel will not transfer that knowledge automatically. Expect to read CodeIgniter 4 documentation alongside the Castopod code.
The README says Castopod comes pre-packaged with all the required static assets and dependencies. Read that carefully, because it changes the deployment shape. You are not being asked to run a JavaScript package manager or a front-end build pipeline before the application will render. The release artifact is intended to be dropped onto a server and configured, which is a deliberate trade-off: simpler installation for the operator, at the cost of a larger download and a build step that happens upstream rather than on your machine.
The default branch is develop. That is the branch a clone gives you, and it is also the branch most likely to carry unreleased work. Anyone deploying from a clone rather than from a packaged release should treat develop as a moving target and pin to a tag or a packaged archive instead. The material supplied here does not include release tags, so the exact release cadence cannot be confirmed from what is available; the getting started page is where that information lives.
Getting it running: what the repository will and will not tell you
The README does not contain an installation procedure. It points to the getting started page at castopod.org, and that is the only installation route the repository documents. This review has not installed or run Castopod, so the following is what the supplied material supports, not a verified walkthrough.
What the repository does establish: the project is PHP, it targets CodeIgniter 4, it ships with its static assets and dependencies already bundled, and the default branch is develop. The practical sequence implied by those facts is to obtain a packaged release, place it on a PHP-capable host with a database, and complete configuration through the application. The specific commands, the required PHP version, the supported database engines and the environment variable names are not present in the material available here, and inventing them would be worse than admitting the gap.
There is one command-shaped detail worth flagging for contributors rather than operators. The README references a CONTRIBUTING.md file in the repository root for contribution guidelines, and it directs security reports to security@castopod.org rather than to a public issue tracker. If you find a vulnerability, the documented path is email, not a public issue on the mirror. That is a normal arrangement for a self-hosted application where a published exploit affects every deployment at once.
For anyone planning a deployment, the honest advice is to read the getting started page before provisioning anything. The requirements listed there determine your base image, your PHP extensions and your database choice, and those decisions are expensive to reverse after the site is live.
Where Castopod's model creates friction
Self-hosting a podcast means you inherit the parts a commercial host absorbs. Feed availability is now your uptime problem. If the server is down when a directory crawler fetches your RSS, that is a failed fetch on your record, not a support ticket. Media files are large and long-lived, so storage and bandwidth costs scale with your back catalogue rather than with your listener count, and a popular episode can produce a bill that a flat-fee host would have absorbed.
The mirror arrangement adds a second kind of friction. Because the GitHub repository is read-only and synchronized from code.castopod.org, the usual GitHub workflow does not apply. You cannot open a pull request against it. You cannot file an issue there and expect a maintainer to triage it. Anyone who finds the project through GitHub search and starts working against that mirror will discover the constraint only after writing code, which is a poor first experience and a documentation problem the project has chosen not to solve in the README beyond a single warning block.
Licensing is the third constraint, and it is the one most likely to be underestimated. Castopod is AGPL-3.0. The AGPL extends copyleft to software offered over a network, so operating a modified Castopod as a public service is not the same as running a modified MIT-licensed tool privately. This review is not legal advice and cannot tell you what your specific obligations are. What can be said is that the licence is a deliberate choice by the project, and any organisation that plans to modify the code and expose it to users should read the licence text and, where the stakes justify it, take proper advice before building on it.
How Castopod differs from a static feed plus a CDN
The alternative most podcasters actually run is not another hosting platform. It is a generated RSS file and a set of audio files sitting in object storage behind a CDN, with a static site generator or a small script producing the feed. That setup has real advantages: it has almost no attack surface, it costs roughly what storage and egress cost, and it will still serve a valid feed in five years without a framework upgrade.
The difference in approach is where the audience interaction lives. A static feed is a one-way artifact. Everything that happens between the podcaster and the listener, including analytics, comments, and the Podcasting 2.0 features the repository's topic list points at, has to be bolted on through third-party services or omitted entirely. Castopod puts those functions inside the application, which is why it needs a database and a running PHP process. That is the trade: operational weight in exchange for features that a static file cannot express.
A second alternative is a managed podcast host. Those remove the server from your plate entirely and typically bundle analytics and distribution. The difference is ownership and exit cost. With a managed host, your feed URL belongs to the provider and migrating means a redirect and a period of uncertainty. With Castopod, the feed is on a domain you control. For a podcaster whose audience is their business, that distinction is often the deciding factor, and it is the strongest argument the project has.
Maintenance, upgrades and the cost of running develop
The maintenance burden of a self-hosted PHP application is not the code, it is the runtime. PHP versions reach end of life on a published schedule, and a CodeIgniter 4 application has to move with them. Database engines get major versions. TLS certificates expire. None of this is specific to Castopod, but Castopod is the thing that will break when it happens, and the person who fixes it is you.
Upgrades are the sharper edge. The README says the packaged distribution includes all required static assets and dependencies, which means an upgrade is not a matter of pulling source and running a package manager. It is a matter of replacing the application tree and applying whatever database migrations the new version ships. The material available here does not describe a rollback procedure or a migration policy, and that absence is worth noting for anyone running a production feed. Before upgrading, take a database dump and keep the previous application directory, because a feed that fails to render is a feed that directories will drop.
The default branch being develop compounds this. If you deploy from a clone of develop, you have opted into unreleased code with no version boundary. Deploying from a tagged release, or from the packaged distribution the README describes, gives you a fixed target and a changelog to read. That is the difference between running software and running a branch.
On licence cost: AGPL-3.0 means no per-seat or per-episode fee, which is the financial argument for self-hosting. The cost moves to infrastructure and to the hours you spend on it. Whether that is cheaper than a managed host depends entirely on how you price your own time, and no benchmark in this material can answer that for you.
Editorial conclusion
Castopod fits podcasters who are comfortable running a PHP application and want their feed, analytics and audience interaction on infrastructure they control, and it fits engineers evaluating Podcasting 2.0 tooling. It does not fit anyone who wants a managed host with no server to maintain, or a team without PHP deployment experience. Before adopting it, verify the current installation steps on the getting started page at castopod.org, confirm the PHP and database versions your target release requires, and read the AGPL-3.0 text to understand what publishing a modified Castopod obliges you to do.
Community notes