Castopod

Qué obtienes

• Los 3 servicios aprovisionados juntos: castopod, castopod-db, castopod-redis
• Desplegada de extremo a extremo y verificada por el equipo de Railyard
• HTTPS automático y despliegues sin downtime

Cómo desplegar Castopod

1. 1

   Conecta un servidor

   Conecta un servidor de DigitalOcean, Hetzner o Vultr a Railyard, o cualquier servidor Linux por SSH.

2. 2

   Haz clic en "Desplegar Castopod"

   Railyard construye el contenedor y aprovisiona los 3 servicios.

3. 3

   Configura tu dominio

   Apunta tu dominio a la app. Railyard emite un certificado HTTPS y lo renueva automáticamente.

Por qué desplegar en Railyard

Railyard aprovisiona los 3 servicios de este stack juntos — castopod, castopod-db, castopod-redis — conectados para hablarse por la red privada, en un servidor que ya pagas.

Desplegar Castopod es una pieza de un stack más grande que puedes seguir construyendo — agrega una base de datos, un worker, un cache, u otra app, todo en los mismos servidores que ya pagas.

Ideal para

• 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

Bueno saber

• 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.

Preguntas frecuentes

Plantillas relacionadas