Web apps (server-rendered)
ESTAGE includes a server-rendered application target. A Web app is a real Next.js project with its own server, built from the same AI chat as everything else. It exists for the products a static site cannot carry: server-side rendering for pages that must be complete in the HTML, server-side logic on every request, and dynamic routes at scale.
Website or Web app?
Section titled “Website or Web app?”| Website | Web app | |
|---|---|---|
| Rendering | Built once, served as static files | Rendered per request on your own server |
| Best for | Landing pages, marketing sites, blogs, stores | Dashboards, portals, catalogues, anything server-driven |
| Server | None needed | One server per app, sized and scaled by you |
| Cost | Included with the project | Billed per app |
Most projects want a Website. Reach for a Web app when the page has to be assembled on the server before it reaches the browser.
What a Web app can use that a site can’t
Section titled “What a Web app can use that a site can’t”- Server-side rendering — the HTML arrives complete, which matters for pages built from live data and for crawlers that shouldn’t have to run your JavaScript.
- Real npm packages — the app has a genuine
package.json; ask for a library and the AI installs it into the app. - API routes — server endpoints inside the app itself, for work that must not run in the browser.
- The Community toolkit — the community screens (feed, courses, challenges, live rooms) rendered inside your own site. It needs a server, so it’s a Web app feature.
How it works
Section titled “How it works”- Add it to a project. A Web app is a target you add alongside your existing site; the project keeps one team and one domain across both. See Apps inside a project.
- Build in a dev workspace. The app runs on its own dev machine while you work on it, with the live preview attached to the running server. That machine sleeps when you’re not working, so it isn’t burning capacity between sessions — dev time is sold as a package of hours and only runs down while you’re actually building.
- Publish to its own machine. Publishing deploys an immutable release to a dedicated, always-on machine that you choose at Publish — your live traffic never shares compute with another customer. Deployments roll without downtime, and a failed one rolls back.
- Keep working while it builds. Publishing doesn’t block the builder: start the deploy and carry on editing while it runs.
- Size and scale it. Pick the server size in Settings → Server (in a multi-app project the Server tab always shows the machine of the app you have open), and raise it as traffic grows.
- Give it a domain. Web apps take a custom domain the same way sites do, with automatic HTTPS.
What you still get
Section titled “What you still get”Everything project-level applies: the AI chat and its validated write path, the visual editor and element inspector, pages, version history, team members, and a Dedicated Cloud backend if the app needs a database and accounts.