Deployment guidelines v6.0.0

​

Upgrade overview

FlowX.AI 6.0 is a feature release. On SaaS, FlowX applies every change on this page. Self-hosted deployments usually follow LTS releases and receive these changes with the next LTS release family. If you upgrade a self-hosted installation to 6.0.0, apply the changes below in the order given in Migrating from v5.9.x to v6.0.0.

​

Before you upgrade a self-hosted installation

• Set every AI service group flag explicitly. See AI service groups in the Helm chart.
• Create the new database users and secrets, including the four new keys in keycloak-flowx-realm-clients. See New databases and secrets.
• Give process-engine read access to the integration-designer bucket. See New databases and secrets.
• Create the new Kafka topics, including the ones added in 5.10 to 5.13. See New Kafka topics.
• Set FLOWX_PII_ENCRYPTION_MASTER_KEY on integration-designer, required since 5.12. See personal-data encryption master key.
• Choose how Elasticsearch replicates new indices, changed in 5.13. See Elasticsearch replica auto-expansion.
• Add the MongoDB hosts on your private network that data sources use to FLOWX_SSRFALLOWEDHOSTS. See nosql-db-runner host restrictions.
• Trust the certificates of the IMAP servers your email triggers read from. See IMAPS certificate verification.
• Keep the advancing-controller management port, 8081, off any public ingress. See Removed environment variables.

Upgrading from 5.9.5 or earlier? After the upgrade, re-publish builds that were waiting for a deployment retry. See Failed deployments retry from PostgreSQL.

​

Component versions

The versions below are the component versions that make up FlowX.AI 6.0.0. On SaaS, FlowX manages these versions.

​

Core components

​

AI base components

​

AI dev-time components

​

AI runtime components

​

AI extensions

In FlowX.AI 6.0, the Observatory components run on environments operated by FlowX. They aren’t included in client deployments in this release.

​

Embedded components

• SpiceDB: see the 5.9.0 deployment guidelines for details.
• Qdrant (vector database): bundled in the flowx-ai Helm chart and deployed with the AI base group (see AI service groups in the Helm chart). Its version is managed by the chart and not pinned here. See the Qdrant setup guide for deployment and configuration.

​

Renderers

The web SDKs ship at the designer version (11.251.0 for FlowX.AI 6.0.0). The native iOS and Android renderers version independently. The solution-portal container app tracks the designer version.

---

​

Configuration changes

This section compares environment variables and Kafka topics with FlowX.AI 5.13, and Helm chart changes with the flowx-ai chart in 5.9.6. Upgrading a self-hosted installation from 5.9.x? The configuration changes in the 5.10, 5.11, 5.12, and 5.13 deployment guidelines also reach you with this upgrade, although those pages describe them for SaaS. The ones you act on are in Before you upgrade a self-hosted installation: the Kafka topics, the personal-data encryption key, and Elasticsearch replica auto-expansion.

​

New Kafka topics

These topics back new 6.0 capabilities. On SaaS they are created and managed automatically. AI nodes as durable jobs: Validation findings: Failed deployments retried: Workflow schedules: Last-used workspace:

​

New services

The ui-driver service replaces ai-render-host in the AI dev-time group. It renders UI flows in the background for the Developer Agentic Harness and adds no new dependencies. On SaaS it is provisioned and managed by FlowX.

​

AI service groups in the Helm chart

The flowx-ai Helm chart groups the services into four groups: The groups are the same as in 5.9.6. The 6.0.0 chart adds designer-user to core, harness and ui-driver to devtime, and cee-pii and dynamic-classifier to runtime. The base group is unchanged. Set all four flags in your values, using one of these combinations:

​

New databases and secrets

Compared with the flowx-ai Helm chart in 5.9.6, these services need new databases: Each database has the same name as its user. Each secret holds the user’s password under the key password. The webhook-gateway also connects to the existing app-runtime MongoDB database with the app-runtime user. The keycloak-flowx-realm-clients secret needs four new keys, one for each new service account: Other chart changes:

• process-engine needs read-only access (s3:GetObject) to the integration-designer bucket, to download the Kafka payloads that integration-designer stores there. The chart reads the access key ID from global.flowx.s3.credentials.processEngine.accessKey (default flowx-process-engine-accesskey) and the secret access key from the flowx-process-engine-s3 secret, key SecretAccessKey.
• dynamic-classifier stores its data on a 20Gi ReadWriteOnce persistent volume claim, dynamic-classifier-data, and uses the Recreate deployment strategy, so an upgrade stops the old pod before the new one starts.
• dynamic-classifier reads an OpenAI API key for its LLM judge from the dynamic-classifier-openai secret, key OPENAI_API_KEY. The secret is optional: without it, the pod still starts and classification keeps working.
• The chart no longer creates an admin Ingress for doc-converter, data-privacy, speech-to-text, web-crawler, and dynamic-classifier. ai-gateway keeps its own.

​

New service dependency: harness and Redis

The harness now uses Redis to stream a running turn to every open Designer session and to cancel a turn from any harness pod. It reuses the platform’s existing Redis, so nothing new is provisioned. Without Redis, turns still run, but live progress and cancellation across pods don’t work. On SaaS this connection is managed by FlowX.

​

New service dependency: harness and Kafka

The harness now connects to Kafka and consumes the existing ai.flowx.llm.config.changed.v1 topic, so a change to an organization’s AI model settings reaches it right away. Without Kafka it picks up the change when its cache expires. No new topic is needed.

​

Changed behavior: failed deployments retry from PostgreSQL

The queue of build deployments waiting for a retry moves from Redis to the application-manager PostgreSQL database, so a Redis flush no longer drops it. Runtime-manager reports a failed deployment on ai.flowx.build.deployment-failed.v1 and application-manager stores and retries it. Self-hosted 5.9.6 already includes this change and the topic.

​

Changed behavior: nosql-db-runner host restrictions cover MongoDB

The host restriction that relational data sources already had now applies to external MongoDB connections too. The nosql-db-runner checks every address a MongoDB host resolves to, including replica-set members and SRV targets, and rejects the connection if any of them is private. For FlowX Database and Unmanaged MongoDB data sources alike, it also rejects UPDATE, UPDATE_MANY, DELETE, and DELETE_MANY operations with a missing or empty filter. To match every document, pass {"_id": {"$exists": true}}.

​

Changed behavior: name placeholders in data-privacy

When data-privacy masks a person’s name, the placeholder now carries the gender, for example <NAME_F_1> or <NAME_M_1>. When the name doesn’t show the gender, the placeholder stays <NAME_1>. Prompts or scripts that match the old placeholder form need updating.

​

Changed behavior: Workspace operations editor role replaced

The upgrade replaces the Workspace operations editor role with the Workspace corrective actions editor role. Users and groups that had the old role get the new one automatically and keep access to process instance migration and move token. No action is needed.

​

New environment variables: audit index retention

The Audit service can now delete old audit data and roll over by shard size. Both settings are off by default, so the Audit service doesn’t delete data unless you set a retention period.

​

Removed environment variables

​

Changed default: IMAPS certificate verification in email-gateway

The email-gateway now verifies the certificate of every IMAPS server it connects to. A server must present a certificate signed by a trusted authority and matching its host name.

​

Changed default: AI node retry

AI nodes without retry settings of their own now retry when a dependency is temporarily unavailable, such as an LLM provider outage, a rate limit, or a lost connection. Permanent errors aren’t retried, and deep research nodes never retry by default. A node’s own retry settings replace the default.