VM Config & Persistence


CodeSandbox repositories and Devboxes run on virtual machines (opens in a new tab). Each branch and Devbox gets its own virtual machine (VM). The size of the VM depends on the settings configured in the workspace portal (opens in a new tab). VM resource consist of vCPU, RAM and memory. The vCPU and RAM specs are grouped in VM tiers of various sizes. However, the memory is set according to the subscription.

Nano2 cores4 GB
Micro4 cores8 GB
Small8 cores16 GB
Medium16 cores32 GB
Large32 cores64 GB
XLarge64 cores128 GB
Free20 GB
Pro50 GB

If you require storage that goes beyond our Pro plan defaults, please select 'Pro Subscriptions' on our support form and get in touch (opens in a new tab). Our team can adjust your 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 VM, 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.


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 project uses Dev Containers (opens in a new tab) (which is the default now), the paths differ a bit, as they are mounted inside the container. Your project is under /workspaces/workspace, and your home folder is under /root. Under the hood the paths are still in /project though.

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 Devcontainers (opens in a new tab). To do this, create .devcontainer/devcontainer.json file in the root of the repository. 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 either create or update a .devcontainer/devcontainer.json file with these contents:

  "name": "My App",
  "image": ""

We're using Devcontainers (opens in a new tab) to configure the environment.

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.

For a step-by-step guide, check out our tutorial Getting started with Docker