LiveCodes: a client-side playground for 90+ languages that you can embed or self-host

The problem LiveCodes solves, and the developers it targets

Most playgrounds that support many languages do the compilation on a server. That means a container per language, a queue, a timeout policy and a bill. LiveCodes takes the opposite position: the README states the project is "client-side", with no servers to configure, no databases to maintain, no installs and no build steps for the end user. The claim is that everything from editing to running the code happens in the browser.

The audience follows from that. It is people who need to publish runnable examples next to documentation, teachers who want a link instead of a repository, and engineers who want to try a snippet in an unfamiliar framework without setting up a toolchain. The README lists React, Vue, Svelte, Solid, TypeScript, Python, Go, Ruby and PHP among 90+ languages and frameworks, and points to a separate page for the full list.

The README also draws a boundary that matters: a GitHub account is required only for features that use GitHub integration. Everything else is described as usable without an account, and the README claims unlimited private projects.

How the client-side playground actually runs code

The repository layout shows the split. There is a src/livecodes/html/sandbox/ directory, and the Dockerfile copies that same directory into the server image as server/src/sandbox/. The package.json exposes a serve:sandbox script that starts live-server on that directory at port 8085 with CORS enabled. So the sandbox is a separate document served from its own origin, and the playground communicates with it rather than evaluating code directly in the page that hosts the editor.

That design is what makes embedding tenable. An embedded playground on a third-party page cannot be trusted to run arbitrary user code in the same context, so the code runs in a sandboxed frame. The docker-compose.yml reflects the same separation on the network level: it defines SANDBOX_HOST_NAME and SANDBOX_PORT, defaulting to livecodes.localhost and 8090.

The build is not trivial despite the "no build steps" phrasing in the README, which refers to the user's experience, not the project's. package.json requires Node >=22 and defines a build pipeline that runs clean, copy:* and scripts/build.js, plus separate builds for docs and Storybook. The Dockerfile pins node:24.4.1-alpine3.22 for both the builder and the server stage.

Embedding LiveCodes with the SDK in one HTML file

The README's embedded example needs no package manager at all. It loads the SDK as an ES module from jsDelivr and calls createPlayground with a container selector and a params object. The params keys in the example are markdown, css, js and console, and the console value 'open' opens the console pane on load.

<div id="container"></div>
<script type="module">
  import { createPlayground } from 'https://cdn.jsdelivr.net/npm/livecodes';

  createPlayground('#container', {
    params: {
      markdown: '# Hello LiveCodes!',
      css: 'h1 {color: dodgerblue;}',
      js: 'console.log("Hello, from JS!");',
      console: 'open',
    },
  });
</script>

Save that as an HTML file and open it in a browser. The result the README describes is a playground rendered inside the container element, pre-filled with the markdown, CSS and JavaScript from params, with the console pane already expanded. No npm install, no bundler and no server are involved.

For projects that already use a bundler, the README gives the npm route instead. The package is named livecodes, and the documented install command is a single line:

npm i livecodes

After that, the SDK is imported from the package rather than from the CDN. The README notes that the same package is also published to jsr and available from CDNs, and that the SDK has separate entry points documented for JavaScript and TypeScript, React, Vue, Svelte, Solid, Preact and web components. If you are embedding into a React app, the React-specific page is the one to read first, because the embed options and lifecycle differ from the plain createPlayground call.

Self-hosting with Docker Compose and the values you must change

The README's self-hosting path is deliberately low-tech: download a release, put it on a static file server, and it works. The repository also ships a Dockerfile and a docker-compose.yml for a fuller deployment, and that is where the picture gets more complicated than the README's static-file framing suggests.

The Compose file defines three services. app is built from the repository Dockerfile with SELF_HOSTED=true. valkey runs valkey/valkey:8.1.2-alpine3.22 and is where share and broadcast state lives. server runs caddy:2.10.0-alpine as a reverse proxy. The app service depends_on valkey and receives VALKEY_HOST=valkey and VALKEY_PORT=6379.

Several defaults are placeholders that will not work as-is for a real deployment. HOST_NAME defaults to livecodes.localhost, SANDBOX_HOST_NAME defaults to the same, PORT defaults to 443, and SANDBOX_PORT defaults to 8090. The valkey service only starts its persistence mode when SELF_HOSTED_SHARE is not "false", which mirrors the SELF_HOSTED_SHARE and SELF_HOSTED_BROADCAST build arguments passed to the app.

The Dockerfile itself has one detail worth knowing before you build: the builder stage runs npm ci --ignore-scripts, then explicitly runs npx patch-package and npm run install:server to avoid installing the docs and Storybook dependencies. The final image runs as a non-root appuser, copies the built output into /srv/build, and starts with node server/src/app.ts.

Where LiveCodes is the wrong choice

The client-side model has a hard ceiling. Anything that needs a native toolchain, a real filesystem, a GPU or a long-running process is out of scope, because the README's premise is that there is no server executing your code. The 90+ language list is achieved through browser-based compilers, interpreters and transpilers, not through the same binaries you would run locally. If your goal is to validate that a project builds under your production toolchain, a browser playground is the wrong instrument no matter how many languages it lists.

There is a second limitation in the self-hosted path. The Compose stack is not a single container. It brings up the app, a Valkey instance and a Caddy server, and the app image is built from a multi-stage Dockerfile that compiles the whole front end. That is a heavier operational surface than the README's "put it on a static file server" instruction implies, and the two paths produce different capabilities: the static release has no Valkey, so the share and broadcast features that depend on it are not part of that deployment.

The documentation is also the authority on behaviour here, and it is silent in places. The README does not document rollback between releases, and it does not state what happens to shared or broadcast state when the Valkey volume is removed. The Compose file mounts a named volume called valkey-data, but nothing in the project's public documentation describes a migration or backup procedure for it beyond the general backup and restore feature listed for the app itself.

LiveCodes against CodeSandbox and StackBlitz

The closest alternatives are hosted playground platforms such as CodeSandbox and StackBlitz. The difference is architectural rather than cosmetic: those services run your project on their infrastructure, which is why they can offer full dev-server semantics, terminal access and npm installs inside the sandbox. LiveCodes runs in the browser and asks for no server, which is why the README can promise no databases and no subscription fees, and why an embedded playground costs you nothing to host beyond static files.

That trade runs in both directions. With LiveCodes you get a component you can drop into an existing page and configure through a params object, and you can self-host it under your own domain. What you give up is the ability to run a genuine Node process or a database alongside the code. If your example needs a backend, LiveCodes is not the tool; if your example is a React component, a Python snippet or a Go function, the browser-only model is sufficient and considerably cheaper to operate.

Licence, maintenance and the cost of upgrading

LiveCodes is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can embed the SDK in a commercial page, modify it and redistribute it, provided the copyright notice and permission notice are preserved. That is the general shape of the licence and not legal advice; if you are redistributing a modified build, read the LICENSE file and the vendor-licenses.md file at the root, which lists the licences of bundled third-party components.

The last push to the default branch develop was on 2026-05-08, the same day as the v49 and sdk-v0.14.1 releases. On a repository whose releases are tagged separately for the app and the SDK, that matters for upgrades: the app version and the SDK version move independently, so pinning the npm package to a specific SDK release does not pin the playground build it loads from the CDN. The README's CDN example imports from cdn.jsdelivr.net/npm/livecodes with no version, which always resolves to the latest published package. For a production embed, that is the first thing to change.

Upgrading a self-hosted instance means rebuilding the app image, since the front end is compiled in the builder stage. The Compose file passes SELF_HOSTED, SELF_HOSTED_SHARE, SELF_HOSTED_BROADCAST, FIREBASE_CONFIG, LOCAL_MODULES and NODE_OPTIONS as build arguments, so any change to those requires a rebuild rather than a restart. NODE_OPTIONS is set to --max-old-space-size=8192 in both the build args and the runtime environment, which is a hint about how much memory the build expects.

Editorial conclusion

Adopt LiveCodes if you need a browser playground embedded in docs or a teaching page, or a self-hosted instance with no server-side code execution. Do not adopt it if you expect the Docker Compose file to be a single container: it starts an app, a valkey service and a caddy server, and the share and broadcast features depend on Valkey being reachable. Before committing, verify the value you set for SANDBOX_HOST_NAME, because the sandbox is served from a separate origin and the default of livecodes.localhost will not resolve for your users.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes