Stateless and durable: rehydrating state on every Autoretto run

Autoretto runs on serverless infrastructure. Each run starts as a blank process. There is no lingering memory in the container. But a music channel needs continuity. A 3am release has to know what happened in every previous release. It has to know the channel's current settings, the last track that went live, and the exact step in the pipeline where the previous run stopped. So we have two requirements that seem to fight each other. The platform must be stateless enough to scale to zero. It must also be durable enough to remember who owns what.

The answer is to keep state in the database, not in memory. For each owner, we store everything relevant to a run. At the top of every run, the autopilot rehydrates that state into a context object. The context is just data. It comes from the database and goes back to it. No state lives in the function's memory between runs. This is the same pattern for every entry point, whether it is a scheduled autopilot event or a manual run triggered from the dashboard.

That context is fairly rich. It includes the owner's YouTube channel credentials and refresh token. It includes the release schedule, the timezone, and the current queue of pending tracks. It includes a list of previously generated tracks, each with its Suno audio file, its Gemini-written artwork and description, and its performance numbers from YouTube. It includes the status of any in-progress pipeline stages. If the autopilot is generating a video render, the render step's metadata is part of the state. If a quality gate is running, its partial results are there too.

We write changes through immediately. When the quality gate passes, we update the state. When the video finishes rendering, we record the file reference. When the scheduler decides the next release date, that goes into the database. We do not hold changes in memory and write them at the end. That would be fragile. If the process dies, everything after the last write is lost. Write-through means the database always reflects the most recent known truth, even if the run itself never completes.

A cold serverless instance starts with no prior context. It reads the database and gets the full picture. The 3am autopilot release is no different from a hand-started run. Both call the same entry point. Both rehydrate the same state. Both make the same decisions based on that state. There is no memory of a previous execution that we need to rely on, because the database is the source of truth. The rehydration step is fast and deterministic. It does not depend on which region or which container the code lands in.

Durability also means handling retries. A run can fail mid-way. The infrastructure may retry the same event. Because we write through each completed step, the retry sees partial progress. We make each step idempotent so running it twice does not cause a duplicate release. For example, if a video was already uploaded, the upload step checks the state and skips it. Similarly, if the cover art was already generated and its file path is recorded, the generation step does not run again. Idempotency keeps partial progress safe.

This design lets us treat each run as a pure function of database state. There is no long-running worker to keep alive. No sticky sessions. We can spin up a fresh instance for every release. If an instance is killed mid-run, the next attempt builds on the persisted state. We can run the same owner's release in any region that supports our stack. This also makes testing easier. We can simulate a release by inserting a known state and letting the autopilot run against it.

The result is a system that forgets nothing, even when it starts from nothing. Autoretto's memory lives in the database, not in the process. That is how a 3am autopilot release knows as much as one you start by hand.