You will be able to make any Rest API request in a backend workflow.
Then this workflow will be available in any workflow in Interface (the front-end app) 
Does that answer your question, or did you mean something else?
Are these routes gonna be exposed as REST endpoints for other services to call? If so, I guess youāre also thinking of letting people be able to set CORS and more.
Thanks a lot for your message, Iām here to answer all your questions! 
Letās take the time to go through everything. And as you know, we love to iterate, so your feedback will be super valuable to help us make this feature as user-friendly as possible.
Backend workflows ā how it works
Those backend workflows are converted into Node.js code. Weāre using a lightweight library called Hono, which allows us to deploy the serverless backend anywhere, so the backend is highly portable and can run on any serverless platform.
Supabase integration
At the beginning, the Supabase panel will be read-only. We want to learn from how you use this new backend tab before adding more complex features.
That said, itās technically possible to push backend workflows into edge functions, so weāre keeping the door open for many possibilities in the future.
Security
Every backend workflow includes a middleware layer that checks the rules you define. You can think of these workflows as standard API endpoints.
If you need specific access control, you can simply add a action at the beginning of the workflow. Youāll also have an action called āSend Responseā to customize error messages as needed.
Additionally, you can set a workflowās access rule to āInternalā, which makes it callable only by other workflows. Itās like turning a workflow into a private function. Perfect for building custom middleware or centralizing access control logic.
3 Likes
Yes, the endpoints will be exposed. Weāll also generate a Swagger documentation so you can easily explore them and share the docs with others if needed.
Additionally, weāre discussing the possibility of turning any endpoint into tool for an MCP server.
Thatās a good point for CORS, youāll have a dedicated settings panel where you can configure options, including CORS policies, what should appear in the Swagger documentation, and what should be exposed through the MCP server.
2 Likes
The thing is some usecases such as with long running tasks, serverless doesnāt work as well as on the classic hosting, e.g. Supabase still has limitations - even though they got better. Big kudos for using Hono, itās great.
1 Like
Does this new backend setup when using in conjunction with Xano or Supabase then allow for an offline-capable app? Where is the data residing, on-device or in the cloud? Will there be built-in sync functions? Should I be thinking about this feature like how SQLite can be used with Flutterflow apps?
True! You can totally run it on a regular Node.js server too, thatās one of the nice perks of using Hono. This is still an open subject even internally for our own hosting.
1 Like
Offline capabilities will not be enabled with these features. Implementing them is significantly more complex on the front-end side, as it would require allowing customization of the service worker. This is challenging because we would need to account for many edge cases to avoid serious issues, such as preventing situations where users are unable to update their pages or data. It is something we may consider exploring in 2026.
Regarding data storage, it will reside in the cloud, in a scalable PostgreSQL database. You will also have access to the database URL if you wish to connect directly. However, the primary and recommended way to interact with it will remain through workflows and the native actions we will provide.
4 Likes
@flo Would an idea be to at least support better SEO for WeWeb CMS?
I guess users could use supabase/xano for non SEO required pages, and could use the WeWeb backend for SEO supported pages.
1 Like
Hi Flo!
Amazing news! Looking forward to try the updates!
May there be any changes or restrictions to the self-hosting option given the new back-end feature?
1 Like
That preview looks pretty insane! Iām assuming weāll also be able to export the backend data (to avoid vendor-locking-anxiety 
)
Iām curious to see how youāll implement assets into the backend. Iāve been using cloudflare images for my weweb app because of how I can pull pre-defined sizes from one uploaded asset like thumbs, etc. If you guys integrate the backend with proper asset compression and image transforms, this will become absolute killer!!
2 Likes
Dope! good work weweb team!
1 Like
āReside in the cloud??ā
Which cloud?? Weweb cloud??
I really hope you guys donāt lock us in with this full stack push. Cos you say the backend code is āexportableā. So I am assuming the backend code here refers to the APIs written in Hono. But the database is NOT part of the exportable backend it will seem. So basically vendor lock-in if one uses weweb tables as I canāt get that data anywhere thatās not Weweb cloud. Cos exporting the server-side logic but not exporting the database still means one violates HIPAA and GDPR too. I like the feature for beginners but for complex use cases itās a legal nightmare
I hope this feature is not compulsory, and as such I can continue to use weweb as my frontend builder and leave anything backend where I want it to be - slef-hosted Supabase.
I am quite worried about HIPAA compliance when you are not a HIPAA-compliant company yourself (and you didnāt need to as a frontend builder) but now as a full-stack builder then that becomes a thing.
Anyway please I hope this new update doesnāt break things in the Editor (some of the complaints I logged from the last update have still not been fixed). But I am very happy to see the new push to be full stack and I am PARTICULARLY excited about the custom coded component editor.
In closing, I wish you focused on being the worldās best frontend editor rather than being so many things at once, but I think so far you are pulling it off okay, so fingers crossed that you continue to do so.
Cheers
Yes, the backend will be fully exportable. Users will be able to self-host the full-stack app with zero ties to WeWeb.
2 Likes
No donāt worry, the DB will also be fully exportable and the feature is not compulsory.
3 Likes
Oh this is excellent news! Thank you so much guys! Now I am looking forwaed to trying out the new backend builder then!
1 Like
Yeah I meant exporting the db data as cssās for example.. 
Hello Everyone,
Iām writing here after watching Florianās demo of the back-end ā and honestly, youāve completely changed the game. Itās a brilliant move. The design is slick, and the experience (as we all know) will only keep getting better.
Since this full-stack app will be fully exportable, Iām curious about your thoughts on future SSR settings. Do you think these will be supported down the line?
Iām also wondering whether, with this architecture, weāll still need an external back-end like Xano for complex queries. Will we be able to write raw SQL queries directly to the Postgres database ā or will it work more like Xano, where we can inject Lambda-style logic inside workflows (which is fun but can be CPU-intensive and expensive)?
From the beginning, Iāve believed that building a true full-stack experience was the right bet ā and seeing this now, Iām convinced. You have the best engineers and product builders in the no-code space by far. The fact that weāll be able to export the entire stack is also a huge value booster for our company. Being locked into Xano with their CPU pricing policies has been a real constraint, and this changes everything.
Thank you again ā truly impressive work.
5 Likes
SSR is apparently still up for discussion. I was also hoping that we would at least have SSR for the native backend.
2 Likes