We are working on it. Firefox is currently unsupported due to Atomics.waitAsync being not yet enabled by default. Safari on the other hand has some subtle inconsistent behavior at the edge between getters, global variables and `this`.
BrowserPod is intended to work across all browsers, but we are not there yet.
Having banged my head on years/decade old inconsistencies between Chrome and Firefox with respect to webrtc APIs, some of these inconsistencies will never be ironed out.
But also, imo, Chrome is way more entrenched that LLM agents. I'm sure people will be happy with chromium being containerized this way.
I understand that marketing your tool for AI/agents is good business nowadays, but using the browser sandbox through WebAssembly seems way over-engineered compared to even a Docker container.
That being said, this would be good as a Coder alternative for basically instant on-boarding if the UX allows for it. Not to mention the great use this would get in a classroom environment, especially when all you've got are Chromebooks.
Impressive tech anyhow. Hopefully you'll find some business model that would justify open-sourcing this someday (other than a last show of goodwill after bankruptcy, as is how I unfortunately often learn about interesting projects).
Really excited for this product, the industry needs alternatives to WebContainers which has become more restrictive around licensing. Also great to see that non-node runtimes (ruby / python) will be supported. Having said that, really wish this was open-source, even if that meant the OSS version had more limited features then the commercial alternative.
Very interesting tech. Ephemeral, high-fidelity preview environments that require zero setup are a key enabler. They let you rapidly validate changes within the complete context of a web or mobile app, accelerating feedback loops and cutting friction for minor updates. This also empowers business users to safely implement small, self-contained UI adjustments which is particularly powerful when combined with LLM-driven suggestions.
I wonder if this would enable the truly "serverless" application I've been thinking about. Imagine shipping a whole Rails/Laravel/Wordpress app to the user to be run in their browser with sqlite. Technically you would only need a CDN to distribute the app.
Unfortunately when visiting the demo (https://vitedemo.browserpod.io/), the terminal just shows "/lt/npm/bin/npm.js install" and does nothing more. There does not seem to be any errors in the developer console and no network requests have failed either. This is on Chrome v140, Windows 10.
"In particular, we plan to support React Native environments in 2026."
Genuinely curious, what is the benefit or use case of this? I thought react native runs in the web already.
React native can indeed target the We. Instead we are referring to running the native build toolchain for react native, which is required to build android apps, in the browser.
> Incompatible Browser
> This demo requires a Chromium-based browser (Chrome, Edge, Brave) to function properly.
> Please switch to a compatible browser to experience the full capabilities of BrowserPod.
well, that sucks.
We are working on it. Firefox is currently unsupported due to Atomics.waitAsync being not yet enabled by default. Safari on the other hand has some subtle inconsistent behavior at the edge between getters, global variables and `this`.
BrowserPod is intended to work across all browsers, but we are not there yet.
Having banged my head on years/decade old inconsistencies between Chrome and Firefox with respect to webrtc APIs, some of these inconsistencies will never be ironed out.
But also, imo, Chrome is way more entrenched that LLM agents. I'm sure people will be happy with chromium being containerized this way.
I understand that marketing your tool for AI/agents is good business nowadays, but using the browser sandbox through WebAssembly seems way over-engineered compared to even a Docker container.
That being said, this would be good as a Coder alternative for basically instant on-boarding if the UX allows for it. Not to mention the great use this would get in a classroom environment, especially when all you've got are Chromebooks.
Impressive tech anyhow. Hopefully you'll find some business model that would justify open-sourcing this someday (other than a last show of goodwill after bankruptcy, as is how I unfortunately often learn about interesting projects).
Really excited for this product, the industry needs alternatives to WebContainers which has become more restrictive around licensing. Also great to see that non-node runtimes (ruby / python) will be supported. Having said that, really wish this was open-source, even if that meant the OSS version had more limited features then the commercial alternative.
Very interesting tech. Ephemeral, high-fidelity preview environments that require zero setup are a key enabler. They let you rapidly validate changes within the complete context of a web or mobile app, accelerating feedback loops and cutting friction for minor updates. This also empowers business users to safely implement small, self-contained UI adjustments which is particularly powerful when combined with LLM-driven suggestions.
I wonder if this would enable the truly "serverless" application I've been thinking about. Imagine shipping a whole Rails/Laravel/Wordpress app to the user to be run in their browser with sqlite. Technically you would only need a CDN to distribute the app.
What you describe is 100% possible. Rails is one of our priorities. PHP is also easy to achieve.
Imagine being able to sync that sql database with some sort of cloud storage(s3, google drive, one drive).
Or, even better imagine being able to load your own applications in into your cloud storage and run them in browser remotely.
Unfortunately when visiting the demo (https://vitedemo.browserpod.io/), the terminal just shows "/lt/npm/bin/npm.js install" and does nothing more. There does not seem to be any errors in the developer console and no network requests have failed either. This is on Chrome v140, Windows 10.
"In particular, we plan to support React Native environments in 2026." Genuinely curious, what is the benefit or use case of this? I thought react native runs in the web already.
React native can indeed target the We. Instead we are referring to running the native build toolchain for react native, which is required to build android apps, in the browser.
Very cool. I've spent quite some time working on compiling Nodejs for WASIX. Not an easy task.
Would love to see this open sourced at some point.
I don't see any indication of this being open source.
Indeed, it's not. It's possible we might decide to release the code in the future, but for the time being we are keeping it proprietary.