[2354902707] Upstream Reporter: BillKlineVT
Upstream issue status: Closed
Upstream description:

What do you want to improve?

Need clarification on when to use "dev mode" deployment of a single-container SonataFlow vs. the Orchestrator Helm chart/operator to support the Orchestrator plugin. Are there certain features/use cases that are only supported by the more heavyweight operator?

What does the current documentation state?

The Orchestrator plugin is configured by default ("dev mode") to create a single docker container as the backstage-internal-sonataflow service to support Backstage calls for Orchestrator workflows.

When considering a production use of the Orchestrator plugin, the documentation steers one to much more complex deployment of OpenShift, and the Orchestrator Helm chart which deploys RHDH (Red Hat Developer Hub) Backstage, OpenShift Serverless Logic Operator (with Data-Index and Job Service), OpenShift Serverless Operator (Knative Eventing and Knative Serving).

What would you like to be added/updated in the documentation?

Examples of when a single-container SonataFlow should be used vs. when the full SonataFlow Orchestrator operator should be used