Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt

Use this file to discover all available pages before exploring further.

This guide describes how external traffic reaches FlowX services on 5.9.x: the two-host model (admin and public), the per-service route table, and CORS handling per deployment.

​
Overview

On 5.9.x, FlowX services are exposed through either Kubernetes Ingress resources (the default) or Gateway API HTTPRoutes, with each service toggled independently. CORS handling moved out of ingress annotations and into the service code, with allowed origins set via an environment variable on each backend service. Two things changed in 5.9.x compared to 5.1.x routing:
  1. Gateway API HTTPRoutes are available as an opt-in alternative to Kubernetes Ingress. Switching a service to HTTPRoute mode is coordinated with FlowX during the upgrade window and requires the Gateway API CRDs (gateway.networking.k8s.io/v1) plus a compatible controller on the cluster.
  2. CORS moves to the application layer. NGINX CORS annotations are no longer the source of truth. Each backend service reads its allowed origins from APPLICATION_CORS_ALLOW_ORIGIN; allowed methods, headers, and credentials are baked into each service’s application.yaml with sensible defaults.
For the migration path from 5.1.x to 5.9.x, see Ingress routing and CORS.

​
Service route reference

FlowX services route under two host groups: admin (designer and admin-side APIs) and public (runtime renderer and integration callers). A few services additionally use a third group called admin-instances for runtime instance APIs on the admin host.

​
Admin routes

ServiceExternal pathBackend receives
admin//
application-manager/appmanager/
audit-core/audit/
authorization-system/auth/
cms-core/cms/
document-plugin/document/
events-gateway/api/events/api/events/... (path preserved)
integration-designer/integration/
license/license/
notification-plugin/notification/
organization-manager/org/
process-engine/onboarding/api/api/...
runtime-manager/rtm/api/build-mgmt/api/build-mgmt/...
task-management-plugin/task/
webhook-gateway/webhooks/webhooks/... (path preserved)

​
Public routes

ServiceExternal pathBackend receives
cms-core/cms/
designer//
document-plugin/document/
events-gateway/api/events/api/events/... (path preserved)
organization-manager/org/
process-engine/onboarding/api/api/...
runtime-manager/rtm/api/runtime/api/runtime/...
task-management-plugin/task/
The Designer also gets a wildcard host rule (*.<public-host>) for workspace-per-subdomain access; this is set up by FlowX and does not require additional configuration on your side.

​
Admin-instances routes

A third group on the admin host carries runtime process and instance APIs:
ServiceExternal pathBackend receives
process-engine/api/instances/api/instances/... (path preserved)
runtime-manager/rtm/api/runtime, /rtm/api/runtime-internal/api/runtime/..., /api/runtime-internal/...

​
Internal-only services

The following services are not exposed externally and have no ingress or HTTPRoute rendered: advancing-controller, data-search, email-gateway, nosql-db-runner, scheduler-core.

​
CORS configuration

CORS is handled inside each backend service rather than at the ingress layer. Only the allowed-origins list is deployment-specific; allowed methods, allowed headers (including Authorization, Content-Type, Fx-Workspace-Id), and credential handling are baked into each service’s application.yaml with safe defaults.

​
APPLICATION_CORS_ALLOW_ORIGIN

Set this environment variable on every backend service exposed via admin or public URLs: 
env:
  APPLICATION_CORS_ALLOW_ORIGIN: "https://designer.yourcompany.com,https://*.yourcompany.com"
Wildcard subdomain patterns are supported. The variable must be set on each of the 15 backend services listed in Service route reference; designer and other frontend-only services do not need it. The per-service rows are listed in the v5.9.0 deployment guidelines.

​
Removed NGINX annotations

The following NGINX-specific annotations are no longer rendered on the default ingress templates and have no effect on 5.9.x:
  • nginx.ingress.kubernetes.io/enable-cors
  • nginx.ingress.kubernetes.io/cors-allow-credentials
  • nginx.ingress.kubernetes.io/cors-allow-headers
  • nginx.ingress.kubernetes.io/cors-allow-methods
  • nginx.ingress.kubernetes.io/cors-allow-origin
Any leftover overrides referencing these should be removed during the upgrade.

​
Customizing routes

Per-service annotations (proxy body size, timeouts, TLS, affinity, cert-manager wiring) are applied to the rendered Ingress through your deployment’s chart values. Common customizations and how they map between Ingress mode and HTTPRoute mode:
CustomizationIngress mode (annotation)HTTPRoute mode
Proxy body size (uploads)nginx.ingress.kubernetes.io/proxy-body-size: "50m" (annotation-driven)Controller-specific policy CRD (Envoy Gateway BackendTrafficPolicy, Istio EnvoyFilter, Traefik Middleware)
Request timeoutsnginx.ingress.kubernetes.io/proxy-read-timeout, proxy-connect-timeoutspec.rules[].timeouts.request on the HTTPRoute
URL rewritenginx.ingress.kubernetes.io/rewrite-targetURLRewrite filter on the HTTPRoute
Session affinitynginx.ingress.kubernetes.io/affinity: "cookie"Controller-specific (Gateway API sessionPersistence field, v1.1+)
TLS certificate managementcert-manager.io/cluster-issuerSame — cert-manager annotations are not NGINX-specific
Share your existing customizations with your FlowX representative during the upgrade window so they can be carried forward.

​
Default proxy body size

Three services ship with a default proxy-body-size: 50m annotation to support larger uploads:
  • application-manager — admin route (application manifests)
  • document-plugin — admin and public routes (document uploads)
  • runtime-manager — admin route (application-version manifests)
If you need a higher limit, coordinate the override with your FlowX representative.

​
Ingress controller

Kubernetes Ingress resources work with any compliant controller (Traefik, HAProxy, Istio, F5 Container Ingress Services, cloud-provider controllers). Confirm the deployment’s ingressClassName matches the controller actually running on your cluster with your FlowX representative.

​
Troubleshooting

​
CORS errors in the browser

The browser console shows Access-Control-Allow-Origin errors but the request reaches the backend successfully.
  1. Confirm the origin is listed in APPLICATION_CORS_ALLOW_ORIGIN on the affected service (deployment guidelines table lists the variable per service).
  2. Check the value is a comma-separated string of full origins, including the scheme (https://).
  3. Restart the service after changing the env var — Spring reads it at startup.

​
413 Request Entity Too Large

A file upload or large request body fails with HTTP 413.
  1. The default proxy-body-size: 50m applies to the three upload-heavy routes (application-manager, document-plugin, runtime-manager admin). Raise the value with your FlowX representative if you need higher.
  2. If you front the FlowX cluster with an external reverse proxy (F5, corporate gateway, cloud LB), check the body size limit at that layer too.

​
404 / path routing issues

A request returns 404 even though the service is healthy.
  1. Cross-check the external path against Service route reference — the path your client sends must match the table.
  2. Confirm the deployment’s ingressClassName (Ingress mode) or attached Gateway (HTTPRoute mode) matches the controller actually running in the cluster.

Migrating ingress from 5.1.x

NGINX controller change, CORS env var, and the upgrade-window action checklist.

v5.9.0 deployment guidelines

Component versions, Kafka topics, and the APPLICATION_CORS_ALLOW_ORIGIN row per service.

Gateway API documentation

Upstream documentation for HTTPRoute, GatewayClass, and Gateway resources.

Setup guides

Per-service configuration including each service’s own routing and CORS section.
Last modified on June 2, 2026