How Autoretto stays stateless and durable

Most of Autoretto runs on serverless functions. We use them for scheduling, for the generation pipeline, and for publishing. Each function is a small piece of work. It starts, does its job, and ends. No process keeps running between invocations. There is no hidden memory. There is no long-lived server holding context. Serverless gives us elasticity. It scales to zero when there is no work. It bursts when there is. But it gives us no place to put data. That is the stateless part of the design.

Stateless is great for scaling. It is not great for remembering. Every creator channel has its own state. Release schedule. Last release date. Which videos are generated. Which policy checks have passed. What artwork is ready. That state changes with every run. If a function cannot see that state, it cannot make the right decisions. If it does not know the last release date, it might schedule two releases too close together. If it does not know which videos are already generated, it might waste time and API calls regenerating them.

So we put the state in a database. At the top of every run, we rehydrate it. That means the function loads the full owner state from the database before it does anything else. The database is the source of truth. The function starts with a clean slate and then gets filled in. This happens on every run. No exceptions. It does not matter whether the run was triggered by the autopilot scheduler, a manual click from the creator, or a webhook from a connected service.

We also write through on every change. When the pipeline generates a new video, we update the database right away. When a policy gate passes, we store that. When the last release stamp changes, we record it. We do not buffer changes in memory. We do not hope the instance stays alive long enough to flush them. Each change is written immediately. If the function crashes a second later, the state is already safe. This includes the state of the Suno audio, the Gemini copy, and the Sora motion clips, along with the final rendered video state.

Cold starts are then just a matter of reading. A cold instance has no local cache. It connects to the database and rebuilds the state in the first few seconds of the run. There is no difference between an instance that has been warm for an hour and one that just woke up. Both start with the same database query. Both get the same answer. That is the key to staying durable in a stateless world.

Consider the 3am autopilot release. The scheduler kicks off a function. The function cold-starts. It loads the channel's state. It sees the last release stamp, the schedule slots, the pending videos, the approved artwork. It knows everything a hand-started run at noon knows. The hand-started run reads the same database. Both runs behave exactly the same. The time of day does not matter. The autopilot run reads the same rows. It makes the same decisions. It does not need to know what happened in previous runs because the database remembers. The function is just a set of instructions. The database is the memory.

Durability comes from the database itself. We rely on its backups and replication. It survives instance restarts and region issues. Our functions stay disposable. They are designed to be thrown away after a single use. That makes them easy to deploy and to scale. But they are not where the truth lives. The truth lives in the database. That separation is what lets us have both stateless functions and durable state.

It is a simple pattern. Rehydrate at the top. Write through on every change. Use the database as the single source of truth. That pattern keeps the platform honest. It avoids a whole class of bugs. No hidden state, no memory leaks, no stale caches. We know that any run, at any hour, in any instance, will see the same reality. That is what a 3am autopilot release needs. It is what a hand-started release needs. And it works.