"One process serves the app, runs the schedule, owns the writes, and rotates the backups. When there's one owner, there's never a question of who did what."
Everything under one roof
Keep runs as a single launchd agent. That one process does all of it: serves the API, serves the built PWA (the same process hands out the web app and answers its calls), runs the 06:31 daily loop, owns the SQLite writer, and rotates the backups. There is no separate web server, no separate scheduler, no separate backup daemon. One process, one owner of every moving part. For a single-family, local-first app, this isn't a limitation — it's the deliberate simplicity that makes the whole system reasoning-about-able.
Why one process is the right amount of process
The instinct trained by cloud architecture is to split: a web tier, a worker tier, a cron service, a backup job, each scaling independently. That's correct at scale and wildly over-built for one family on one Mac. Every split you add is a new coordination problem: how do the scheduler and the web server agree on state, how do you make sure only one thing writes the database, what happens when the backup daemon and the daily loop run at once. Keep dissolves all of those questions by never creating them. One process can't disagree with itself about who owns the writer, because it is the writer.
The single writer, made real by the single process
Remember the single-writer database guarantee from the snapshots track? This is where it becomes physically true. The reason there's exactly one SQLite writer is that there's exactly one process, and that process is the writer. You don't have to enforce single-writer with locks and coordination across services, because the architecture makes multiple writers impossible — there's only one process that could write. The clean data-layer invariant and the clean process model are the same fact seen from two angles.