Stateless runs, durable state: how Autoretto survives a cold start

A serverless instance has no memory. It starts, does work, and can be killed the next second. That is fine for many jobs. It is not fine for an autonomous channel that needs to remember its own history. So we separate the memory from the machine. Our runs are stateless. The owner's state is not.

Every run begins the same way. The platform lifts the owner's state out of the database. That state includes the channel config, the release schedule, the last video's metadata, the quality gate results, the policy checks, the performance data from previous uploads. It arrives before any real logic runs. The run does not guess. It does not start from zero. It starts from the owner's last known truth.

Why do we do this? Because a serverless function is an unreliable home for anything important. The container can freeze. The memory can vanish. If we kept state in a local variable, it would evaporate whenever the platform scaled to zero. A 3am autopilot release would then be a stranger to its own channel. So the state lives in a database. Each run takes a fresh copy of it, uses it, and gives it back.

The write-through part is just as important. We do not wait until the end of the run to save. Every time the platform changes a fact, it writes that fact to the database immediately. A render completes. Write it. A quality gate passes. Write it. A schedule shifts. Write it. A viewer metric comes in. Write it. Then the next step can read the updated state. If the instance dies in the middle, the next run will see exactly how far this one got.

Let me walk through the autopilot release. At 3am, a cron event wakes a cold serverless function. There is no cache. There is no warm memory. The function asks the database for the owner's state. It gets the full history, including the fact that this release was scheduled three days ago and the previous video earned a low retention rate. It adjusts the upload time slightly based on that data. It also knows that the channel prefers a certain thumbnail style. That came from the state, too. The function renders the video, runs the gates, writes each result back, and uploads the MP4. When the owner opens the dashboard in the morning, the run looks like any hand-started one. The only difference is that no human clicked a button.

This pattern solves a real tension. Autonomy needs memory. Infrastructure needs statelessness. We get both by putting memory in a place that survives. The database is the single source of truth. The run is a read and write loop around it. The pattern is simple, and simple patterns fail less often.

It also helps when something goes wrong. Because we write through on every change, the state file is a trail. You can open it and see the decisions a run made and the data it had at the time. That makes debugging an automated channel feel more like inspecting a ledger and less like interrogating a ghost. The state is never trapped in a dying process.

So the next time you see an Autoretto channel release a video at an odd hour, know that the machine that made it had no memory when it woke up. It rehydrated. It acted. It wrote through. It survived. And the next release will know everything this one knew.