Skip to content

Serve & deploy

How a Mateu UI reaches its users is independent of how it was authored. There are two shapes, and an app can use both.

A server hosts the Mateu endpoints (/mateu/v3/…) and the renderer’s static assets. Each request instantiates the view model, runs the action and answers with the wire model; nothing is kept in memory between requests, so the server scales horizontally without sticky sessions.

Choose a backend when screens need server-side logic: database access, domain rules, secrets injected into proxied API calls, server-side validation.

RuntimeSetup
Spring Boot MVCSpring Boot MVC
Spring Boot WebFluxSpring Boot WebFlux
QuarkusQuarkus
MicronautMicronaut
Helidon MPHelidon
ASP.NET CoreC#
FastAPIPython

A UI authored only in YAML is served by a backend too when you want one: the generated project is a Spring Boot application whose only Java is its main method (YAML quickstart).

The model is exported at build time into plain files — index.html, a manifest.json with the screens, and the renderer’s assets — and served from any static host or CDN. The browser calls your REST APIs directly, as named in the data source catalogue.

  • Static bundle — exporting, what works without a backend, hybrid bundles.
  • A 100 % static UI — authoring for it, the static-safety check, hosting, auth.
  • Environments — one catalogue, re-pointed per deployment, even after the bundle is built.

Several deployed UIs — on different stacks, owned by different teams — can be composed into one console. See UI federation.