← Modèles · Applications
CA
Castopod
Vérifié3 services
Castopod, the open-source podcast hosting platform — publish episodes, track real analytics, and own your RSS feed instead of renting it.
| S'exécute | 3 services |
|---|---|
| Pile technique | castopodcastopod-dbcastopod-redis |
| Provisionné pour l'application | Rien, l'application est autonome |
| Vérifié | Oui, déployé de bout en bout par l'équipe Railyard |
Pourquoi déployer sur Railyard
Railyard provisionne les 3 services de cette pile ensemble — castopod, castopod-db, castopod-redis — câblés pour se joindre sur le réseau privé, sur un serveur que vous payez déjà.
Déployer Castopod n'est qu'un élément d'une pile applicative que vous pouvez continuer à faire grandir — ajoutez une base de données, un worker, un cache ou une autre application, toujours sur les mêmes serveurs que vous payez déjà.
Idéal pour
- Self-hosted podcast hosting with your own RSS feed and real listener analytics
- Podcasting 2.0 features (transcripts, chapters, value4value) without a third-party host
Bon à savoir
- MariaDB and Redis are wired up automatically
- HTTPS is required by default (mandatory to federate with the fediverse) — Railyard terminates TLS in front of this app, so that's already satisfied
- Uploaded media lives on a dedicated volume — plan real disk space for audio files
- Its own image runs as non-root (www-data) and needs to chown /run on boot — disable_no_new_privileges is required or the container fatals out (s6-overlay-suexec: child failed with exit code 100), same class of fix as Jitsi's services
- Castopod's own image already generates its real .env from the documented CP_* env vars this template sets (s6-overlay's prepare-environment.sh bootstrap script runs on every boot) — no Railyard config-writing primitive needed. An earlier investigation wrongly concluded CP_* names were incompatible with Castopod's dotted-key config; that was based on a flawed diagnostic (`railyard run` spins up a brand-new one-off container, not an exec into the live one, so its own entrypoint — and the .env generation — never ran). The only real bugs were disable_no_new_privileges (above) and a MariaDB container occasionally getting killed mid-first-boot under heavy host CPU contention (interrupts user/grant creation, producing 'Host X is not allowed to connect' until the volume is wiped and redeployed clean) — confirmed live end to end: a real HTTP 200 with the real page title.