Stateless runs and durable state: the shape of every Autoretto release

Autoretto treats every release as a fresh, stateless job. There are no local files, no leftover process memory, and no assumed context from an earlier run. Instead, per-owner state lives in the database. At the top of every run, the platform rehydrates that state into the function that is about to work. The function gets everything it needs in one explicit read. The database is the single source of truth. That is not a convenience. It is the core architecture.

Why bother with this split? Because serverless functions can start on any machine, at any time. A run scheduled for 3am might land on a cold instance that has never seen this owner before. The instance has no history of earlier videos, no cached settings, no memory of what the channel decided last week. If the function relied on local memory, it would miss all of that. It would not know the owner's channel name, the autopilot schedule, the YouTube refresh token, or the date of the last release. The database solves that by carrying the full picture. It is the only thing that persists across instances.

The mechanism is a read-and-rehydrate at the start. Once the state is in memory, the run proceeds normally. It generates audio, artwork, video, checks the quality gates, and prepares to publish. Every time a decision changes something, that change is written through to the database immediately. This is write-through, not write-back. There is no waiting for a batch save and no risk of losing a change if the function dies. If a step fails, we can retry from the beginning because the database already holds the updated state. The run does not need to write a recovery file.

Here is a concrete example. A creator pauses autopilot from the dashboard at 2pm. The setting is written to the database at that moment. At 3am, the scheduled release fires on a fresh serverless instance. That instance has no local memory of the pause. But it reads the database and sees paused. So it skips the run. If the platform had cached state inside the instance, the 3am run would act on stale information and release anyway. The same applies if a creator changes the channel name or updates their YouTube authorization. The next run picks up the latest version of every field. There is no propagation delay.

The same pattern holds for everything else. Owner preferences, YouTube connection details, content policy settings, and performance metrics from earlier videos all live in the database. Each run starts with the last committed snapshot. Then it adds new decisions as it goes. It writes those decisions back as it makes them. Because every write is durable, a crash mid-run does not lose anything. The next run simply reads the same database and picks up where the record allows. This also means two runs for different owners are naturally isolated. Each owner's state is kept separate and keyed by the owner id.

This combination gives Autoretto both statelessness and durability. Stateless compute is easier to scale and retry. If a function fails, we can launch another one with no cleanup. We do not have to worry about a particular machine holding the only copy of something. Durable storage means no run is alone. The knowledge of what a creator asked for, what a channel needs, and what YouTube requires is never trapped in a temporary container. It sits in the database, ready for the next run. Even if every compute instance is replaced overnight, the platform still knows how to publish correctly.

We also use this model to learn from performance. After a video publishes, the platform fetches analytics and writes the metrics back to the database. Those metrics inform the next run's decisions. A later autopilot job will rehydrate that history and adjust the prompt, the thumbnail, or the schedule. None of that needs a persistent server or a shared file system. The analytics are just another part of the owner state. The next run reads them like any other field. Over time, the database becomes the platform's memory of what works and what does not.

So yes, a 3am autopilot release really does know everything a hand-started one knows. It reads the same database and applies the same rules. It writes its decisions the same way. The only difference is who pressed go. The platform treats each run as a blank sheet with a full memory. That is the whole trick. No state in the process, all state in the database. That is what makes the system both stateless and durable.