VM Config & Persistence


CodeSandbox Repositories and Cloud Sandboxes run on microVM technology (opens in a new tab). Each branch and cloud sandbox 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 12vCPUs, 16GB memory and 30GB 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.


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

Configure various aspects of the running VMs with the environment file. Currently the config allows you to set a specific nodeVersion, but more options will be available in the future.

Getting started

  1. Create a new file: .codesandbox/environment.json.
  2. Add your configuration.
  3. Save the file.
  4. Commit/Push the file to persist changes when restarting the VM - this is needed to ensure every newly created branch will use the new configuration.
  5. Open the sidebar menu and click on Restart.

Supported configuration


If you already have a .nvmrc file containing a Node version number in your project's root folder it will automatically be picked up by CodeSandbox.

The environment file allows you to specify:


/* .codesandbox/environment.json */
  "nodeVersion": "14"

Single value configuration, type string, by default it is set to "16" .


If your package.json uses engines (opens in a new tab) field then a .nvmrc or environment.json file is not needed.

Note: This works only if you are using pitcherv-v0.236.0 or higher. You can restart your vm anytime to load the latest version.

If your project has all three ways of configuring node version. Then .nvmrc and environment.json gets the priority. If both of the files are missing then the node version that is specified in package.json file is used.

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

Nix support

Nix (opens in a new tab) is a tool that takes a unique approach to package management and system configuration. Use it to install any additional tools, like go, java, or system packages, inside your workspace.

You can put a file called csb.nix in the root of the project. This is an example configuration file for installing Python:

with import <nixpkgs> {};
stdenv.mkDerivation {
    name = "csb";
    buildInputs = [