Environment

CodeSandbox Repositories and Devboxes run on microVM technology (opens in a new tab). Each branch and Devbox gets its own microVM and their resources (shown below) are set to each one of these instances.

Default resources

Based on our analysis of usual resource needs, we have defined these resources as default:

But we can go higher, up to 32vCPUs, 64GB memory and 256GB storage. To upgrade to higher specs, you can ugrade to one of our Pro plans (opens in a new tab).

If you require specs that go beyond our Pro plan defaults, get in touch and our team will adjust the limits to suit your project.

Memory snapshotting

One of the most unique aspects of our environments is the use of a technique called memory snapshotting.

When we hibernate a microVM, we pause it and save its memory to disk. When you come back, we resume the VM from that memory snapshot in about 1.5 seconds. So for you, it will look as if the VM was never stopped at all! You can learn more about how we use memory snapshotting in this blog post (opens in a new tab).

Note that, the first time you import a project to CodeSandbox, it can take longer to start. However, every subsequent start will resume from memory–so, the real-world experience on a day-to-day scenario will be spinning up an environment in 1.5 seconds.

Persistence

Everything you save in /project is guaranteed to be persisted between reboots, hibernations and forks. Every file change outside of /project will usually be persisted, but there is a chance that those changes will be cleared.

Your project folder lives in /project/<repo-name>, your home folder lives in /project/home/<username>. Your home folder is inaccessible for other users.

If your branch has not been accessed for 31 days, we delete the contents of /project. This means that the next time you start this branch again, we will reinitialize /project by doing a fresh clone.

For any uncommitted work we make a backup. This backup is never deleted. All your uncommitted work is restored when you open a branch where the /project folder is deleted. This means that you will never lose your work, even if we delete /project after 31 days of inactivity.

Memory snapshots (which allow instant resume of VMs) will be cleaned up after 7 to 31 days of inactivity. There is no lost work from cleaning up memory snapshots.

Node Modules

The node_modules folder is globally ignored. You can override this behaviour by adding !node_modules in your own project .gitignore file. While this will add node_modules folders to git, they won't be displayed in the UI.

Environment configuration

You can configure the environment of your VM with a Dockerfile. To do this, create a file in the .codesandbox folder called Dockerfile. After you've saved the file, you should be prompted with a notification to restart the container.

Configuring NodeJS version

For example, to update NodeJS to v18, you can create a .codesandbox/Dockerfile with these contents:

FROM node:18

Deno support

If we detect a deno.json file in your sandbox or repository during boot, we'll automatically enable the Deno LSP (which provides autocompletions) instead of the TypeScript LSP. You can also force this by creating a file called .codesandbox/features.json and inserting these contents:

{
    "deno": true
}

Vue support

Vue also has a custom LSP to handle TypeScript files better. If we detect any .vue files in the project, we'll default to using that LSP. You can also forcefully enable or disable this by creating a .codesandbox/features.json file and inserting these contents:

{
    "vue": {
        // Whether to enable Vue LSP for TS files
        takeOverMode: true,
        // Whether to enable component inspector functionality in the editor for Vue
        inspector: true,
    }
}

Docker support

CodeSandbox supports running Docker containers inside any workspace. You can learn more about our Docker support in our Docker documentation.