Deployment guidelines v5.9.6

​

Upgrade overview

FlowX.AI 5.9.6 is a maintenance release for the 5.9.x LTS line. The upgrade from 5.9.5 adds one Kafka topic, a database table, and a MongoDB index. The table and the index are created automatically when the services start. Review Kafka topics, Configuration changes, and the 5.9.6 upgrade notes before you deploy.

​

Component versions

​

Core components

* The reporting plugin is an optional add-on and is versioned independently of the platform, so its numbering does not follow the other components. It moved from the 0.2.x scheme to 10.x after 5.9.0. Pin the version listed for your release.

​

Embedded components

• SpiceDB: see the 5.9.0 deployment guidelines for details.
• Qdrant (vector database): bundled in the flowx-ai Helm chart; its version is managed by the chart and not pinned here. See the Qdrant setup guide for deployment and configuration.

​

Renderers

​

AI components

FlowX.AI groups AI services into four tiers by deployment role. AI Base components are the foundation; AI Runtime and AI Dev Time components both require Base to be installed first; AI Extensions are optional add-ons layered on top.

​

AI Base components

​

AI Runtime components

​

AI Dev Time components

​

AI Extensions

​

Kafka topics

5.9.6 adds one Kafka topic. If your cluster does not create topics automatically, create it before you deploy, and allow both services in your ACLs. The topic is included in the FlowX Kafka topics chart from version 10.2.0. For the full multi-release topic matrix, see the 5.9.0 deployment guidelines.

​

Deployment notes

​

Standard deployment

This maintenance release follows standard FlowX.AI deployment procedures:

1. Create the ai.flowx.build.deployment-failed.v1 Kafka topic if your cluster does not create topics automatically. See Kafka topics.
2. Review Configuration changes. No values change is required for a standard upgrade.
3. The ai-platform umbrella Helm chart has been superseded by the flowx-ai chart. If you installed the ai-platform chart, contact FlowX support before you upgrade to 5.9.6. See the 5.9.6 upgrade notes.
4. Update container images to the 5.9.6 versions listed in the tables above.
5. Deploy services using your standard deployment process.
6. Verify deployment via FlowX.AI Designer → Platform Status.

​

Configuration changes

​

Build redeployment retries

When a build deployment fails, application-manager queues it for a retry. The queue is now stored in the application-manager database, in the new failed_deployment table, instead of in Redis. The table is created automatically on startup. runtime-manager reports each failure on the ai.flowx.build.deployment-failed.v1 topic, and application-manager consumes it. New application-manager variables (the defaults fit a standard deployment):

​

MongoDB setting names

Services that use MongoDB now read their connection settings from new names. The previous SPRING_DATA_MONGODB_* variables still feed the new settings, so existing deployments need no change. Use the new names in new configuration. SPRING_DATA_MONGODB_RUNTIME_AUTOINDEXCREATION no longer has any effect: indexes on the runtime database are never created automatically.

​

Document parser models

The document parser image now contains its layout, table, and OCR models, so the parser downloads nothing at startup or on the first parse. It runs without internet access and on a read-only filesystem. USE_DOCLING no longer has any effect on the document parser and can be removed from its configuration.

​

Integration Designer: document download timeout

A REST node JSON body can include "@@base64File(<path>)" to send a Document Plugin file as base64. Downloading the file from the Document Plugin is cancelled after this timeout. See Content Type: JSON. New integration-designer variable:

​

Third-party supported component versions

Within each version line listed below, versions that have reached upstream end of life are not supported, even though their major/minor is listed. (*) Required only if using indexing via Kafka. Multiple sink connector implementations also work, as long as they are compatible with both the deployed Kafka and Elasticsearch version.