The Pipeline Framework

Appearance

Runtime Layouts and Build Topologies ​

This section is the application developer guide for shaping deployments after scaffold generation. In the standard flow, you design in the Web UI Canvas Designer, download the scaffold, then choose how many deployables you actually want to run.

Three terms you must separate ​

These terms sound similar, but they answer different questions:

  1. Runtime layout: where TPF logically places the generated runtime pieces.
  2. Build topology: what Maven and CI actually build.
  3. Transport/platform: how generated pieces call each other and what kind of runtime they target.

Runtime layout (logical) ​

Defined in pipeline.runtime.yaml.

  • Decides where the orchestrator, regular steps, and plugin side effects logically run.
  • Values include modular, pipeline-runtime, and monolith.
  • Drives generated calls and validation.

Build topology (physical) ​

Defined by Maven modules and POM structure.

  • Decides what artefacts are produced (how many JARs/containers).
  • Decides what is actually deployable in CI and production.
  • Is not rewritten automatically by runtime mapping.

Transport mode (call mechanism) ​

Values include GRPC, REST, and LOCAL.

  • Decides how generated components call steps.
  • Orthogonal to layout/topology.

Platform mode (deployment target) ​

Values include COMPUTE and FUNCTION (legacy aliases: STANDARD, LAMBDA).

  • Decides whether generation targets standard Quarkus services or function-style entry points.
  • This page provides the canonical deeper reference for choosing between COMPUTE and FUNCTION.
  • Constrained by transport and step-shape compatibility (Function mode requires REST; unary and streaming shapes are supported via generated function bridges).
  • Orthogonal to runtime layout/topology.

Who this guide is for ​

Application developers using the normal onboarding path:

  1. Design in Canvas.
  2. Download scaffold.
  3. Adjust runtime layout and build topology for your target environment.

Why people get confused ​

You can set layout: monolith and still not have a real monolith artefact if the Maven topology is still modular.

  • Runtime mapping changed the logical placement.
  • Maven still produced modular deployables.

Both layers must be aligned to achieve your intended runtime shape.

What runtime mapping changes automatically ​

What runtime mapping does not change automatically ​

  • Parent/module structure in Maven.
  • Number of runtime artefacts produced.
  • CI lanes needed to build/test a new topology.

::: note Choosing monolith does not remove per-step service modules from the scaffold. monolith-svc acts as the runtime packaging module and aggregates service sources at build time. :::

For Maven topology changes, use the migration playbook.

Start here ​