Today we're releasing a new SDK that finally fulfills the mission of Wasmer: run anything, anywhere.

Python, Node.js (via Edge.js), PHP and even Postgres can now run as sandboxed libraries inside your Python, JavaScript or Rust applications.

There's no Docker daemon to start, no VM to boot and no remote sandbox service involved. The sandbox runs locally, as part of your application, with 0.1ms of sandbox creation time, 10-20x faster command runs, and 2-10x faster startup times compared to Docker and Remote Sandboxing alternatives (see benchmarks below).

Try it in the browser

This is probably my favorite part: the SDK also works fully inside the browser.

Here is the Wasmer JavaScript SDK running Python, PHP and a Next.js server directly in the browser:

https://wasmer.sh/

Important: the first run will take a bit to run, since it’s downloading all runtimes into your browser (~50-70Mb each, uncompressed at the moment). We are working on serving them compressed, which would save around 80% of bytes in transfer.

Try it yourself:

• Run Python in your browser → python python/server.py
• Run a Next.js server in your browser → cd next && pnpm i && pnpm run dev
• Run PHP in your browser → php -S 0.0.0.0:8000 -t php
• Run Postgres inside Python → See source code (postgres in browser coming soon!)

And to be clear: none of these examples are running on a remote machine. The actual runtimes and servers are executing locally through Wasmer JS SDK in your browser.

Use the SDK from Python, JS and Rust

The API is intentionally small. Create a local sandbox, select the packages you want and run them:

# pip install wasmer_sdk
sandbox = await Wasmer().sandboxes.create(
    packages=["python/python", "wasmer/edgejs-quickjs", "php/php-32"]
)

print(await sandbox.command("python", ["-c", "print('hello from Python')"]).run())
print(await sandbox.command("node", ["-e", 'console.log("hello from Edge.js")']).run())
print(await sandbox.command("php", ["-r", "echo 'hello from PHP';"]).run())

Or using JavaScript:

// npm i @wasmer/sdk
const sandbox = await wasmer.sandboxes.create({
  packages: ["python/python", "wasmer/edgejs-quickjs", "php/php-32"],
});

console.log((await sandbox.command("python", ["-c", "print('hello from Python')"]).run()).text());
console.log((await sandbox.command("node", ["-e", 'console.log("hello from Edge.js")']).run()).text());
console.log((await sandbox.command("php", ["-r", "echo 'hello from PHP';"]).run()).text());

The sandbox is another component of the host application. It can be created, configured and destroyed through the SDK without shelling out to Docker or coordinating with a separate sandbox service.

Once the runtime itself becomes embeddable, software starts becoming embeddable too. Making very interesting combinations possible:

Python application
    └── Node.js

Rust application
    └── Postgres

Browser
    ├── Python
    ├── PHP
    └── Next.js

Why WebAssembly?

Docker can run almost anything. That's its superpower.

But a standard container is not always the security boundary you want for hostile code. Systems that execute untrusted workloads commonly rely on extra isolation layers, normally using hardware virtualization (KVM or similar).

WebAssembly gives us a small in-process boundary: bounds-checked memory, validated control flow, explicit host capabilities, and Harvard Architecture provide strong in-process isolation without requiring hardware virtualization.

A Harvard architecture machine has distinct code and data address spaces

This is one of the properties that makes Wasmer considerably lighter than VM-based sandboxing approaches.

Instead of:

Application
    ↓
Network
    ↓
Sandbox service
    ↓
MicroVM / KVM
    ↓
Guest Linux
    ↓
Application

you can have:

Application
    ↓
Wasmer
    ↓
WebAssembly sandbox
    ↓
Python / Node.js / PHP / Postgres / ...

The sandbox is simply another component of your application.

Local sandboxes for AI agents

One immediate use case is AI agents.

Agents often need to execute untrusted code they did not write. The common solution is to send that code to a remote sandbox backed by a container or microVM.

But it also has tradeoffs. Every command may require a network round-trip. Starting an isolated environment can also be much heavier than creating an in-process sandbox.

For agents performing dozens or hundreds of tool calls, these costs compound quickly.

Wasmer gives local agents another option:

• Local execution: no network round-trip for every command
• Fast sandbox creation: no VM or container needs to boot
• Open source: the sandbox can run entirely on infrastructure you control
• Embeddable: the execution environment is part of your application

Do you want to give it a try? Copy and paste this prompt into your agent:

Install the new Wasmer SDK to run a simple Python program.
The SDK documentation lives in their repo: https://github.com/wasmerio/wasmer-sdk

How it compares

Wasmer overlaps with several existing technologies, but the boundaries are different.

Lighter than Docker

Docker can run almost anything. But you can't embed Docker as a library, run it on your iPhone, or inside a browser. It's simply too heavy.

For hostile workloads, standard containers also often need an extra isolation layer such as hardware virtualization (KVM or equivalents).

With Wasmer, the runtime is embedded directly into your application and uses WebAssembly for isolation. That makes Wasmer sandboxes dramatically lighter:

• Single-digit millisecond startup times (see benchmarks)
• Much higher application density (read more)
• Lightweight isolation without KVM

And because Wasmer is embeddable, the same sandbox can run on servers, browsers, mobile apps, or directly inside another library.

Remote sandbox services

Services such as E2B, Daytona, Modal and Blaxel provide managed remote environments and physical separation from the user's machine.

Wasmer SDK runs locally. That removes the required network hop and keeps execution on infrastructure controlled by the host application.

WebContainers

StackBlitz proved something remarkable with their WebContainers implementation: you can run Node.js entirely inside the browser. It's now the engine behind bolt.new.

But what if you want Python? Postgres? What if the host application itself is written in Rust instead of JavaScript?

Wasmer starts one layer lower. WASIX packages are not limited to Node.js: the SDK can run JavaScript, Python or PHP, natively or in the browser.

So you could build something like bolt.new, but run way more than just Node.js. All while being fully open-source and MIT-licensed.

PGlite

PGlite made Postgres embeddable inside JavaScript applications, particularly in browsers.

We wanted to take that one step further: what if Postgres itself was the portable package?

From JavaScript, sure. But also from Python or Rust?

Even in your phone? Yes, even in your phone.

That's what packaging Postgres as a WASIX application gives us.

In other words, Postgres becomes a portable package rather than a JavaScript-specific library.

Pyodide

Pyodide made Python in the browser practical and powers projects such as JupyterLite.

But what if you want to run a normal Python application that was never designed for the browser?

Wasmer runs CPython on top of WASIX, which lets us preserve many of the things normal Unix Python applications expect:

• Multithreading with pthreads
• Greenlets and stack switching, enabling libraries such as SQLAlchemy
• Native Python **asyncio**** semantics**
• Normal **pip**** workflows**, instead of micropip
• Full servers, including Django, Flask and FastAPI

Take SQLAlchemy: its synchronous APIs rely on greenlets. With Wasmer, that kind of application can now run directly inside the browser.

Why now

Most of this was simply not possible with Wasmer a year ago.

The funny thing is that the SDK wasn't really the blocker. The runtime was.

WASIX now has much more complete networking, threading and filesystem support. Python can use greenlets and stack switching. Edge.js lets us run Node.js-compatible applications. Packages such as Postgres can now run as normal Wasmer packages.

Once those pieces started working together, we realized we could expose all of them through the same API.

That's what the new SDK is: Python, Node.js, Postgres and other software running through the same sandbox interface, whether the host is Python, Rust, JavaScript, a browser or a phone.

Deep dive into the architecture

Previously, we maintained the Python, JavaScript and other Wasmer bindings independently. Every new capability had to be implemented more than once, and the APIs slowly diverged.

The new SDK has a shared Rust core:

              Python  Swift   C++   Rust
                 \      |      |     /
                  \     |      |    /
                      Wasmer core
                           |
                         WASIX
                           |
          Python   Edge.js   PHP   Postgres   ...

For native language bindings, we're using UniFFI.

That gives us a clear path toward bindings for:

• Python
• Swift
• C++
• Kotlin
• and others

An improvement in the Rust core can propagate through the other language bindings instead of being reimplemented independently.

However, JavaScript bindings are a bit different.

We use wasm-bindgen when targeting JS as browser threads are implemented with Workers, and we also want the SDK to use the browser's native WebAssembly engine directly. That doesn't map cleanly to UniFFI today.

We have been very interested in BoltFFI (a faster UniFFI alternative) because it’s zero-copy resource model avoiding serialization/deserialization. We hit a few issues that prevented us from adopting BoltFFI for the SDK (yet), but we're watching it very closely.

Networking inside the browser

Browsers cannot open arbitrary TCP or UDP sockets, yet we still want applications to be able to do this:

python -m http.server

So, how do we do it?

We handle it in two ways:

• HTTP servers are bridged into our virtual network through a Service Worker
• Other outbound connections can be routed through a proxy

From the guest's point of view it still sees normal WASIX networking APIs.

Benchmarks

There are three different performance questions here, and combining them into one number would be misleading:

1. How long does it take to create the sandbox?
2. How long does the guest runtime (such as CPython) take to start?
3. What is the end-to-end latency of running a command?

In general, we can see that sandboxes are created much, much faster compared to Docker and alternatives.

So, if you want to run a real Python / Node.js / PHP or Postgres sandbox, fully inside of your Python application, how long it will take in the real world?

Benchmarks run in Apple M5 Max laptop, using wasmer_sdk package in python. Reproducible results available here: https://github.com/wasmerio/wasmer-sdk/blob/main/benchmarks/sandboxes/RESULTS-2026-09-01.md

What doesn't work?

Wasmer is not a full Linux VM.

Programs depending on functionality that has not been implemented by WASIX may not run without changes.

Examples of areas where there are inherent or current limitations include:

• Linux kernel modules
• direct hardware/device access
• eBPF
• arbitrary unsupported syscalls

Browser environments also impose constraints that don't exist on native platforms, particularly around networking, persistent storage, and access to the operating system.

The goal is not to pretend those differences don't exist. It is to make the set of software that can run in a WebAssembly sandbox large enough that, for many application and agent workloads, you no longer need a traditional container or VM.

The sandbox becomes a library

Containers made it possible to package software independently from the machine running it.

Wasmer pushes that one step further: the execution environment itself can now be embedded into your application.

application → Wasmer → software

Run Node.js inside Python. Postgres inside Rust. Django inside a browser.

The sandbox becomes a library.

The Wasmer SDK is open source and available today.

# Node or Browser
npm i @wasmer/sdk

# Python
pip install wasmer_sdk

Star the project on Github!

wasmerio/wasmer-sdk

We can't wait to see what you build with it.