Stateless runs, durable state: how Autoretto wakes up knowing everything

Picture a 3am upload. Nobody pressed a button. The autopilot schedule fired a serverless function. That function has no memory of previous runs. It has never existed before. Yet it needs to know the channel connection, the release schedule, the pending videos, the quality history, and the last time something changed. How does it know all that?

The answer is that we designed every run to be stateless. No in-memory state is carried from one run to the next. If a run crashes, the next run starts over with a clean slate. This makes scaling easy, because any instance can handle any request. It also makes recovery trivial. The only thing that matters is the database.

Every change a run makes is written through to the database before the run moves on. We do not hold state in memory and sync later. When a draft is updated, that update hits the database immediately. When a video passes a quality gate, the result is stored. When an upload completes, that status is recorded. If the process stops right after a write, nothing is lost.

At the top of every run, we rehydrate state from the database. This means we load every piece of information that belongs to that owner. Channel tokens, settings, performance history, the current draft, all of it. The run assembles its own context from the stored records. No hidden local caches. No assumption that a previous run left something behind.

Cold starts are the norm for serverless instances. They can be spun down at any time and created from nothing on the next request. We treat that as a feature, not a bug. Because state lives outside the instance, a cold start is just a fresh read. The 3am autopilot run gets the full picture, exactly like a hand-started one from the dashboard.

This matters for creators because it makes behavior consistent. Autopilot releases are not approximations of manual ones. They are the same code, with the same data, so they make the same decisions. It also helps with debugging. If a run does something unexpected, you can inspect the database to see exactly what it knew at the start. That removes a whole class of mysteries.

We also write through on every step, not just at the end. That means progress is tracked. If a long operation like rendering gets interrupted, the next run can pick up from the last recorded step. It does not have to redo work that already finished. The database acts as a progress log, so the system is both durable and resumable.

This is not a clever trick. It is a discipline. Every run must be able to start from nothing and rebuild its world from what is stored. That discipline keeps the platform reliable, even when the underlying instances are ephemeral. A 3am release gets the same context as one started by a human, because the database is the only memory that counts.