CodeSandbox uses different execution environments based on the contents of a sandbox.
When using CodeSandbox, your code is evaluated and run by one of our built-in execution environments. These execution environments come in one of two types: Client and Container.
Client environments run entirely inside of your browser and will continue to bundle your code even when you lose your connection to our servers. Containers on the other hand are executed server-side inside of a Docker container instance.
While Client Sandboxes have faster previews and offline availability, they lack in configurability. Container Sandboxes take longer to start up, but effectively behave much like a local development environment, allowing you to customize your build tools, set up servers to listen to incoming requests, etc.
Client Sandboxes each have their own bundler attached to them which are configured to support a specific framework and emulate their official CLI tools. They are not one-to-one implementations and thus don't support advanced configuration like custom webpack configurations or ejecting, however they are designed to mirror the default behavior of the framework. If your project requires advanced configuration, try using a Container Sandbox instead.
Currently it is not possible to convert a Client Sandbox to a Container Sandbox.
Container Sandboxes run by connecting to a Docker instance running on our servers. We use the official Node docker image in our container instances, meaning most Node packages should be supported out of the box. With Containers you can run your own bundlers such as Webpack and retain full control over its configuration.
Containers also support running NPM scripts defined in your
run a few of these scripts automatically to start up your server. See the list
below for which scripts we run automatically and what their priority is:
While you can also lint your code using ESLint via the command line in containers, we don't currently support custom ESLint configs in the editor itself.
Unlike Client Sandboxes, Containers also expose access to the Terminal, which
allows you to run most commands you'd normally expect to be able to run in the
command line. However, you don't have root access. Also, keep in mind that
running certain commands which alter the filesystem of the container instance
will cause the files shown in the Editor to become out of sync, such as manually
yarn add or running
git commands. We don't sync files and
directories that are ignored via
.gitignore, and there is a sync limit of 10
files per second and a maximum file size of 2mb.