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.

Dependency Install Caching

When we create a base cache of a source we install the dependencies for it. Once the dependencies are installed and the initial dev server is started we snapshot the VM, and use this snapshot for all future dev servers created off of the same template. When new repositories are created based off the same source, their dependencies are not automatically re-installed. This means that if you don't change your dependencies you never pay the cost of installing them again.

While we are waiting on this snapshot to be created, we cannot return a VM for you to work with, because this VM needs to stay clean for your other VMs to fork off of, which can make requesting a dev server for a repository that is created off of a template take longer to return than other cases when you are requesting a dev server for a repository that has already been used.

Cache Invalidation

To invalidate a cache you can commit to the underlying git repo. New repositories created off of this source will have a new cache created for them.

You can also manually invalidate a cache by deleting the underlying VM snapshot. You can find the VM a dev server is based on by looking at baseId and vmId on the dev server object you get back from the API.