Verklet

introduction

What is Verklet

A browser-first runtime for Node.js-style and Python workloads, with server execution when a workload needs it.

Verklet is a browser-first runtime for Node.js-style and Python workloads. It uses Web Workers for process isolation, Pyodide for supported Python, WebAssembly for the heavy systems work, OPFS for browser persistence, and Service Workers for routing preview requests, so what your code produces is what your visitor sees.

It is distributed as @verklet/sdk, a single package you import into a client-side React, Vue, or vanilla project. Each integration uses a public projectId from your Verklet account so Verklet can serve compatible runtime assets and registry URLs for the SDK version you installed. Browser workloads do not need you to provision a backend, start a container, or keep an SSH tunnel open.

Python is browser-first too: python, python3, and supported pip flows run in Pyodide when possible. When a workload needs a server environment, such as uv, native Linux tools, native Python wheels, or server persistence, the same SDK can boot or promote to Verklet's managed server runtime. Use backend: 'auto' to start in the browser and promote only when a command requires it.

What you can build with it

  • AI coding agents — give the agent a sandbox to mount, edit, and run code in, keep supported Python local with Pyodide, then promote native or unsupported work to a server workspace when needed.
  • Browser IDEs — bring your editor and a real runtime to the same origin. The terminal becomes just another component, even when a command crosses to the server backend.
  • Embedded tutorials — drop a working dev environment into your docs so the reader edits JavaScript or Python, the code runs, and the preview reloads.
  • Customer demos — ship a live, mutable demo of your product with browser-cheap sessions by default and server sessions only where the flow needs them.

What you cannot use it for

  • Browser-only workloads that need actual native binaries. Use the server runtime for native Python wheels, subprocess-heavy code, or other native tools, and verify the exact package stack you plan to expose.
  • Long-lived background jobs across page reloads (we persist filesystem state, not running processes).
  • Anything that legally must run only in your own trust boundary.

Ready? Try the interactive tutorial, or create an account, get a project ID, then jump to getting started.