Environment
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:
Type | Limit |
---|---|
CPU | 2 vCPUs |
Memory | 2Gi |
Storage | 6Gi |
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.
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
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
- Create a new file:
.codesandbox/environment.json
. - Add your configuration.
- Save the file.
- 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.
- Open the sidebar menu and click on
Restart
.
Supported configuration
NodeJS
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:
nodeVersion
/* .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 = [
python310
];
}