How the Dev Server Cache Works

The Dev Server cache is the key to making Dev Servers fast and cheap to run.

We key the cache on Git Commit Hashes per user. This means that it works on Git Repositories outside of Freestyle, and that other users caches cannot interfere with yours.

When a Dev Server is started, we check if there is a cache hit, if not, we automatically create a new cache entry for you to fork your new Dev Server off of. This works well when you have template repositories that are used a lot for new projects, as their caches will be automatically generated as they are used. It also means new commits to them will invalidate your cache — so for new commits to your template you can expect the first dev server created off of them to take longer.

A cached VM is not just a file system image, instead we snapshot the running VM. This means that if for example you're running a NextJS Dev Server, rather than paying for the 5-10 second cold start time on every start, once we have a cached VM it is started in hundreds of milliseconds with the NextJS server already running and ready to go. We generate these automatically based on git repositories that are used.

The cache mechanism is built around Freestyle Cache VMs. This mechanism works around your accounts rate limits, and maximizes keeping around the most recently used VMs while deleting the old ones.

When a Dev Server is created for a branch of a repository, it will use the closest available snapshot of the code available. If there is a snapshot for the branch it will use it, if not it will fallback to the main branch. It will not use and dirty snapshots with in progress work in them.