Storage

The podcast pipeline and the apps that serve its public feeds don’t talk to each other over the network at all — they share one plain folder on disk instead. See Podcast Agent — Storage & Feed for the full shape. This replaced an earlier design that ran a full self-hosted object-storage service for what is, in practice, a handful of small files written once a day by one producer and read by one consumer already on the same machine — simpler was genuinely simpler here, not just cheaper.

Not everything fits a plain folder. The podcast pipeline’s story history and pending-approval drafts live in a real Postgres database instead, shared by all three of its shows (each with its own database on the same instance) — this data needs to be queried and filtered, which a flat file can’t do. It’s the same single-machine deal as everything else here: one Postgres instance, one disk, no separate high-availability setup.

There’s no backup mechanism anywhere in this stack — no snapshots, no off-machine replication — for either the shared folder or the shared database. This is a known, accepted gap for a single-operator setup, not an oversight — stated plainly rather than glossed over. If the machine were lost, everything stored on it — including the entire podcast episode archive and story history — would be lost with it.