There are two types of Config Params that can be read from the environment: variables and secrets. There is one provider for variables and secrets extracted from the environment variables, and two providers for the ones extracted from Kubernetes. By default, the variables and secrets are extracted from environment variables (env provider).
Configuration parameters from environment variables (default)
The env provider used for variables and secrets extracts them from environment variables. For security reasons, the env provider uses an allow list regex which defaults to FLOWX_CONFIGPARAM_.*. This means only environment variables that match this naming pattern can be read at runtime into configuration params (either as variables or secrets). Feel free to edit it to match the environment variables that you use in your deployment.
Environment variable
Description
Default value
FLOWX_CONFIGPARAMS_VARS_PROVIDER
Provider type for variables
env
FLOWX_CONFIGPARAMS_VARS_ALLOWLISTREGEX
Regular expression to match allowed env variables for variables
FLOWX_CONFIGPARAM_.*
FLOWX_CONFIGPARAMS_SECRETS_PROVIDER
Provider type for secrets
env
FLOWX_CONFIGPARAMS_SECRETS_ALLOWLISTREGEX
Regular expression to match allowed env variables for secrets
You can configure multiple secrets and ConfigMaps by incrementing the index number (e.g., FLOWX_CONFIGPARAMS_PROVIDERS_K8SSECRETS_SECRETSLIST_1, FLOWX_CONFIGPARAMS_PROVIDERS_K8SCONFIGMAPS_CONFIGMAPSLIST_1). Values are overridden based on the order in which the maps are defined.The default provider is env, but there is a built-in allowlist with the regex pattern FLOWX_CONFIGPARAM_.*. This means only configuration parameters that match this naming pattern can be read at runtime, whether they are environment variables or secret variables.
Configure caching behavior for configuration parameters to optimize performance:
Environment variable
Description
Default value
FLOWX_CACHE_CONFIGPARAMS_TTLSECONDS
Time-to-live in seconds for cached configuration params
120
FLOWX_CACHE_CONFIGPARAMS_MAXENTRIES
Maximum number of entries in the config params cache
500
These settings control how long configuration parameters are cached in memory before being refreshed from the source (environment variables, ConfigMaps, or Secrets). Adjust these values based on how frequently your configuration changes and your memory constraints.
Kafka handles all communication between the FlowX.AI Engine, external plugins, and integrations. It also notifies running process instances when certain events occur.
Default context value for message routing when no context is provided
"" (empty string)
When KAFKA_DEFAULT_FX_CONTEXT is set and an event is received on Kafka without an fxContext header, the system will automatically apply the default context value to the message.
Both a producer and a consumer must be configured:
Configuring a Kafka Producer
Configuring a Kafka Consumer
About consumer groups and threads
A consumer group is a set of consumers that jointly consume messages from one or more Kafka topics. Each consumer group has a unique identifier (group ID) that Kafka uses to manage message distribution.Thread numbers refer to the number of threads a consumer application uses to process messages. Increasing thread count can improve parallelism and efficiency, especially with high message volumes.
Consumer group configuration
Environment variable
Description
Default value
KAFKA_CONSUMER_GROUPID_NOTIFYADVANCE
Group ID for notifying advance actions
advance
KAFKA_CONSUMER_GROUPID_NOTIFYPARENT
Group ID for notifying when a subprocess is blocked
notify-parent
KAFKA_CONSUMER_GROUPID_ADAPTERS
Group ID for messages related to adapters
adapters
KAFKA_CONSUMER_GROUPID_SCHEDULERRUNACTION
Group ID for running scheduled actions
scheduler-run-action
KAFKA_CONSUMER_GROUPID_SCHEDULERADVANCING
Group ID for messages indicating continuing advancement
scheduler-advancing
KAFKA_CONSUMER_GROUPID_MESSAGEEVENTS
Group ID for message events
message-events
KAFKA_CONSUMER_GROUPID_PROCESS_START
Group ID for starting processes
process-start
KAFKA_CONSUMER_GROUPID_PROCESS_STARTFOREVENT
Group ID for starting processes for an event
process-start-for-event
KAFKA_CONSUMER_GROUPID_PROCESS_EXPIRE
Group ID for expiring processes
process-expire
KAFKA_CONSUMER_GROUPID_PROCESS_OPERATIONS
Group ID for processing operations from Task Management plugin
process-operations
KAFKA_CONSUMER_GROUPID_PROCESS_BATCHPROCESSING
Group ID for processing bulk operations from Task Management plugin
process-batch-processing
KAFKA_CONSUMER_GROUPID_PROCESS_UIFLOWUPDATE
Group ID for processing UI flow session variable updates
ui-flow-update
Consumer thread configuration
Environment variable
Description
Default value
KAFKA_CONSUMER_THREADS_NOTIFYADVANCE
Number of threads for notifying advance actions
6
KAFKA_CONSUMER_THREADS_NOTIFYPARENT
Number of threads for notifying when a subprocess is blocked
6
KAFKA_CONSUMER_THREADS_ADAPTERS
Number of threads for processing messages related to adapters
6
KAFKA_CONSUMER_THREADS_SCHEDULERADVANCING
Number of threads for continuing advancement
6
KAFKA_CONSUMER_THREADS_SCHEDULERRUNACTION
Number of threads for running scheduled actions
6
KAFKA_CONSUMER_THREADS_MESSAGEEVENTS
Number of threads for message events
6
KAFKA_CONSUMER_THREADS_PROCESS_START
Number of threads for starting processes
6
KAFKA_CONSUMER_THREADS_PROCESS_STARTFOREVENT
Number of threads for starting processes for an event
2
KAFKA_CONSUMER_THREADS_PROCESS_EXPIRE
Number of threads for expiring processes
6
KAFKA_CONSUMER_THREADS_PROCESS_OPERATIONS
Number of threads for processing operations from task management
6
KAFKA_CONSUMER_THREADS_PROCESS_BATCHPROCESSING
Number of threads for processing bulk operations from task management
6
KAFKA_CONSUMER_THREADS_PROCESS_UIFLOWUPDATE
Number of threads for processing UI flow session variable updates
6
All events that start with a configured pattern will be consumed by the Engine. This enables you to create new integrations and connect them to the engine without changing the configuration.
The KAFKA_NOTIFICATION_OUT topic must resolve to the same value as KAFKA_TOPIC_NOTIFICATION_INTERNAL_IN in the Notification plugin configuration.
Topics related to the Document plugin
The process-engine receives results from document-plugin operations on topics matching the pattern ai.flowx.engine.receive.plugin.document.*. The following topics are used for file encryption and decryption operations:
Topic for receiving file decryption results from document-plugin
These topics are automatically matched by the Engine’s KAFKA_TOPIC_PATTERN configuration (default: ai.flowx.engine.receive.*). No additional configuration is required. The topics must be created in your Kafka infrastructure before deployment.
Task manager operations include: assignment, unassignment, hold, unhold, terminate. These are matched with the ...operations.out topic on the engine side. For more information, see the Task Management plugin documentation:📄 Task management plugin
Topics related to UI flow session updates
Environment variable
Description
Default value
KAFKA_TOPIC_UIFLOW_UPDATE_IN
Topic for receiving UI flow session variable updates
ai.flowx.core.trigger.ui-flow.update.v1
Topics related to the scheduler extension
Environment variable
Description
Default value
KAFKA_TOPIC_PROCESS_EXPIRE_IN
Topic for requests to expire processes
ai.flowx.core.trigger.expire.process.v1
KAFKA_TOPIC_PROCESS_SCHEDULE_OUT_SET
Topic used for scheduling process expiration
ai.flowx.core.trigger.set.schedule.v1
KAFKA_TOPIC_PROCESS_SCHEDULE_OUT_STOP
Topic used for stopping process expiration
ai.flowx.core.trigger.stop.schedule.v1
KAFKA_TOPIC_PROCESS_SCHEDULE_IN_RUN_ACTION
Topic for requests to run scheduled actions
ai.flowx.core.trigger.run.action.v1
KAFKA_TOPIC_PROCESS_SCHEDULE_IN_ADVANCE
Topic for events related to advancing through a database
When configuring FlowX services, ensure the following:
The Engine’s pattern must match the pattern used by services sending messages to the Engine
The integrationPattern must match the pattern used by the Integration Designer
Output topics from one service must match the expected input topics of another service
For example:
Services send to topics matching ai.flowx.engine.receive.* → Engine listens
Engine sends to topics matching ai.flowx.integration.receive.* → Integration Designer listens
Kafka message size configuration
Environment variable
Description
Default value
KAFKA_MESSAGE_MAX_BYTES
Maximum message size in bytes
52428800 (50MB)
This setting affects:
Producer message max bytes
Producer max request size
Consumer max partition fetch bytes
Kafka authentication (when using SASL_PLAINTEXT)
For secure environments, enable OAuth authentication with the following environment variables:
Environment Variable
Description
Default Value
KAFKA_OAUTH_CLIENT_ID
OAuth client ID
kafka
KAFKA_OAUTH_CLIENT_SECRET
OAuth client secret
kafka-secret
KAFKA_OAUTH_TOKEN_ENDPOINT_URI
OAuth token endpoint
kafka.auth.localhost
When using the kafka-auth profile, the security protocol will automatically be set to SASL_PLAINTEXT and the SASL mechanism will be set to OAUTHBEARER.
The Process Engine uses Elasticsearch for process instance indexing and search capabilities. Configure the connection using these environment variables:
To use the advancing controller, configure the following variables:
Environment variable
Description
Default value
ADVANCING_DATASOURCE_URL
Connection URL for Advancing Postgres DB
jdbc:postgresql://postgresql:5432/advancing
ADVANCING_DATASOURCE_USERNAME
Username for Advancing DB connection
flowx
ADVANCING_DATASOURCE_PASSWORD
Password for Advancing DB connection
-
ADVANCING_DATASOURCE_MAXIMUMPOOLSIZE
Maximum size of the advancing datasource connection pool. Worker threads open their own connections, configured separately via ADVANCING_PICKINGTHREADS and ADVANCING_PROCESSINGTHREADS
Number of worker threads for reading from database (picking operations)
1
ADVANCING_PROCESSINGTHREADS
Number of threads for parallel processing of advancing events
20
ADVANCING_PROCESSINGBUFFERSIZE
Maximum buffer size for processing queue. Controls how many events can be queued
20
ADVANCING_BLOCKPICKINGIFNOWORKERAVAILABLE
Block picking operations when no worker threads are available
true
ADVANCING_PICKINGPAUSEMILLIS
Pause duration between picking batches (ms)
50
ADVANCING_COOLDOWNAFTERSECONDS
Cooldown period after processing a batch (seconds)
120
ADVANCING_SCHEDULER_HEARTBEAT_CRONEXPRESSION
Cron expression for the heartbeat
"*/2 * * * * ?"
How the new advancing controller works:
Picking threads (ADVANCING_PICKINGTHREADS): Controls how many worker threads read events from the database. This handles only the picking/reading operations.
Processing buffer (ADVANCING_PROCESSINGBUFFERSIZE): Acts as a queue between picking and processing. When the buffer is full, no new events are read. When there’s available space (even just 1 position), that amount of events will be read.
Processing threads (ADVANCING_PROCESSINGTHREADS): Controls how many threads process the advancing events in parallel. Events are processed instantly if processing threads are available. If all processing threads are busy, events accumulate in the buffer until it reaches capacity.
Blocking behavior (ADVANCING_BLOCKPICKINGIFNOWORKERAVAILABLE): When enabled, prevents picking operations if no worker threads are available, ensuring better resource management.
The Process Engine is exposed on both the admin and public hosts, with a dedicated route for runtime process instances on the admin host. Routing is configured through the FlowX Helm chart, which renders either a Kubernetes Ingress (default) or a Gateway API HTTPRoute per service. CORS handling lives in the service code; only the allowed-origins list is deployment-specific.
Paths are set through services.process-engine.ingress.<key>.path (or gateway.<key>.paths) in the chart values. The admin and public routes share the same backend route family — the /onboarding prefix is stripped before forwarding so the backend receives /api/....
Comma-separated list of origins allowed to call this service from the browser. Supports wildcard subdomains. Must include every Designer, runtime renderer, and integration domain that calls Process Engine.
-
Allowed methods, allowed headers (including Authorization, Content-Type, Fx-Workspace-Id), and credential handling are baked into the service’s application.yaml with safe defaults. Override these only if you have a non-standard requirement.For the complete route reference, Gateway API HTTPRoute configuration, and route customization, see the ingress configuration guide.
For SSE (Server-Sent Events) communication configuration, refer to the Events Gateway setup guide.
The process engine uses a native script engine for executing JavaScript and Python business rules. The native engine runs scripts in separate Node.js and Python worker processes.
The native script engine is the default starting with 5.9.0, replacing the previous GraalVM-based engine. Scripts run in isolated subprocess pools. To revert to GraalVM, set APPLICATION_SCRIPT_ENGINE_PROVIDER=graalvm.