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

A release does not happen in one instant. It happens in steps. Audio gets generated first. Then artwork. Then a video render. Then a quality gate. Each step might run on a different serverless instance. Those instances are short-lived. They are created for one task and thrown away. They do not remember anything from the step before. This is how serverless works. There is no guarantee that two steps of the same release run on the same machine.

If a run relied on memory inside an instance, it would fail. The next step would have no idea what the previous step produced. You cannot keep a variable in memory and expect it to be there an hour later. Autoretto does not rely on memory. It relies on a database. The database is the source of truth for every release and every owner. It is not a cache or a convenience. It is the only place where state lives.

At the top of every run, the platform rehydrates state from that database. This happens before anything else. It loads the owner's profile, the current release's artifacts, the schedule, and the settings. It loads the status of the pipeline. It loads any results from previous steps. Then it starts executing. Everything the run needs is in memory, but that memory was built from the database seconds before. The memory is just a working copy.

Write-through is the other half of the pattern. Every change the run makes is written to the database immediately. When the audio step finishes, it writes the file URL and metadata. When the quality gate passes, that pass is recorded. When the video render completes, the render event is stored. There is no waiting until the end to save. There is no flush step. If the instance dies mid-run, the changes that were already written are safe. The next invocation can read them and continue.

This solves the cold start problem. A serverless instance that has never run before can pick up exactly where a previous instance left off. At 3am, when the autopilot triggers a release, the instance is cold. It has no local data. It may have been created for this one task. But the database has everything. It rehydrates the full state and proceeds. The creator does not need to do anything. The release continues as if the same instance had been running for hours.

That state is broader than just the current release. It includes the owner's YouTube channel connection and refresh tokens. Without those, the platform cannot upload. It includes the list of scheduled slots and which ones have been filled. It includes the settings for the channel, like posting frequency. It includes historical performance numbers from previous uploads. Those numbers matter because the platform learns from real performance and adjusts the next release. It might change the best time to post or pick a different style of cover art.

Manual runs work the same way. When a creator starts a run from the dashboard, that run also begins by loading the same database. It sees the same pending queue and the same context. There is no special path for manual runs. The only difference is the trigger that started them. One trigger comes from a schedule, the other from a button. After that, the code is identical.

This pattern makes the compute stateless and the data durable. Functions have no local state. They read, they work, they write. If one dies, the work already written is safe. Debugging is easier because you can inspect the database to see the exact state of a run at any moment. You can even replay a run by resetting its state and starting again. Autoretto runs unattended, and that only works if every run can recover. Rehydrating state from the database gives it that resilience. A 3am release and a hand-started one are the same to the platform.