# Web apps (server-rendered)

> ESTAGE can build a server-rendered Next.js application with its own server per app — real npm packages, API routes, a dev workspace billed by the hour, and a dedicated machine for your live traffic.

Source: https://knowledge.estage.com/platform/web-apps/
Part of the ESTAGE knowledge base (https://knowledge.estage.com). Full corpus: https://knowledge.estage.com/llms-full.txt

---
**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?

| | 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

- **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](/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

- **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](/platform/apps/).
- **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.

:::note
A Web app's server, storage, and subscription are tied to its Estage project ID, so a Web app
**cannot be [re-bound](/project-settings/general/#re-bind-to-another-estage-project) to a
different Estage project** the way a website can.
:::

## 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](/cloud/) backend
if the app needs a database and accounts.