Castopod

O que você ganha

• Todos os 3 serviços provisionados juntos: castopod, castopod-db, castopod-redis
• Deploy de ponta a ponta feito e verificado pela equipe do Railyard
• HTTPS automático e deploys sem downtime

Como fazer deploy de Castopod

1. 1

   Conecte um servidor

   Conecte um servidor DigitalOcean, Hetzner ou Vultr ao Railyard, ou qualquer máquina Linux via SSH.

2. 2

   Clique em "Fazer deploy de Castopod"

   O Railyard constrói o container e provisiona todos os 3 serviços.

3. 3

   Configure seu domínio

   Aponte seu domínio para o app. O Railyard emite um certificado HTTPS e o mantém renovado automaticamente.

Por que fazer deploy no Railyard

O Railyard provisiona todos os 3 serviços dessa stack juntos — castopod, castopod-db, castopod-redis — conectados entre si pela rede privada, em um servidor que você já paga.

Fazer deploy de Castopod é só uma peça de uma stack maior que você pode continuar construindo — adicione um banco de dados, um worker, um cache, ou outro app, tudo nos mesmos servidores que você já paga.

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

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

Perguntas frequentes

Templates relacionados