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.

5.1.x deployments route external traffic through Kubernetes Ingress resources rendered by the FlowX Helm chart, with NGINX as the assumed ingress controller. CORS is handled at the ingress layer through nginx.ingress.kubernetes.io/cors-* annotations on every per-service Ingress. 5.9.x changes both: the chart no longer assumes ingress-nginx as the bundled controller, and CORS handling moves to the application layer via an environment variable on each backend service. The chart on 5.9.x ships Kubernetes Ingress and Gateway API HTTPRoute templates side-by-side; each service can be toggled independently between the two modes. The Service Route Reference and full configuration are documented in the ingress configuration guide.
This migration is operated by FlowX during the 5.1.x → 5.9.x upgrade window for self-hosted deployments. The customer-facing actions are limited to verifying CORS origins and confirming the post-upgrade ingress controller choice with your FlowX representative.

​
CORS handling moves into the services

On 5.9.x, CORS is handled inside each backend service’s code rather than at the ingress layer. Each service’s application.yaml ships with sensible defaults for allowed methods, headers, and credentials. Only the allowed origins list is deployment-specific and must be configured per environment. The change applies to every backend service that is exposed through an admin or public URL: admin, application-manager, audit-core, authorization-system, cms-core, document-plugin, events-gateway, integration-designer, license, notification-plugin, organization-manager, process-engine, runtime-manager, task-management-plugin, webhook-gateway. Internal-only services do not serve browser traffic and are unaffected.

​
Set APPLICATION_CORS_ALLOW_ORIGIN per deployment

APPLICATION_CORS_ALLOW_ORIGIN accepts a comma-separated list of origins: 
env:
  APPLICATION_CORS_ALLOW_ORIGIN: "https://designer.yourcompany.com,https://*.yourcompany.com"
Wildcard subdomain patterns are supported. The list must include every domain that your Designer, runtime renderers, and custom integrations are served from. The variable must be set on each of the 15 services listed above.
Origins that are not listed in APPLICATION_CORS_ALLOW_ORIGIN will be rejected at the service layer with a CORS error in the browser, even if the request reaches the backend successfully. CORS failures surface only in the browser console. Backend logs show the request as successful.

​
Other CORS settings use safe defaults

Allowed methods, allowed headers (including Authorization, Content-Type, Fx-Workspace-Id, and the other FlowX-specific headers used by the platform), and credential handling are baked into each service’s application.yaml with the correct values. The defaults are overridable via environment variables but rarely need to change; consult your FlowX representative if you have a non-standard requirement.

​
What is removed

The following NGINX-specific annotations are no longer rendered on the chart’s ingress templates and are no longer effective for CORS handling:
  • 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
Custom overrides that referenced these annotations should be removed during the upgrade. They have no effect on 5.9.x.

​
NGINX ingress controller is no longer assumed

The chart no longer assumes ingress-nginx as the bundled controller in 5.9.x. Kubernetes Ingress resources themselves remain fully supported with any compliant controller (Traefik, HAProxy, Istio, F5 Container Ingress Services, cloud-provider controllers, etc.). The change applies to the bundled controller the chart historically assumed. Not to Kubernetes Ingress as a routing mechanism. Deployments that already terminate ingress on a non-NGINX controller are unaffected; only the CORS env var change above applies.

​
What this means for your deployment

Current 5.1.x setup5.9.x action
ingress-nginx controller deployed alongside FlowXPlan the controller change with your FlowX representative — another Kubernetes Ingress controller, or opt in to Gateway API HTTPRoutes (see below).
Existing non-NGINX ingress controller (Traefik, HAProxy, F5, etc.)No controller change required. Confirm the chart’s ingressClassName is set to your controller.
External reverse proxy in front of Kubernetes (F5, corporate API gateway)No controller change required. The chart’s Ingress resources continue to apply behind your proxy.

​
Optional: Gateway API HTTPRoutes

5.9.x ships Gateway API HTTPRoute templates alongside the existing Ingress templates, as an opt-in alternative for customers who want a controller-agnostic routing model. Kubernetes Ingress remains the default for every service; switching 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 (Envoy Gateway, Istio, Traefik with Gateway API enabled, etc.) on the cluster. For details, see the routing guide.
HTTPRoute adoption is not required at the 5.1.x → 5.9.x upgrade window. Customers staying on Kubernetes Ingress for the 5.9.x release cycle will continue to be supported on the chart’s Ingress templates.

​
Customizing routes

If your 5.1.x deployment carries custom NGINX annotations (body-size tuning, timeouts, sticky sessions, custom rewrites, cert-manager, WAF), share the full set with your FlowX representative before the upgrade window so they can be carried forward. See Routing → Customizing routes for the Ingress ↔ HTTPRoute mapping of common annotations.

​
Pre-upgrade audit checklist

Before the upgrade window, walk through the following with your FlowX representative:
1

Inventory CORS origins

List every domain that calls FlowX REST APIs from the browser. Include Designer URLs, custom domains, runtime renderer domains, third-party integration hosts, and any local-development origins that need to remain authorized in production.
2

Confirm ingress controller

Confirm which Kubernetes ingress controller your deployment currently uses. If you are on ingress-nginx, decide with FlowX whether to migrate to another controller, adopt Gateway API HTTPRoutes, or stay on ingress-nginx for the 5.9.x cycle.
3

Share custom annotations

If your 5.1.x deployment carries custom annotations on FlowX Ingress resources (body size, timeouts, affinity, custom rewrite, cert-manager, WAF), share the full set with FlowX. They will be carried forward via the chart values.
4

Verify upstream proxy settings

If you have an external reverse proxy in front of Kubernetes (F5, corporate gateway, cloud LB), confirm that origin-rewriting or header-stripping at that layer does not interfere with the new application-level CORS handling.
5

Plan post-upgrade verification

After the upgrade, validate one request from each origin in APPLICATION_CORS_ALLOW_ORIGIN against each affected service. CORS failures surface only in the browser. Backend logs show successful requests.

Ingress configuration guide

Service Route Reference, Gateway API HTTPRoute configuration, and route customization for the 5.9.x baseline.

v5.9.0 deployment guidelines

Component versions, APPLICATION_CORS_ALLOW_ORIGIN environment variable per service, and self-hosted upgrade guidance.

Prerequisites

Complete the pre-upgrade inventory before working through this page.

Migration overview

Return to the consolidated 5.1 LTS → 5.9 LTS migration guide.
Last modified on June 2, 2026