codesandbox-client: the GPL-3.0 monorepo behind the CodeSandbox web IDE

What codesandbox-client actually is, and who it is for

This repository is the client half of CodeSandbox: the web application, the components it is built from, and the in-browser machinery that compiles and runs a project without a server round trip. The README describes the product as an "instantly ready, full-featured online IDE for web development on any device with a browser".

The audience is narrower than the product's. If you want to use CodeSandbox, you go to codesandbox.io; nothing here is needed. This repository is for people who want to embed a CodeSandbox editor in their own page, reuse the browser bundler, or study how a client-side compiler pipeline is organised. The README points to a separate codesandbox-importers repository for the Git extractor and the CLI that uploads a project from the command line, so the repository boundary is deliberate: this is the front end and its runtime, not the platform.

The monorepo layout: workspaces, Lerna and the packages that matter

package.json declares a private package named codesandbox at version 0.1.0, licensed GPL-3.0, with Yarn workspaces covering eighteen package paths. The interesting ones are packages/app (the application itself), packages/sandpack-core, packages/executors, packages/node-services, packages/common, packages/components, packages/react-embed and packages/codesandbox-api. The browser compilers for Dart Sass and Vue 3 sit in their own packages, browser-dart-sass and vue3-browser-compiler, alongside vue3-transpiler. Build orchestration is Lerna: the scripts call lerna, the root has a lerna.json, and the README carries a Lerna badge.

That split tells you where the difficulty lives. The app package is the shell and the editor UI; sandpack-core and executors are the part that actually turns files into a running preview; node-services is the shim that lets browser code call things that normally need Node. The nohoist list in package.json pins react-codemirror2 and a tern dependency inside codesandbox-deps, which is the kind of exception you add when a nested dependency cannot be deduplicated safely. The build script raises the Node heap to 4096 MB before building dependencies and the production bundle, which is a plain signal about how much memory a full build expects.

Installing codesandbox-client and getting a first build

The repository uses Yarn workspaces, so the install step is a workspace install at the root. The README does not spell out an install procedure; the scripts and the lockfile are the source here. Run this from the repository root:

yarn install

Be aware of what that triggers. package.json defines a postinstall script that runs `yarn lerna run install-dependencies` across the workspace with concurrency 1, then changes into a VSCode linter worker directory. Dependency installation is therefore serialised and slow, and it is the step most likely to fail on a restricted network.

The full build is a single script that builds workspace dependencies first and then the production bundle:

yarn build

The script sets NODE_OPTIONS to `--max-old-space-size=4096`, runs `yarn build:deps` (which is `lerna run build:dev`) and then `yarn build:prod`, which runs `lerna run build --scope app` followed by `lerna run copy-assets --scope app`. If you only want the embeddable bundle, the narrower target is:

yarn build:embed

That runs `lerna run build:embed --scope app` and then gulp. The README does not document what the resulting artefacts are named or where the embed bundle is expected to be mounted, so treat the build output as something you have to inspect yourself rather than something the documentation hands you.

What the Dockerfile does and does not give you

There is a Dockerfile in the repository, and it is four lines. It starts from nginx:1.25.3-alpine, sets the working directory to /var/www/codesandbox, and copies a www directory into it. That is all.

The consequence is that the image is not buildable from a clean checkout. The COPY expects a www directory that the build produces, and if you have not run the build first, the copy step has nothing to take. This is a serving image for pre-built static assets, not a self-hosting recipe. The README lists the Phoenix API server, the Nginx configuration files and the Git extractor as separate repositories, and it does not describe how to point this client at your own API server. Anyone reading the presence of a Dockerfile as an invitation to run CodeSandbox on their own infrastructure is reading more into it than the file supports.

The licence gap between package.json and the LICENSE file

package.json states `"license": "GPL-3.0"`, and the repository root contains a LICENSE file. GitHub's own classification for this repository is NOASSERTION, which means the platform did not match the LICENSE file to a known licence template. Those two facts are not in conflict, but they do mean you cannot rely on an automated licence scanner to tell you what you are dealing with.

GPL-3.0 is a copyleft licence, and that has a direct bearing on the embeddable editor. If you ship packages/react-embed inside a proprietary product, the licence question is not a formality. I am not giving legal advice; the practical point is that the licence identifier in package.json and the LICENSE file are the two things to read before you build anything on top of this, and the NOASSERTION classification is a reason to read them rather than a reason to skip them.

Where this repository is the wrong tool

If your goal is a private, self-hosted CodeSandbox, this repository will not get you there. The client is one of several servers, and the README is explicit that the API server, the Nginx configuration and the Git extractor live elsewhere. There is no documented path from a built client bundle to a working instance that opens a sandbox, saves it and serves it back.

The second case is anyone who wants a stable API surface. The latest release in this repository is tagged RIP-V1, dated 2024-08-26, and the version in package.json is still 0.1.0 on a private package. The release is titled "R.I.P. V1", and the version number tells you the monorepo is not versioned for external consumers. If you need semver guarantees, you are looking at the wrong artefact.

The third case is a small team that just wants to run untrusted code. The executors and node-services packages exist to make browser-side execution work, and reusing them means inheriting their assumptions about how a sandbox is isolated. That is a substantial piece of engineering to adopt in order to avoid writing a much smaller piece of engineering.

How it compares with StackBlitz

StackBlitz is a common alternative, and the architectural difference is the point. StackBlitz's published approach runs Node.js in the browser through WebContainers, so the runtime itself lives in the tab. CodeSandbox's client repository takes the other route: it ships browser builds of specific toolchains, which is why browser-dart-sass, browser-eslint-rules, vue3-browser-compiler and vue3-transpiler exist as separate workspace packages. Each language or tool needs its own browser-compatible build rather than running unchanged.

That difference has practical consequences. The CodeSandbox approach gives you a bundler and a set of pre-compiled tools that you can read and modify, at the cost of maintaining a browser build for every tool you add. A container-based approach moves the compatibility problem into the runtime, at the cost of a much larger piece of infrastructure. Neither is strictly better; they fail in different places.

Maintenance and upgrade cost

The last push to this repository was on 2026-10-22, and the repository is not archived. The only release listed is RIP-V1 from 2024-08-26, so releases are not a useful signal of what has changed recently; commits are. There is no changelog in the repository listing, and the README's documentation link points at the hosted product's docs site rather than at anything specific to this monorepo.

The upgrade cost is structural. Eighteen workspace packages, a nohoist list, a serialised postinstall, and a build that wants four gigabytes of heap mean that moving this repository forward is a project in itself. If you fork it, you are forking the whole workspace graph, and the packages that matter to you are entangled with the ones that do not. A shallow fork that keeps only react-embed or only the executors is possible in principle, but the README does not describe a supported way to do it.

Editorial conclusion

Adopt codesandbox-client if you are embedding the editor or reusing the browser bundler and can live with GPL-3.0. Do not adopt it if you want a self-hosted CodeSandbox: the README lists a Phoenix API server, Nginx configs and a Git extractor as separate repositories, and it does not document a deployment path for this one. Before committing, read the postinstall chain in package.json and check the LICENSE file, which GitHub reports as NOASSERTION even though package.json declares GPL-3.0.

Frequently asked questions

Official sources

1. codesandbox/codesandbox-client on GitHub
2. Issues
3. Project website
4. README
5. Releases