Castopod

Was du bekommst

• Alle 3 Services gemeinsam bereitgestellt: castopod, castopod-db, castopod-redis
• End-to-End deployt und verifiziert vom Railyard-Team
• Automatisches HTTPS und Zero-Downtime-Deploys

So deployst du Castopod

1. 1

   Einen Server verbinden

   Verbinde einen DigitalOcean-, Hetzner- oder Vultr-Server mit Railyard, oder jede Linux-Box per SSH.

2. 2

   Auf "Castopod deployen" klicken

   Railyard baut den Container und stellt alle 3 Services bereit.

3. 3

   Deine Domain einrichten

   Richte deine Domain auf die App. Railyard stellt ein HTTPS-Zertifikat aus und erneuert es automatisch.

Warum auf Railyard deployen

Railyard stellt alle 3 Services dieses Stacks gemeinsam bereit — castopod, castopod-db, castopod-redis — verdrahtet, damit sie sich übers private Netzwerk erreichen, auf einem Server, den du schon bezahlst.

Castopod zu deployen ist nur ein Teil eines größeren Stacks, den du weiter ausbauen kannst — füge eine Datenbank, einen Worker, einen Cache oder eine weitere App hinzu, alles auf denselben Servern, die du schon bezahlst.

Gut für

• 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

Gut zu wissen

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

Häufig gestellte Fragen

Ähnliche Templates