Create a sandbox from a template (opens in a new tab), or read more about the difference between browser and cloud sandboxes.
There are several ways to set a sandbox as private. One universal way (that works both for browser sandboxes and cloud sandboxes) is to right-click a sandbox from the dashboard and select Make sandbox private.
A Pro subscription (opens in a new tab) is required to make sandboxes private or unlisted.
You can also change the privacy settings from the editor. How you do it will depend on whether you're using a browser sandbox or a cloud sandbox, as shown below.
The browser editor provides two ways to change the privacy settings:
- Change the privacy drop-down under Permissions in the Sandbox Info tab.
- Click the Share button on the top right and change the privacy drop-down at the top.
The cloud editor also provides two ways to change the privacy settings:
- Click the chevron on the right side of your sandbox's name at the top of the screen; click Edit info and then change the drop-down next to Privacy.
- Click the Share button on the top right and change the drop-down under Permissions.
There are a few possible reasons a repo might throw that error on import. The
most common are: the lack of a
package.json file, or the project using
more than 500 modules (files).
If you think it's something else, or you're unable to solve this yourself, then get in touch and provide a link to the repo you're importing and we can look into this for you.
For performance reasons, we ignore any specified scripts in browser sandboxes, instead using a default script. If you need to control the scripts, then we recommend using a cloud sandbox.
Yes, for cloud sandboxes you can refer to here (opens in a new tab) to learn how to change the Node version. All recent server sandboxes run in a cloud sandbox.
For container sandboxes that are created after May 10 2021, we run Node v14.18.1 (LTS) by default.
For backwards compatibility, the older sandboxes are on Node v10. However, you can
node value to alter the version in
sandbox.config.json, which will
be used instead. For further details, see configuration.
Note that we recommend using Cloud Sandboxes when you're working with Node.js projects.
Yes. The terminal, console, and problems tabs are all draggable. Click on the tab and drag it to the bar alongside browser and tests. You can then re-order those items by dragging them in that bar. Whichever is first from left to right in the list of tabs is what opens first when other folks view the sandbox. The ordering is maintained within the sandbox. You can also achieve this change by setting a value for "view" in a sandbox config file.
Ensure the font you want to use has been installed on your computer, then put the name of it first in the comma-separated list under 'Editor: Font Family' from File > Preferences > Settings in the editor.
Changing fonts is currently only supported in browser sandboxes.
- The maximum file upload size is 7MB for Free users and 30MB for Pro users.
- Imported sandboxes must contain a
- Cannot use more than 500 modules (files). Note that
node_modulesand dependencies do not count toward this limit.
- The maximum file size that can be opened in the editor is 2MB. Files uploaded that are larger than that still exist but are linked as a static asset.
- Terminal commands that alter the filesystem of the container instance aren't synced with files shown in the editor. You'll need to refresh to see files updated this way.
- When using a container, there is a sync limit of 10 files per second and only files up to 2MB are synced with the editor. Files larger than that still exist but are not shown in the editor's file tree. You're still able to write and read to and from them in your code and they can be seen and edited via the terminal.
- When using a container, the sandbox sleeps after around 10 minutes and can be woken by opening the sandbox or preview in a web browser.
- When using a container, the sandbox has a 1GB persistent storage limit, a 1GB vCPU soft limit, and a hard memory limit of 2 GB.
Cloud Sandboxes are part of our evolved CodeSandbox experience, so we highly advise you to use them to avoid encountering these limitations.
If you encounter this error when importing or committing, check your sandbox or repo for large binary files and remove them.
Yes, you can use any database that has a Docker image available. Some popular databases with Docker images include MySQL, PostgreSQL, MongoDB, and Redis.
For ready-to-use examples, check our starter templates (opens in a new tab) modal.
No, you don't need to install Docker on your local machine. CodeSandbox has built-in support for Docker (opens in a new tab), so you can use it directly in the online development environment.
You can access the database using the appropriate driver for your language or framework. Typically, you'll need to provide the hostname, port number, username, and password to connect to the database.
Yes, you can use multiple databases in the same project by running multiple Docker containers with different port numbers. However, keep in mind that running multiple databases can put a strain on your system resources and affect performance.
Yes, you can use Docker Compose in CodeSandbox to orchestrate multiple containers and define the relationships between them. However, you'll need to create a Docker Compose file and run the
docker-compose command in the terminal to start the containers.
Yes, it's safe to use a database in CodeSandbox with Docker support, as long as you follow best practices for security and keep your database credentials private. Docker provides a secure and isolated environment for running containers, so your database is protected from external threats.
If you're having issues with your database, you can check the logs of the container to see if there are any error messages. You can also run commands like
docker ps and
docker logs in the terminal to get more information about the container. Additionally, you can ask for help on the CodeSandbox community forums or consult the documentation of the specific database you're using.
To change the theme of a Cloud Sandbox (opens in a new tab), click on the CodeSandbox logo at the top left, then go to Settings > Preferences, and select a theme from the Themes dropdown. You can also do it from the command palette (opens in a new tab).
On a Browser Sandbox, you can change the theme from File > Preferences > Color Theme in the editor. You can also set a custom VS Code theme on a Browser Sandbox. Open VS Code, Press (CMD or CTRL) + SHIFT + P, Enter: '> Developer: Generate Color Scheme From Current Settings', copy the contents and paste it into Preferences > Appearance from the top-right avatar menu. After completing that, you need to reload the browser and select "Custom" as your color theme from File > Preferences > Color Theme.
While we do have infinite loop protection as a
configurable option (opens in a new tab) it doesn't
prevent all scenarios where infinite loops can occur, such as with incomplete
code. When this happens, you can append
runonclick=1 to the editor URL to stop
the code from being automatically executed, enabling you to edit your code to
resolve it. For example:
https://codesandbox.io/s/new?runonclick=1 (opens in a new tab)
Yes. While our Repositories only have built-in push and sync capabilities for GitHub, you can connect to a remote repository from any other git provider.
To do that, use our terminal to
git remote add the remote repository and then add your credentials for it. You can also add the authentication details to the CodeSandbox microVM using environment variables (opens in a new tab).
For Team Pro & Personal Pro users, once you've logged in, you can downgrade your plan on the Settings page (opens in a new tab).
If you're on one of our legacy Patron plans you can cancel your subscription on the Patron page (opens in a new tab).