Q2/22 Launch Week Day 1: Firecracker-Based Snapshotting
Reading Time • 2 min read
Q2/22 Launch Week Day 1: Firecracker-Based Snapshotting
Q2/22 Launch Week Day 1: Firecracker-Based Snapshotting

The Q2 2022 day 1 launch week announcement brings Firecracker-based snapshotting, giving users a faster e2e testing experience.

Welcome to our third Launch Week, where each weekday we unveil a product or feature release that our team has been working on in the past three months. If you haven't already, head over here to subscribe for future product updates and launch weeks.

Why We Built This

Firecracker-based snapshotting was a project led by webapp.io’s Co-Founder and CEO, Colin Chartier. It uses the technology that powers Serverless to provide a faster e2e testing experience. Colin has written extensively about the process of setting up and running end-to-end tests using Firecracker, which can be found on the webapp.io blog.

Below is a demo video of how Firecracker-based snapshotting works from Colin:

Video description of Firecracker-based snapshotting

Enabling Firecracker-Based Snapshotting

For most use-cases, it’s as easy as going into your organization’s settings page within webapp.io and clicking the checkbox that’s named “Use new hypervisor for snapshotting and file watching”.

A screenshot of the organization page, showing where the new hypervisor can be toggled on

Then vs. Now: What's Changed?

Next, we’ll address some general infrastructure changes and features that we have implemented alongside Firecracker.

The CLONE Instruction

The CLONE instruction can be used if you have multiple repositories (e.g., a repository for the frontend and a repository for the backend) and you want to run both in one environment (in one runner). For users that may already be familiar with some of our directives, the CLONE instruction works much like the COPY instruction, with the key difference being that it works across repositories.

The MEMORY Instruction

Recognizing that there is a way to mitigate memory errors and reduce the time that it takes to make snapshots, we have reformulated the way that we add memory when a new run is started. Initially, runs would start, 1GB of memory would be added, and more would be added as requested. Now, the MEMORY instruction is put at the top of the build, where all of the memory that will be needed gets stated.

Overall Speed

Now, a run will start as the repository is being cloned. This means that even if files are referenced for the first time, it will wait for the repository to finish being cloned and then copy the files in after. This results in extremely fast runs. An additional improvement can be seen in the loading of snapshots, as they can be loaded almost instantaneously. Try it out yourself to see the difference!

Deleting Logic

Lastly, we have also created a new way of prioritizing snapshots to ensure that one organization creating many snapshots does not cause another organization to lose their snapshots too quickly. Now, if an organization has a pull request open, and the repository creates snapshots, then the snapshots for that repository are not deleted. The snapshots can now be retained for up to a week.

Ready to get started? Sign up for free here and see the speed difference for yourself, or if you are an existing customer, enable “Use new hypervisor for snapshotting and file watching” in your organization’s settings!

Last Updated • Jun 20, 2022