FlowX.AI 6.0.0 is a feature release. Self-hosted deployments usually follow LTS releases. Use this guide if you upgrade a self-hosted installation to 6.0.0.
Who is affected
Teams that run a container app with a FlowX renderer SDK (Angular, React, iOS, Android, or React Native) and move it to FlowX.AI 6.0.0. See Renderer SDK migration. Teams that run FlowX.AI on theflowx-ai Helm chart and upgrade it from 5.9.x to 6.0.0. See Helm chart upgrade.
Teams with business rules, reusable functions, or workflow scripts that still run on the GraalVM script engine. See Move scripts off the GraalVM engine.
What’s changing
An upgrade to 6.0.0 touches up to three areas, depending on what you run:- Helm chart: set every AI service group flag explicitly, and create databases and secrets for the new services that need them. See Helm chart upgrade.
- GraalVM script engine: deprecated. Scripts on GraalVM keep running after this upgrade, now with the same time limit as the native engine, and 6.1.x is the last release family that supports the engine. See Move scripts off the GraalVM engine.
- Renderer SDKs: container apps upgrade the FlowX renderer SDK, and the host framework where the SDK needs it. See Renderer SDK migration.
Migration process
Follow these steps in order, and skip the ones for areas you don’t run.1
Check your starting point
Upgrade to 6.0.0 from FlowX.AI 5.9.x on the
flowx-ai Helm chart. If you still run the per-service charts or the ai-platform umbrella chart, first migrate to the flowx-ai Helm chart on 5.9.x, as a separate change.2
Read the release notes and deployment guidelines
The release notes list what changes in 6.0.0. The deployment guidelines list the component versions, environment variables, and other configuration changes. The 5.9.x to 6.0.0 changelog lists every feature change since 5.9.x, including the 5.10 to 5.13 feature releases.
3
Prepare the infrastructure
Create what the 6.0.0 services need before the upgrade window: new PostgreSQL and MongoDB database users and their secrets, four new keys in the
keycloak-flowx-realm-clients secret, read access for process-engine to the integration-designer bucket, and storage for a 20Gi ReadWriteOnce volume if you turn on dynamic-classifier. Create the new Kafka topics, or list them for the chart to create. From 5.9.x, also set the personal-data encryption key that integration-designer needs since 5.12, and choose how Elasticsearch replicates new indices since 5.13. Update your values walks through each item, and New databases and secrets lists the names.4
Back up
Take the backups listed in Before you begin right before the upgrade.
5
Upgrade the Helm release
Update your values and upgrade the release, as described in Helm chart.
6
Upgrade your container apps
For each container app, upgrade the host framework first if the SDK needs it, then the FlowX renderer SDK. See Renderer SDK migration. Container apps on a 5.9.x renderer SDK keep running against a 6.0.0 backend, but screens can render incorrectly wherever 6.0.0 changed behavior. Release the upgraded apps in the same window as the Helm upgrade. For iOS and Android apps, end users who don’t install the app update stay on the 5.9.x SDK, so plan how you move them to the new version.
7
Check GraalVM scripts and plan the move off GraalVM
Scripts on GraalVM keep running, but from 6.0.0 they stop at the same time limit as the native engine. Before the upgrade, check the scripts that can run longer than the limit, or raise it. Then plan their move to the native engine, as described in Move scripts off the GraalVM engine.
Helm chart upgrade
Migrate to the flowx-ai Helm chart
Move from the per-service or ai-platform charts to the single
flowx-ai chartHelm chart
Upgrade an installation on the
flowx-ai Helm chart from 5.9.x to 6.0.0Move scripts off the GraalVM engine
The GraalVM script engine is deprecated. FlowX.AI 6.1.x is the last release family that supports GraalVM as a script engine for JavaScript and Python. Scripts that run on GraalVM keep running after the upgrade to 6.0.0, but they now stop at the same time limit as the native engine: 5,000 ms for JavaScript and 10,000 ms for Python by default. Before 6.0.0, a GraalVM script had no time limit. Before you upgrade, check the GraalVM scripts that can run longer than these limits, or raise the limits, as described in Script size and execution limits. Then plan the move to the native engine.1
Find the scripts that run on GraalVM
Business rules and reusable functions created before the move to the native engine run on GraalVM unless you switched them. The engine selector in each rule’s script editor shows the engine it runs on. Workflow scripts run on GraalVM only if
APPLICATION_SCRIPTENGINE_PROVIDER=graalvm is set on integration-designer.2
Test each script on the native engine
The two engines don’t always write the same output. Check the common pitfalls, and search scripts for Python imports the native engine blocks, such as
os and subprocess, JavaScript require(...), process, or global, and calls into Java classes such as Java.type(...). The native engine supports none of these.3
Switch to the native engine
Switch business rules per rule. Move a reusable function and the rules that call it together: a function written for GraalVM fails when a rule on the native engine calls it. For workflow scripts, remove
APPLICATION_SCRIPTENGINE_PROVIDER=graalvm from integration-designer. The default is native.Renderer SDK migration
Angular SDK
Migrate the Angular renderer SDK to 6.0.0
React SDK
Migrate the React renderer SDK to 6.0.0
iOS SDK
Migrate the iOS renderer SDK to 6.0.0
Android SDK
Migrate the Android renderer SDK to 6.0.0
React Native SDK
Migrate the React Native renderer SDK to 6.0.0