Stateless and durable: the database powers every Autoretto run

When you hit publish on Autoretto or when the scheduled autopilot fires at 3am, both start the same way: a brand new serverless container spins up. No memory of previous runs. No leftover variables. It is a clean slate. That is the stateless part.

But that clean slate would be useless if it forgot everything about your channel. So at the very top of every run, we read your entire owner state from our database. Your YouTube channel settings. Your scheduled uploads. The history of past videos. The current step of whatever workflow was in progress. The analytics from previous runs. All of it comes from the database. We call this rehydration.

Once the run has that context, it can do its job. Maybe it generates a new video. Maybe it uploads a final master. Every single change it makes is written through to the database immediately. Not cached. Not promised later. Written right then. If the database write fails, the run stops. No dirty state is left behind.

This write-through pattern is the key to durability. If a cold start happens mid-process (say the container is recycled after a long idle period), the new container rehydrates from the database and sees the exact same state the previous container had. It picks up where the last one left off. No lost work. No duplicate uploads. Even if the owner changed something in the UI during the idle time, that change is already in the database, so the new container sees it too.

The alternative would be to keep state in memory across runs, but that couples the code to a specific container. You lose the ability to scale horizontally. You risk losing state if the container dies. You have to deal with cache invalidation. Stateless design handles spikes naturally. You can have 100 containers doing 100 different works simultaneously without conflict, because each one loads its own owner's state from the database.

There is a practical benefit for debugging too. When something goes wrong, we can inspect the database at the exact moment the run started. We know what the container knew. We do not have to guess about memory leaks or stale variables. The database is the single source of truth. Every decision the platform makes traces back to a persisted record.

So a 3am autopilot release feels exactly the same as a hand-started one. Both start from a cold container. Both rehydrate the same state. Both write every change to the database. Statelessness gives us scalability and simplicity. The database gives us durability and consistency. They work together so the platform just works.