codesandbox-client: The Web Application Behind CodeSandbox's V1 Online IDE

What codesandbox-client Is and Its Current Status

codesandbox-client is the client-side web application that formed CodeSandbox's V1 product: an instantly ready, full-featured online IDE for web development on any device with a browser. The README describes it as enabling developers to start new projects quickly, prototype rapidly, create web apps, experiment with code, test ideas, and share creations.

The repository's most recent release tag is named "RIP-V1," published on 2026-08-26, which marks the formal retirement of the V1 codebase. The last push to the repository was on 2026-09-07. The project homepage is codesandbox.io, where a successor product is maintained separately.

Monorepo Architecture and Package Layout

The repository is organized as a Yarn workspaces monorepo managed by Lerna. The top-level `lerna.json` and `package.json` define the workspace, with packages split between `packages/` and `standalone-packages/`.

The Yarn workspace configuration in `package.json` declares these packages:

{
  "workspaces": {
    "packages": [
      "packages/@styled-system/css",
      "packages/app",
      "packages/browser-dart-sass",
      "packages/codesandbox-api",
      "packages/common",
      "packages/components",
      "packages/sandpack-core",
      "packages/react-embed",
      "packages/node-services",
      "packages/sandbox-hooks"
    ]
  }
}

The central package is `packages/app`, which contains the main browser application. `packages/sandpack-core` implements the in-browser module bundler and execution runtime. `packages/codesandbox-api` defines the messaging protocol between the application and sandbox iframes. `packages/common` provides shared utilities and types. The `standalone-packages/` directory holds packages that can be published independently from the rest of the workspace.

This separation reflects a deliberate architecture: the sandbox execution runtime is decoupled from the IDE application layer, which allows the sandbox code to be loaded into isolated iframe contexts.

The Broader CodeSandbox System

The README documents that CodeSandbox consists of several separate servers, some open-sourced and some not. The client repository contains the web application only. The other components are: a Phoenix (Elixir) API server, Nginx configuration files, a Git Extractor (github.com/codesandbox/codesandbox-importers) responsible for pulling source from GitHub repositories, and a CLI for uploading a CodeSandbox project from the command line.

This means running codesandbox-client locally does not give a fully functional CodeSandbox: the Phoenix API server is not open-sourced in this repository. The Docker setup in the repository produces an Nginx container serving the static client build, not a full stack.

Building and Running the Client Locally

The client build process uses Node.js with Yarn and Lerna. The `package.json` root defines build scripts managed through Lerna.

To install dependencies:

yarn install

To build the production bundle:

yarn build

The build script runs `lerna run build:dev` for shared packages first, then `lerna run build` for the app package. It sets `NODE_OPTIONS="--max-old-space-size=4096"` to handle the large bundle size. The `.nvmrc` file specifies the expected Node.js version.

The Dockerfile builds a static production bundle and serves it with Nginx:

FROM nginx:1.25.3-alpine
WORKDIR /var/www/codesandbox
COPY www ./

The `www/` directory is the compiled static output. Running this container serves the client interface but cannot function as a complete sandbox without the API server. The `docker/` directory in the repository contains additional Docker-related configuration.

Development Toolchain and Code Quality Setup

The repository uses a combination of TypeScript, Flow (`.flowconfig` is present at the root), ESLint (`.eslintrc`), and Prettier (`.prettierrc.js`) for code quality. The presence of both TypeScript and Flow type systems in the same repository reflects the gradual migration from Flow to TypeScript that occurred over the project's lifetime. Babel configuration (`babel.config.js`) handles transpilation, and Gulp (`Gulpfile.js`) runs asset processing tasks.

CircleCI (`/.circleci/`) handles continuous integration. BrowserStack integration is referenced in the README for automated cross-browser testing. The repository contains a `sandbox-performance-benchmark.js` at the root for measuring execution performance. GraphQL configuration (`.graphqlconfig.yml`) is also present, indicating the client communicates with a GraphQL API on the CodeSandbox backend.

The `contributor-docs/` directory provides documentation aimed at new contributors. The `.devcontainer/` configuration enables development in a container environment compatible with VS Code Remote Containers and GitHub Codespaces. Sentry error tracking is configured via `.sentryclirc` for production error monitoring.

License and What It Does Not Cover

The repository README shows a GPL-3.0 license badge and the `package.json` specifies `"license": "GPL-3.0"`. The top-level `LICENSE` file uses a `NOASSERTION` identifier in the GitHub metadata, which indicates a custom or composite license situation. Teams considering forking or embedding this code should read the full `LICENSE` file rather than relying on the metadata label. GPL-3.0 requires that derivative works also be licensed under GPL-3.0, which constrains how the code can be incorporated into proprietary products.

Several key components of a working CodeSandbox environment are not in this repository. The server-side API, the sandbox container infrastructure, and the live collaboration backend are not open-sourced here. The `README` links to some sister repositories, including the Git Extractor at github.com/codesandbox/codesandbox-importers and the CLI in the same importers repository, but the core execution infrastructure that runs user code in isolated containers is not publicly available. This means someone who builds and deploys the client Docker image gets a static web application pointing at the codesandbox.io API endpoints, not an independent self-hosted installation.

When to Use This Repository and When to Skip It

This repository is valuable as a reference for how the CodeSandbox client was architected, specifically: the separation of sandbox execution from the IDE application, the Lerna monorepo structure with interdependent packages, and the integration of a custom module bundler (`sandpack-core`) into a browser application.

StackBlitz is a comparable alternative in the online IDE space. StackBlitz uses a WebAssembly-based Node.js runtime running entirely in the browser, while CodeSandbox V1 used iframe-based sandbox containers with server-side support. This architectural difference means StackBlitz can run Node.js processes in the browser without a server, whereas CodeSandbox V1 required server infrastructure for certain runtimes.

For teams who want to embed a CodeSandbox-like experience in their own product, the separately maintained Sandpack library (github.com/codesandbox/sandpack) is the currently supported path. For studying the V1 architecture, this repository is the primary reference.

Editorial conclusion

The codesandbox-client repository is the right reference for engineers who want to study how a browser-based IDE was built at scale: how sandboxed execution was separated from the main app, how a Lerna/Yarn workspace manages a dozen packages, and how the client-side editor integrated with a Phoenix API server. It is not a starting point for building a new sandbox environment: the V1 codebase was retired in August 2024 and the repository has received no significant new features since. Teams building a new product should look at Sandpack, CodeSandbox's separately maintained embedding library, or an actively developed alternative. Anyone evaluating CodeSandbox as a service should visit codesandbox.io, not this repository.

Frequently asked questions

Official sources

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