I’ve been looking around all over for information about these aspects and how they tie together and how they function both as a group and separately.
My main goal is a b2b saas, but I know that what I’m making will require certain industries that have high-security requirements to request some form of on-premise hosting whether it is their own cloud, their own physical server, or even in the oddest cases, their own local storage that is air-gapped, and some that won’t require anything too strict besides basic security.
I’m still learning the technical aspect of all of this, so excuse me for perhaps not explaining my question the best way.
Regarding the self hosting aspect of weweb. I’ve read a few threads about it, but I’m still not following how it works. My interpretation of self hosting was that even if you self host, the application can’t be hosted on weweb’s server or any form of cloud server. You can only do one or the other. But then I read up on exporting and I found out that you can export the code and host it anywhere on an unlimited number of servers. So whats the difference between exporting and self hosting? Are they basically the same?
Regarding exporting, if I export the application, how would the application work for the client? By that, I mean would it still function as a complete software? I saw the demo exported file on your docs, but I had no idea how to get it to work as a complete software. I unpacked the zip file, but I had no idea what was what nor how to get it to work as an application. On the exportation, would it be possible to export it to github as a private repository and let the client install it that way from github? Would every client beable to host the exported code on the server?
Regarding the frontend aspect of weweb in conjunction with the exported or self hosted application, what is wewebs purpose in the self hosted and exported applications? How does the program and weweb work if the code is exported and on a server that isn’t on weweb’s server?
How does the backend work on a exported or self hosted application?
I read a post about air-gapped applications. Is that even possible on weweb?
Thanks for asking, as I’m sure this is a difficult topic for many users to grasp and we probably have a lot of room for improvement in explaining it better.
There is indeed two different level of selfhosting.
a) code export : you can get the builded version (ready to be served) version of your application and host it like any website, its pure html/js/css. A modern and easy way to host such application is through service like Vercel or Netlify. You push the code to a repository, you link the repository on the hosting service, and it can automate the deployment. You can also put your website inside your own infrastructure and any kind of web server.
b) self host : Some features rely to our weweb server (a special web server we built), this server can also be self hosted and so you can host your web app the same way we do it and keep the private page system running for example.
When you export the code you can both get the raw files or the builded files. The raw files allow you to build it yourself if you have to run some complex pipline before (like code analysis tools) or update something in the code. You can export the code (builded or not) and push it to a private repository.
We are a front end builder. The core application (the one you export) is fully run on the browser. It doesn’t need weweb servers to works.
You connect your front-end to an external backend. If you connect to supabase, xano, or through rest api it will still work the same way when host by us or selfhosted by yourself. The frontend will run in the user browser and make api call to the connected external back end.
Note : Some of our plugins require a special weweb microservice to works, they cannot be used when selfhosted, it’s an important difference. We dont provide the plugins server, only the main server used to host your app. Plugins like Airtable, OpenAI, Smartsuite or SQL require such microservice in order to remain secure (hide the private API key). As long as your front end connect directly to your backend there is no issues.
If by air-grapped you mean hosted inside a network with no access to internet, we already have many customers doing it and it’s working fine. They choose either to code export and host it in their network along side their own backend, or choose to also use our weweb server to host it.
Be aware we’re working on redesigning selfhost and the way weweb works in general, so it’s possible that a lot will change over the next few months.
If you need any further information, please do not hesitate to ask.
Thank you!! I’ve been trying to figure this aspect out for the longest.
Regarding the changes, are they to simplify the process or add more features?
Another question. Do you all have someone who could help me with the process by showing me how the exporting and hosting aspects work or not? Or is it only on the super expensive plans that weweb customers get help like that?
Just to clarify the simplicity of all this - in the the vast majority of cases - 100% so far in my experience (which is a handful) - you do not need the “weweb server” component. It is middleware for abstracting a number of the features that use API keys. But for the mainline “writing to work with a backend” you can use the code export and it works brilliantly. Effectively you’re downloading the HTML, javascript, CSS and asset files, and then uploading them to your server of record which just serves the files statically. Nothing super-special required. Our clients have sent to digital ocean, netlify - but you could make it work fairly easily anywhere else because there’s no build step required.
In most situations, code export will take care of everything you need. Some of the plugins need the server connection (e.g. openAI) because it does the job that would ordinarily go with a back-end. But the most-used plugins do not (e.g. Xano, Supabase) largely because they are about connecting to a proper back-end.
Once you export, sure you can run it locally on a web server of your choosing. This is a simple one: http-server - npm
Be aware we’re working on redesigning selfhost and the way weweb works in general, so it’s possible that a lot will change over the next few months
Are you able to give us some indication of the general principle of what this might mean? For example, one of the main reasons that I have not used WeWeb so far is that I cannot choose a hosting region in my country to host my WeWeb app. Sure I can subscribe to a plan that allows me to export my app and place it on my own infrastructure, but that reduces the value of the low/no-code approach.
I want the ability for my entire app to be hosted on WeWeb infrastructure but in my region of choosing. Is this something that is being worked on?
It’s still a work in progress, so it shouldn’t be seen as set in stone., but the general idea is to get ride of the WeWeb Server, and so self host will be only code export.
It will allow us to move forward with the published app, implement many performance improvement, reduce the latency and eliminate downtime risk (as every app hosted by WeWeb will not be served by a bunch of servers anymore but only by global CDN everywhere around the world).
In order to achieve this transition we will move the private page system logic from the weweb server to the web app router itself as most of app already protect their data behind their own backend, we feel we dont have to protect the access to the page itself anymore, only prevent unauthorised navigation.
It means instant page navigation and no more latency when accessing a private page that need to be validated through multiple layers.
This makes good sense! Most pages Should be public and just redirect on the client side. As the sensitive data often is hidden in a backend with autherization.
Whould you say that now 13. September the wewebserver is not needed to use the wewebAuth plugin anymore?
Hi, we achieved the transition since. The WeWeb server is deprecated and lo longer needed nor recommended to selfhost your app.
WeWeb Auth as some others plugins still depend of WeWeb microservices, so when you selfhost your app a request will goes to our servers to execute its logic.
