JS Executor Configuration
Queue configuration
Section titled “Queue configuration”Queue type used for JS evaluation requests: kafka or in-memory
Optional prefix applied to all queue/topic names; useful for environment isolation
Kafka topic name for incoming JS evaluation requests
HTTP port exposing the /livenessProbe health check endpoint
JavaScript execution configuration
Section titled “JavaScript execution configuration”Interval in milliseconds to poll for JS execution responses
Maximum allowed size in bytes of a JS execution result
Kafka configuration
Section titled “Kafka configuration”Kafka Bootstrap Servers
Number of replicas for each Kafka topic partition
-1 = all; 0 = no acknowledgments; 1 = only waits for the leader to acknowledge
Maximum number of messages to accumulate before triggering a batch send
Time in milliseconds the producer waits before sending a batch, allowing more messages to accumulate
(EXPERIMENTAL) increase this value if you are planning to handle more than one partition (scale up, scale down) - this will decrease the latency
Time in milliseconds to wait for a response to a Kafka request before timing out
Time in milliseconds to wait when establishing a connection to a Kafka broker
Message compression codec for the producer: gzip, lz4 or none
Semicolon-separated Kafka topic configuration properties applied on topic creation
Set to true to enable Confluent Cloud-specific configuration (SSL + SASL)
Kafka client identifier; inject the pod name to easily identify the client via kafka-consumer-groups.sh
Enable SSL/TLS for Kafka broker connections
SASL mechanism for Confluent Cloud authentication: PLAIN, SCRAM-SHA-256, or SCRAM-SHA-512
Logging configuration
Section titled “Logging configuration”Log level: trace, debug, info, warn, or error
Directory path where log files are written
Log file name pattern; %DATE% is replaced with the current date
JavaScript execution and monitoring configuration
Section titled “JavaScript execution and monitoring configuration”WARNING: setting this to “false” is DANGEROUS BY DESIGN. The non-sandbox path compiles and runs user-supplied scripts in the host realm via vm.compileFunction; it provides no isolation and exposes the host process (file system, environment variables, child_process, etc.) to script authors. Use “false” only as a performance trade-off in trusted, non-public clusters where every script author is fully trusted.
Log memory usage every N script executions
Print execution statistics every N script executions
Log the script body every N script executions
Maximum number of compiled scripts kept in the cache
Execution time threshold in milliseconds above which a script is considered slow and logged
Log the script body when execution time exceeds slow_query_log_ms threshold
Node.js runtime configuration
Section titled “Node.js runtime configuration”Standard Node.js environment variable for passing CLI flags to the runtime process. The following flags are recommended best practices for production deployments:
--max-old-space-size=200— caps the V8 old-generation heap at 200 MB. Increase this value based on your workload needs. For containerized deployments, set the container memory limit at least 100 MB above this value — Node.js requires additional memory beyond the heap limit for runtime internals, and a tight limit causes OOM evictions.--permission— activates Node.js’s built-in Permission Model (available since Node.js 20), which denies all privileged operations by default and requires explicit allow-flags for each capability. Recommended for publicly available deployments.--allow-fs-read=/usr/share/tb-js-executor/*— grants read-only filesystem access exclusively to the executor’s own installation directory, blocking any attempt by a script to read arbitrary files on the host. Required when--permissionis set.
Was this helpful?