Skip to main content
The Application Manager and Runtime Manager share the same container image and Helm chart. Refer to the Deployment Guidelines in the release notes to ensure compatibility and verify the correct version.

Infrastructure prerequisites

The Runtime Manager service requires the following components to be set up before it can be started:
  • PostgreSQL
  • MongoDB
  • Redis
  • Kafka
  • OAuth2 Authentication

Dependencies

Change the application name

Default Value: application-manager -> must be changed to runtime-manager

Core service configuration

Database configuration

The Runtime Manager uses the same PostgreSQL (to store application data) and MongoDB (to manage runtime data) as application-manager. Configure these database connections with the following environment variables:

PostgreSQL (Application data)

MongoDB (Runtime data)

Redis configuration

Runtime Manager uses Redis for caching. Configure Redis connection using the standard Redis environment variables. Quick reference:
Both SPRING_DATA_REDIS_* and SPRING_REDIS_* variable prefixes are supported. The SPRING_DATA_REDIS_* prefix is the modern Spring Boot standard and is recommended for new deployments.
For advanced Redis deployment modes (Sentinel, Cluster) and SSL/TLS setup, see the Redis Configuration guide. Note that Sentinel and Cluster modes are only supported by the Events Gateway service.

Kafka configuration

Kafka connection

Kafka OAuth authentication

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.

Kafka topics

Since the Runtime Manager shares the same container image as the Application Manager, it uses the same Kafka topic definitions. However, the Runtime Manager conditionally activates a listener for the build.runtime-data topic (based on spring.application.name=runtime-manager), which is how it receives runtime data from the Admin service.
The KAFKA_TOPIC_BUILD_RUNTIMEDATA topic must resolve to the same value in both Admin and Runtime Manager. If the KAFKA_TOPIC_NAMING_ENVIRONMENT prefix differs between services (common after export/import to a new environment), Admin will produce to one topic and Runtime Manager will consume from another, causing data not to be passed back to the calling process after subprocess execution.

Build topics

Consumer configuration

Process topics

Other topics

For the full list of application resource topics (export, import, sync, resource usages, etc.), see the Application Manager Kafka configuration.

Scheduler configuration

The Runtime Manager scheduler times out stalled build import/export sessions: A build import or export that stays in progress longer than FLOWX_SCHEDULER_BUILDTIMEOUT is moved to IMPORT_TIMEOUT or EXPORT_TIMEOUT. The default of 14400 seconds is 4 hours. FLOWX_SCHEDULER_BUILDIMPEXTIMEOUTCRON controls how often the check runs, every 10 minutes by default.
Raise FLOWX_SCHEDULER_BUILDTIMEOUT if large builds are legitimately being marked as timed out before they finish. The equivalent timeouts for application version import/export are configured on the Application Manager. See Application Manager scheduler configuration.

Authentication configuration

Security type

Resource server (opaque-token introspection)

In 5.1.x, the Runtime Manager validates access tokens using opaque-token introspection against the identity provider’s introspect endpoint. The introspection URI is derived automatically: ${SECURITY_OAUTH2_BASE_SERVER_URL}/realms/${SECURITY_OAUTH2_REALM}/protocol/openid-connect/token/introspect

Service account configuration

File storage configuration

S3-compatible storage is used for storing application files, exports, and imports. The Runtime Manager supports MinIO, AWS S3, and other S3-compatible storage solutions.

Temporary storage for build exports and imports

Runtime Manager uses the container’s /tmp directory as working space for build exports and imports. It writes each exported resource and assembles the export archive in /tmp before uploading it to S3-compatible storage, and it unpacks imported builds there. Size /tmp to hold your largest build both unpacked and as a zip archive, for every export or import that runs at the same time. Builds exported with binary files included are larger. When the container runs with a read-only root filesystem, mount a writable volume at /tmp. Prefer a disk-backed emptyDir: a memory-backed one (medium: Memory) counts against the container’s memory limit. To increase the volume, override the Runtime Manager volumes in your Helm values:
If your Runtime Manager values aren’t nested under services, set extraVolumes and extraVolumeMounts at the top level of those values instead.
extraVolumes and extraVolumeMounts are lists, so your values replace the whole list. Include any other volumes the Runtime Manager already mounts.

Ingress configuration

The Runtime Manager uses the standard FlowX.AI ingress pattern with three separate ingress configurations. For complete setup instructions including the full ingress template, CORS configuration, and troubleshooting, see the Ingress Configuration Guide.

Public ingress

Service-specific values for Runtime Manager Public:
  • Ingress name: runtime-manager-public
  • Service path: /rtm/api/runtime(/|$)(.*)
  • Service name: runtime-manager
  • Rewrite target: /api/runtime/$2
  • Fx-Workspace-Id: Required

Admin ingress

Service-specific values for Runtime Manager Admin:
  • Ingress name: runtime-manager-admin
  • Service path: /rtm/api/build-mgmt(/|$)(.*)
  • Service name: runtime-manager
  • Rewrite target: /api/build-mgmt/$2
  • Fx-Workspace-Id: Required

Admin instances ingress

Service-specific values for Runtime Manager Admin Instances:
  • Ingress name: runtime-manager-admin-instances
  • Service path: /rtm/api/(runtime|runtime-internal)/(.*)
  • Service name: runtime-manager
  • Rewrite target: /api/$1/$2
  • Fx-Workspace-Id: Required

Complete Ingress Configuration

View the centralized ingress guide for the complete configuration template, annotations reference, and best practices.
Note: Replace placeholders in environment variables with the appropriate values for your environment before starting the service.

Troubleshooting

Common issues

Symptoms: Service fails to start with database connection errors.Solutions:
  1. Verify the PostgreSQL database exists and is accessible
  2. Check that the database user has appropriate permissions
  3. Ensure network connectivity between the pod and PostgreSQL service
  4. Verify the JDBC URL format is correct
  5. For MongoDB, confirm the replica set is healthy and retryWrites=false is set in the connection URI
Symptoms: Messages not reaching consumers, runtime data not syncing between Admin and Runtime Manager.Solutions:
  1. Verify that KAFKA_TOPIC_BUILD_RUNTIMEDATA resolves to the same value in both Admin and Runtime Manager
  2. Check that KAFKA_TOPIC_NAMING_ENVIRONMENT is consistent across services
  3. Ensure Kafka broker addresses are correct and reachable
  4. Review consumer group IDs for conflicts with other deployments
  5. Check Kafka logs for authorization or connectivity errors
Symptoms: 401/403 errors when communicating with other FlowX services.Solutions:
  1. Verify the Keycloak service account (flowx-runtime-manager-sa) is properly configured
  2. Check that client secrets match between configuration and Keycloak
  3. Ensure the service account has required roles assigned
  4. Confirm SECURITY_TYPE is set to oauth2 (default for 5.1.x)
  5. Verify the OAuth2 base server URL, realm, and token introspection URI are accessible
Symptoms: Some build exports or imports fail with No space left on device while others succeed, and the failures look random.Solutions:
  1. Check the size of the volume mounted at /tmp in the Runtime Manager pod
  2. Increase its sizeLimit as described in Temporary storage for build exports and imports
  3. Switch a memory-backed emptyDir (medium: Memory) to a disk-backed one
  4. To free the space right away, replace the Runtime Manager pods, for example with kubectl rollout restart. An emptyDir volume is emptied only when its pod is removed, not when the container restarts.

Application Manager

Companion service sharing the same container image and Helm chart

Redis Configuration

Complete Redis setup including Sentinel and Cluster modes

Kafka Authentication

Configure Kafka security and authentication

IAM Configuration

Identity and access management setup
Last modified on October 8, 2026