> ## 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. # Routing > How FlowX services are exposed externally on 5.9.x, the per-service route table, and CORS handling at the application layer. 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](/5.9/migrating-from-5.1-lts/ingress-routing). *** ## 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 | Service | External path | Backend 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 | Service | External path | Backend 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 (`*.`) 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: | Service | External path | Backend 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: ```yaml theme={"system"} 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](#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](/release-notes/v5.x/v5.9.0-june-2026/deployment-guidelines-v5.9#cors-handling--application-cors-allow-origin-new-in-5-9-0). ### 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: | Customization | Ingress 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 timeouts | `nginx.ingress.kubernetes.io/proxy-read-timeout`, `proxy-connect-timeout` | `spec.rules[].timeouts.request` on the HTTPRoute | | URL rewrite | `nginx.ingress.kubernetes.io/rewrite-target` | `URLRewrite` filter on the HTTPRoute | | Session affinity | `nginx.ingress.kubernetes.io/affinity: "cookie"` | Controller-specific (Gateway API `sessionPersistence` field, v1.1+) | | TLS certificate management | `cert-manager.io/cluster-issuer` | Same — 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](#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. *** ## Related resources NGINX controller change, CORS env var, and the upgrade-window action checklist. Component versions, Kafka topics, and the `APPLICATION_CORS_ALLOW_ORIGIN` row per service. Upstream documentation for HTTPRoute, GatewayClass, and Gateway resources. Per-service configuration including each service's own routing and CORS section.