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:
Type | Limit |
---|---|
CPU | 2 vCPUs |
Memory | 2Gi |
Storage | 6Gi |
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.
For a step-by-step guide, check out our tutorial Getting started with Docker