Environment

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 resources consist of vCPU, RAM and storage. The vCPU and RAM specs are grouped in VM tiers of various sizes. However, the storage is set according to the subscription.

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.

Persistence

We use Dev Containers (opens in a new tab) by default for all repositories and Devboxes. Your project is under /workspaces/workspace (the default workspace folder) and your home folder is under /root. Under the hood, the paths are in /project.

Everything in your workspace is guaranteed to persist between reboots, hibernations and forks. We persist the workspace folder and the Docker engine state, like images, volumes, etc.

If your branch or Devbox has not been accessed for a certain period (explained below), we delete the contents of your workspace. However, we back up uncommitted changes to repositories and all code in Devboxes (other than the ones in .gitignore). This means that you will never lose your work, even if we delete the workspace folder after the standard period of inactivity.

Overall, we persist the workspace folder and some state in Docker (like volumes) for:

• 8 days of inactivity for projects belonging to Free workspaces.
• 15 days of inactivity for projects belonging to Pro workspaces.

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 behavior 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 Dev Containers (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": "mcr.microsoft.com/devcontainers/javascript-node:20"
}

We're using Dev Containers (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.