I want to be able to run code from untrusted sources (other people, users of my SaaS application, LLMs) in an environment, where I can control the blast radius if something goes wrong.
Everyday we grow closer to my dream of having a WASM based template engine for Python, similar to how Blazor takes Razor and builds it to WASM. I might have to toy with this when I get home.
How long should it take for "wasmer run python/python" to start showing me output? It's been hung for a while for me now (I upgraded to wasmer 6.1.0-rc.5).
"wasmer run python/python@=0.2.0" on the same machine gets me into Python 3.12.0 almost instantly.
OK got there in the end! I didn't time it but felt like around 10 minutes or more.
It did give me one warning message:
% wasmer run python/python
Python 3.13.0rc2 (heads/feat/dl-dirty:152184da8f, Aug 28 2025, 23:40:30) [Clang 21.1.0-rc2 (git@github.com:wasix-org/llvm-project.git 70df5e11515124124a4 on wasix
Type "help", "copyright", "credits" or "license" for more information.
warning: can't use pyrepl: No module named 'msvcrt'
>>>
I'm not sure I understand correctly: is it a new serverless offering competing with the likes of vercel and fly.io, but with a different technology and pricing strategy? And the wasm container means that I can deploy my streamlit of FastAPI ETL apps without the Docker overhead or slowness of streamlit cloud?
FFI support (like they have) is essential for any alternative Python to be worthwhile because so much of what makes Python useful today is numpy and keras and things like that.
That said, there is a need for accelerating branchy pure-python workloads too, I did a lot of work with rdflib where PyPy made all the difference and we also need runtimes that can accelerate those workloads.
Are we at the point where I can store arbitrary scripts in a sql database and execute them with arguments, safely in a python sandbox from a host language that may or may not be python, and return the value(s) to the caller?
I'd love to implement customer supplied transformation scripts for exports of data but I need this python to be fully sandboxed and only operate on the data I give it.
Wasmer's approach hints at faster cold starts and better overall performance; the benchmarking against pyodide is a bit unclear, and it's unclear to me whether that would make or break viability for a use case like this.
But one thing this does make possible is if your arbitrary script is actually a persistent server, you can deploy that to edge servers, and interact with your arbitrary scripts over the network in a safe and sandboxed way!
That's almost exactly what I want to do too. I've experimented a bit with QuickJS for this - there's a Python module here that looks reasonably robust https://pypi.org/project/quickjs/ - but my ideal would be a WebAssembly sandbox since that's the world's most widely tested sandbox at this point.
Nice, but every time I look into WASM I have to wonder if containers and/or lite weight VMs wouldn’t be simpler and have less restrictions. We seem to have forgotten about microkernels and custom runtimes (like the various Erlang ones) as well…
Still, that close to native Python is an interesting place to be.
Depending on the language, GC is either implemented in userspace using linear memory, or using the new GC extension to webassembly. The latter has some restrictions that mean not every language can use it and it's not a turnkey integration (you have to do a lot of work), but there are a bunch of implementations now that use wasm's native GC.
If you use wasm's native GC your objects are managed by the WASM runtime (in browsers, a JS runtime).
For things like goroutines you would emulate them using wasm primitives like exception handling, unless you're running in a host that provides syscalls you can use to do stuff like stack switching natively. (IIRC stack switching is proposed but not yet a part of any production WASM runtime - see https://webassembly.org/features/)
Based on what I read in a quick search, what Go does is generate each goroutine as a switch statement based on a state variable, so that you can 'resume' a goroutine by calling the switch with the appropriate state variable to resume its execution at the right point.
JuputerLite also does this. Uses local storage and Pyodide kernel (python on wasm). It has a special version of pip, and wasm versions of a lot of libraries which usually use native code (numpy etc). Super impressive.
Philosophically speaking I believe we should not require a special version of pip to install packages, nor a "lite" version of Jupyter to run in WebAssembly.
We should be able to run Jupyter fully within the Wasmer ecosystem without requiring any changes on the package (to run either in the browser or the server).
Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.
Not every single website needs to support every single browser. This is a modern convenience, I was doing QA back in the day when we still had to support Internet explorer.
Internet explorer just didn't provide the same experience as Chrome.
You were supporting the tail end of an era that is universally agreed upon as an ecosystem failure. The internet didn't provide a consistent user experience for developers or for users, it generated mountains of legacy baggage, and it was frustrating for everyone.
For example if Firefox decides to add Rust support it doesn't mean every other browser needs to support it.
Just a handful of web experiences are going to be exclusive to Firefox. As is having Chrome as the only browser most people use isn't great for innovation.
Maintaining a browser is already hard enough, it's a very tough sell to convince 3+ browser vendors to implement a new language with its own standard library and quirks in parallel without a really convincing argument. As of yet, nobody has come up with a convincing enough argument.
Part of why WebAssembly was successful is that it's a way of generating javascript runtime IR instead of a completely new language + standard library - browsers can swap out their JavaScript frontend for a WASM one and reuse all the work they've done, reusing most of their native code generator, debugger, caches, etc. The primitives WASM's MVP exposes are mostly stuff browsers already knew how to do (though over time, it accumulated new features that don't have a comparison point in JS.)
And then WASM itself has basically no standard library, which means you don't have to implement a bunch of new library code to support it, just a relatively small set of JS APIs used to interact with it.
I tried to understand what is "Wasmer Edge" but couldn't. They say on the front page "Make any app serverless. The cheapest, fastest and most scalable way to deploy is on the edge." and it seems like I can upload the source code of any app and they will convert it for me? Unlikely so.
Also it says "Pay CDN-like costs for your cloud applications – that’s Wasmer Edge." and I don't understand why I need to pay for the cloud if the app is serverless. That's exactly the point of serverless app that you don't need to pay for the servers because, well, the name implies that there is no server.
Confusingly, "Serverless" doesn't mean there's no server. It means that you don't have to manage a server yourself.
My preferred definition of serverless is scale-to-zero - where if your app isn't getting any traffic you pay nothing (as opposed to paying a constant fee for having your own server running that's not actually doing any work), then you pay more as the traffic scales up.
Frustratingly there are some "serverless" offerings out there which DO charge you even for no traffic - "Amazon Aurora Serverless v1" did that, I believe they fixed it in v2.
Still confusing, since infrastructure you don't have to manage yourself is sometimes called "managed". It makes sense from the perspective of "you are paying us to manage this for you".
It's a terrible name, but it's been around for over a decade now so we're stuck with it.
I mostly choose not to use it, because I don't like using ambiguous terminology if I can be more specific instead. So I'll say things like "scale-to-zero".
Normally, if you want to run your apps serverlessly you'll need to adapt your source code to it (both AWS Lambda and Cloudflare Workders require creating a custom HTTP handler).
In our case, you can run your normal server (lets say uvicorn) without any code changes required from our side.
Of course, you can already do this in Docker-enabled workloads: Google Cloud or Fly.io, for example. But that means that your apps will have long cold-start times at a way higher cost (no serverless).
Thank you for the explanation, now I can better see the differences between "serverless" platforms although I am still a little disappointed that so called "serverless" apps still require a (paid) server despite the name.
This bugs me all the time. Ethernet is serverless. Minesweeper is serverless. AWS Lambda is quite serverful, you're just not allowed to get a shell on that server.
I believe "serverless" in this sense means "like AWS lambda". Theoretically you upload some small scripts and they're executed on-demand out of a big resource pool, rather than you paying for/running an entire server yourself.
It seems like a horrible way to build a system with any significant level of complexity, but idk maybe it makes sense for very rarely used and light routes?
Would it be possible to make it work on iOS or android? I always missed better support of python on mobiles. In the past used PythonKit rapid prototype and interop with Swift but had limited set of modules. Wish to use this in react native for interop between js and python
Does your solution support interop between modules written in different languages? I would love to be able to pass POD objects between Python and JS inside the same runtime.
For a backend project in Java, I use Jep for Python interoperability and making use of Python ecosystem. It gives me a "non-restricted" Python to have in my Java code, something I'm quite happy with. Wondering how this compares to that .
Would the app have outbound network access to do some Python scheduling stuff that involves pulling from another endpoint?
Eg something like this flask-based app? (Yes the code is shit, I’m just a sysadmin learning Python with some AI support at that time).
https://github.com/jgbrwn/my-upc/blob/main/app.py
Also, if wasmer supports Starlette, I assume it would support FastHTML (web framework that uses Starlette under the hood) ?
OK this looks promising:
Running that gave me a Python 3.12 shell apparently running entirely in a WebAssembly sandbox!I've been trying to find a robust, reliable and easy way to run a Python process in WebAssembly (outside of a browser) for a few years.
Thanks!
Forgot to put it on the article, but the latest Python requires the Wasmer rc.5 to run! (the final release will be coming very soon)
> I've been trying to find a robust, reliable and easy way to run a Python process in WebAssembly (outside of a browser) for a few years. reply
What’s the use case? Is it the sandboxing? Is it easier than running Python in a container?
I want to be able to run code from untrusted sources (other people, users of my SaaS application, LLMs) in an environment, where I can control the blast radius if something goes wrong.
The sandboxing, especially for AI Agents.
Everyday we grow closer to my dream of having a WASM based template engine for Python, similar to how Blazor takes Razor and builds it to WASM. I might have to toy with this when I get home.
Does this work for packages with C/C++ extensions e.g. numpy and scipy?
Seems like it already does for some, assuming Pillow and FFMpeg are on the list.
``` ╰─ wasmer run python/python
error: Spawn failed
╰─▶ 1: compile error: Validate("exceptions proposal not enabled (at offset 0x191a)")
```
You'll need the latest wasmer RC for proper exceptions support.
We unfortunately didn't get the final release out quite in time...
How long should it take for "wasmer run python/python" to start showing me output? It's been hung for a while for me now (I upgraded to wasmer 6.1.0-rc.5).
"wasmer run python/python@=0.2.0" on the same machine gets me into Python 3.12.0 almost instantly.
Compilation with LLVM takes quite a while (the final release will show a spinner...).
So please wait a bit - subsequent runs will be fast, since compiled Python will be cached.
Oh so it's actually compiling everything on my machine?
Any chance `wasmer run python/python` might download a pre-compiled version in the future?
Yeah, that's mentioned as a small side note in the blog post - we are working on it, and will hopefully have it ready in a week or two!
OK got there in the end! I didn't time it but felt like around 10 minutes or more.
It did give me one warning message:
That sounds like the compilation is accidentally triggering this old frustration [0].
[0] https://github.com/python/cpython/issues/131189
Compilation was slow for me on macOS too.
Hasn't Pyodide been available for some years now?
Yes but it works only in the browser - running Pyodide outside of a browser is a lot of extra work.
My previous attempts are described here:
- https://til.simonwillison.net/deno/pyodide-sandbox
- https://til.simonwillison.net/webassembly/python-in-a-wasm-s...
What is the point of running python in webassembly outside browser?
See comment here: https://news.ycombinator.com/item?id=45365165
I want a robust sandbox I can run untrusted code in, outside of the browser.
not true
I don't know what runtime it uses but I have tests in nightly CI that run exactly like this.see https://pyodide.org/en/stable/development/building-packages-...
Interesting - I hadn't seen that before:
> Pyodide provides an experimental command line runner for testing packages against Pyodide. Using it requires nodejs version 20 or newer.
Looks like it's a recent addition?
No clue - I added that CI job around 6 months ago.
I tracked it down to this PR from September 2022, so it's been around for a while: https://github.com/pyodide/pyodide/pull/2976
I'm not sure I understand correctly: is it a new serverless offering competing with the likes of vercel and fly.io, but with a different technology and pricing strategy? And the wasm container means that I can deploy my streamlit of FastAPI ETL apps without the Docker overhead or slowness of streamlit cloud?
FFI support (like they have) is essential for any alternative Python to be worthwhile because so much of what makes Python useful today is numpy and keras and things like that.
That said, there is a need for accelerating branchy pure-python workloads too, I did a lot of work with rdflib where PyPy made all the difference and we also need runtimes that can accelerate those workloads.
Are we at the point where I can store arbitrary scripts in a sql database and execute them with arguments, safely in a python sandbox from a host language that may or may not be python, and return the value(s) to the caller?
I'd love to implement customer supplied transformation scripts for exports of data but I need this python to be fully sandboxed and only operate on the data I give it.
Arguably/pedantically, Pyodide has had this for a while: see https://developer.nvidia.com/blog/sandboxing-agentic-ai-work... for a use case.
Wasmer's approach hints at faster cold starts and better overall performance; the benchmarking against pyodide is a bit unclear, and it's unclear to me whether that would make or break viability for a use case like this.
But one thing this does make possible is if your arbitrary script is actually a persistent server, you can deploy that to edge servers, and interact with your arbitrary scripts over the network in a safe and sandboxed way!
I hadn't seen that NVIDIA article before... turns out they're running Python inside Pyodide inside WebAssembly inside Chrome inside Playwright inside Node.js! https://github.com/JosephTLucas/wasm-plotly/blob/main/server...
I'm always on the lookout for ways to run Python in a sandbox but that feels like one too many levels for me.
Pyodide inside Deno removes at least the headless browser layer: https://til.simonwillison.net/deno/pyodide-sandbox
That's almost exactly what I want to do too. I've experimented a bit with QuickJS for this - there's a Python module here that looks reasonably robust https://pypi.org/project/quickjs/ - but my ideal would be a WebAssembly sandbox since that's the world's most widely tested sandbox at this point.
Nice, but every time I look into WASM I have to wonder if containers and/or lite weight VMs wouldn’t be simpler and have less restrictions. We seem to have forgotten about microkernels and custom runtimes (like the various Erlang ones) as well…
Still, that close to native Python is an interesting place to be.
I get an https error at https://docs.wasmer.io/: net::ERR_CERT_AUTHORITY_INVALID
How does WASM replace/implement language specific features like goroutines or Python's asyncio loop, or the specifics of each language's GC?
Depending on the language, GC is either implemented in userspace using linear memory, or using the new GC extension to webassembly. The latter has some restrictions that mean not every language can use it and it's not a turnkey integration (you have to do a lot of work), but there are a bunch of implementations now that use wasm's native GC.
If you use wasm's native GC your objects are managed by the WASM runtime (in browsers, a JS runtime).
For things like goroutines you would emulate them using wasm primitives like exception handling, unless you're running in a host that provides syscalls you can use to do stuff like stack switching natively. (IIRC stack switching is proposed but not yet a part of any production WASM runtime - see https://webassembly.org/features/)
Based on what I read in a quick search, what Go does is generate each goroutine as a switch statement based on a state variable, so that you can 'resume' a goroutine by calling the switch with the appropriate state variable to resume its execution at the right point.
Are dependencies easier to install or does it work only for packages that have pure wheel support?
JuputerLite also does this. Uses local storage and Pyodide kernel (python on wasm). It has a special version of pip, and wasm versions of a lot of libraries which usually use native code (numpy etc). Super impressive.
https://jupyter.org/try-jupyter/lab/
We are actually going on another direction.
Philosophically speaking I believe we should not require a special version of pip to install packages, nor a "lite" version of Jupyter to run in WebAssembly.
We should be able to run Jupyter fully within the Wasmer ecosystem without requiring any changes on the package (to run either in the browser or the server).
I actually want browsers to support other languages natively.
Brendan Eich ( the creator of JavaScript) was kind enough chime in that it would be impossible for variety of reasons.
Obviously he knows more about this than me, but I think Google could put Dart in there if they really wanted.
WebAssembly is pretty close though.
What would "support other languages natively" give you that WebAssembly doesn't?
Ideally, sure, but that would increase the already enormous burden of building a standards compliant web browser. For a healthy web ecosystem it's important that not only trillion dollar companies can contribute or compete.
Not every single website needs to support every single browser. This is a modern convenience, I was doing QA back in the day when we still had to support Internet explorer.
Internet explorer just didn't provide the same experience as Chrome.
You were supporting the tail end of an era that is universally agreed upon as an ecosystem failure. The internet didn't provide a consistent user experience for developers or for users, it generated mountains of legacy baggage, and it was frustrating for everyone.
I was doing building and qa when we had to support Netscape Navigator. Not having a varied set of options for browsers comes with clear downsides.
I think we agree ?
For example if Firefox decides to add Rust support it doesn't mean every other browser needs to support it.
Just a handful of web experiences are going to be exclusive to Firefox. As is having Chrome as the only browser most people use isn't great for innovation.
Back to Internet Explorer ActiveX times.
Maintaining a browser is already hard enough, it's a very tough sell to convince 3+ browser vendors to implement a new language with its own standard library and quirks in parallel without a really convincing argument. As of yet, nobody has come up with a convincing enough argument.
Part of why WebAssembly was successful is that it's a way of generating javascript runtime IR instead of a completely new language + standard library - browsers can swap out their JavaScript frontend for a WASM one and reuse all the work they've done, reusing most of their native code generator, debugger, caches, etc. The primitives WASM's MVP exposes are mostly stuff browsers already knew how to do (though over time, it accumulated new features that don't have a comparison point in JS.)
And then WASM itself has basically no standard library, which means you don't have to implement a bunch of new library code to support it, just a relatively small set of JS APIs used to interact with it.
Webassembly does not generate JavaScript IR. Not sure where you got that idea. Maybe you're thinking of asm.js?
I tried to understand what is "Wasmer Edge" but couldn't. They say on the front page "Make any app serverless. The cheapest, fastest and most scalable way to deploy is on the edge." and it seems like I can upload the source code of any app and they will convert it for me? Unlikely so.
Also it says "Pay CDN-like costs for your cloud applications – that’s Wasmer Edge." and I don't understand why I need to pay for the cloud if the app is serverless. That's exactly the point of serverless app that you don't need to pay for the servers because, well, the name implies that there is no server.
Confusingly, "Serverless" doesn't mean there's no server. It means that you don't have to manage a server yourself.
My preferred definition of serverless is scale-to-zero - where if your app isn't getting any traffic you pay nothing (as opposed to paying a constant fee for having your own server running that's not actually doing any work), then you pay more as the traffic scales up.
Frustratingly there are some "serverless" offerings out there which DO charge you even for no traffic - "Amazon Aurora Serverless v1" did that, I believe they fixed it in v2.
Then it should be called manageless?
Still confusing, since infrastructure you don't have to manage yourself is sometimes called "managed". It makes sense from the perspective of "you are paying us to manage this for you".
It's a terrible name, but it's been around for over a decade now so we're stuck with it.
I mostly choose not to use it, because I don't like using ambiguous terminology if I can be more specific instead. So I'll say things like "scale-to-zero".
these are just automanaged cloud servers, I guess?
Thanks for the feedback.
Normally, if you want to run your apps serverlessly you'll need to adapt your source code to it (both AWS Lambda and Cloudflare Workders require creating a custom HTTP handler).
In our case, you can run your normal server (lets say uvicorn) without any code changes required from our side.
Of course, you can already do this in Docker-enabled workloads: Google Cloud or Fly.io, for example. But that means that your apps will have long cold-start times at a way higher cost (no serverless).
Hope this makes things clear!
Thank you for the explanation, now I can better see the differences between "serverless" platforms although I am still a little disappointed that so called "serverless" apps still require a (paid) server despite the name.
This bugs me all the time. Ethernet is serverless. Minesweeper is serverless. AWS Lambda is quite serverful, you're just not allowed to get a shell on that server.
I believe "serverless" in this sense means "like AWS lambda". Theoretically you upload some small scripts and they're executed on-demand out of a big resource pool, rather than you paying for/running an entire server yourself.
It seems like a horrible way to build a system with any significant level of complexity, but idk maybe it makes sense for very rarely used and light routes?
"Serverless" means Function-as-a-service, think of it like CGI-bin scripts but you pay per execution.
Would it be possible to make it work on iOS or android? I always missed better support of python on mobiles. In the past used PythonKit rapid prototype and interop with Swift but had limited set of modules. Wish to use this in react native for interop between js and python
Yes, running Wasmer Python package on iOS or Android is 100% doable.
In fact, we want to even run it on browsers.
We are small team, so we have to pick our battles very carefully, but we would welcome any patch to make it work (if it doesn't work already!).
To be clear "fast" means "almost as fast as native Python", not "actually fast". Impressive achievement anyway.
"fast" is not "blazing fast"
Wondering how this compares to e.g. Jep for Java/Python interoperability (https://github.com/ninia/jep).
Would be way more exciting if it could _compile_ Python to Wasm (or does it?).
Hmm, I tried it out.
> wasmer app create --template=static-website
gets you from empty folder to initialized template and deployed static website in like 10 seconds when logged in.
Pretty nice.
What does that do? A static website with some language compiled to wasm running in the browser?
Does your solution support interop between modules written in different languages? I would love to be able to pass POD objects between Python and JS inside the same runtime.
For a backend project in Java, I use Jep for Python interoperability and making use of Python ecosystem. It gives me a "non-restricted" Python to have in my Java code, something I'm quite happy with. Wondering how this compares to that .
See https://github.com/ninia/jep
WASMBots: Fast, Cheap, and Out Of Control!
https://people.csail.mit.edu/brooks/papers/fast-cheap.pdf