I’ve been playing around with deploying oTToDev to GCP – and for the most part got it done. However, I notice a dependency to the original repo when oTToDev actually tries to create files and previews as opposed to just displaying them. Attached is a screenshot. Any thoughts from the community ? This issue happens only in a GCP deployment, not when running oTToDev locally
2 Likes
That’s really strange! I’ll have to look into that. Did you see where in the codebase the original repo/URL is being referenced?
I believe it has something to do with the webcontainer technology that stackblitz.com uses. I tried both on oTTo and the original Bolt.
This is the technology that allows Bolt to create files and directories.
Interesting! Could you expand a bit on why you think it’s in action-runner.ts/what you found there?
I was able to get oTTo dev running on GCP. I think the core issue is that WebContainer is StackBlitz commercial product – https://webcontainers.io/
Will continue investigating.
2 Likes
God dammit, this means we have a big issue. I checked in to it, and while web container API is MIT licensed, that is what I looked at before, webcontainers themselves are not and are proprietary.
Free to use only for non comercial usecases.
They also have this webcontainer-core/LICENSE at main · stackblitz/webcontainer-core · GitHub
But that is only repo for issues on WebContainers, not really tech itself…
This potentially puts a huge dumper on adoption of bolt for comercial use cases.
2 Likes
Did some search for alternatives and only one I found so far is WebVM.
It has its own limitations like reliance on Tailscale VPN for networking, is probably slower than WebContainers, but its full Linux implementation, so it can run other things besides Node.js, comes with python prepackaged.
But not Node.js
Would be good for it to have Node.js with npm install support packaged in to be a dropin replacement for WebContainers…
1 Like
Hi @wonderwhy.er ,
Thanks for bringing this up, I would also like to try it on OCI (Oracle Cloud Infrastructure for those who are not familiar 
) , can you let us know if you deployed on GKE?
2 Likes
Well, for me, what I like about Bolt.New setup is 0 dependency on anything, it just runs contained in browser. That makes it super easy to support and roll out, and also with 0 infrastructure costs. Great for upstarts.
Moment you bring in server side or local containers is moment it becomes not as portable and easy to run.
So, as far as I am concerned I have 0 interest in those directions.
BUT, that is potential beauty of it being Open Source.
We can make WebContainers an optional default dependency that can be switched for WebVM, or cloud containers, or local Docker container and so on. I am for supporting such flexibility!
But for me something like WebContainers is a desirable default.
5 Likes
Love your thoughts here Eduard! That is really too bad there could be a licensing issue with Bolt.new because it relies on the webcontainer under the hood. The API is under the MIT license as you said… could you argue that is what is being leveraged for Bolt.new, or are you forced to say the full proprietary technology is within it?
I think its worth reaching out to StackBlitz, I will try to ask in their Discord. But it looks like tech itself is licensed differently. Needs more exploration.
Here are some things I can find
The API that we are releasing today allows headless access to WebContainers, allowing developers the flexibility to build their own user applications on top of the technology. As with our core products, we are committed to being free for open source use cases and have support & licensing available for enterprise use cases.
Here is page of https://webcontainers.io/
Actually found this page Commercial Usage | WebContainers
All in all I do not have confident asnwer, I will reach out in Discord to StackBlitz
Asked here: Discord
6 Likes
Awesome, I appreciate the research and you reaching out to them a ton!
1 Like
First and foremost, here to help figure out and break this dependency if it is one. I have noticed that based on the current setup flow, the system is definitely expecting access to what @wonderwhy.er has discovered. I do believe that while using ollama local with various models, this error related to webcontainers.io could be responsible for some failures I’ve seen in actually executing the container/displaying in the preview window when an artifact is loaded.
Going to learn a bit about WebVM in case an alternative is necessary. It looks interesting either way.
Do we have an issue we can use to centralize efforts around this?
2 Likes
Wait, now that I get to look at it, webcontainers-core is MIT licensed. What exactly is the concern here?
Edit: Right, their page defines some commercial for-profit usage. Kinda hard to square that with what the MIT license is defined as.
I’d definitely like to hear what stackblitz has to say about that arbitrary restriction on an MIT-licensed system.
1 Like
Thanks for chiming in Chris!
It is pretty confusing that some of what they say seems to contradict an MIT license. I’m super curious to hear what they say once they get back to @wonderwhy.er.
Looks to me as though the content of the webConainrs-core repository (marginal amounts of documentation) are MIT licensed, not the subject of the documentation. Nothing new here though, just a company trying to leverage a bunch of free labor in support of an infrastructure-tied end product they intend as their primary revenue stream. After all, it’s damn near impossible to keep a UI proprietary in any real sense, so they have to build a moat around the one product they can hid behind an API. The fact is though, that we can reverse enginer their runtime containers and webVM is half way there. I trust you’ve seen other Webasm based implementations of things like Dosbox. or the MacOs9 emulators used on for example https://archive.org for insalling and running various piecs of abandonare sofware.
In fact the superior project would be to build a framework that allows compilation of any linux kernel (ad base utils) into a webasm runnable environment.
That being arguably too ambitious, some questions:
Stackblitz uses CloudFlaire workers to execue the enviroments. My recollection is they’re meant to be stateless and short term processes, so I wonder what else they’re layering into that stack… This may explain why it seems to be a losing proposition to run backnd-heavy node servers within wbConainers as currently constituted
Is it architecturally superior to implement a filesystem and runtime separately, or would we be better off with true containerization?
I may be preferable to implement tru openContainer spec’d containerizaion (docker or otherwise) as the infrastructure based service behind this/any derivative fork of Bolt.
UPDATE: A quick review of the WebVM project shows it does in fact support Node.js in it’s current implementation Will have to give his a litle thought, but it’s very likely that the protected/protectable part of Stackblitz’s offering is merely the server side implementation of their API that runs the webVM-like webcontainers on available remote infrastructure (cloudflaire) bhing their server api, toll road.
UPDATE 2: The more I read about WebVM, the more I think Stackblitz just grabbed it, deployed it and put a wrapper around it
3 Likes
Some insight to potentially using WebVM after some initial digging:
- TCP/UDP handling, since it’s not available native in the browser is handled with WebVM via tailscale. There is an alternative in headscale, my concern would be any limitations in terms of architecture (x86 versus arm, etc) if the project was to go that route.
- WebVM does seem to base itself on standard containerization tech (Linux exec based on Dockerfile), which does make the system more accessible to new devs.
- Mini.WebVM seems to pride itself on the docker-based containerization mentioned above, but does allude to some limitations in terms of deployment artifact size ~1-2gb. For small test NodeJS projects including node_modules this would not be a hindrance for initial validation & testing.
- The observed webcontainers.io dependency mentioned in this thread does seem to prevent me from having the container spin up and run my initially-prompted project when it comes to the
npm run devstep with our fork; Once I have myself in a known good state locally I’ll dig into this further.
Hope this adds some context, any other insights are welcome & helpful.
Edit: FYI, WebVM is based on cheerpx on the virtualization side, which based on the licensing doc linked here may also require a commercial license outside of non-commercial/academic work.
1 Like