Technical Reference
Infrastructure & OS Requirements
- Operating Systems: Requires a supported operating system and runtime environment for KNIME Analytics Platform (see KNIME Analytics Platform documentation). macOS is not supported.
- KNIME Version: Requires KNIME Analytics Platform 5.8.1 or later with KNIME Executor Connector and KNIME Remote Workflow Editor for Executor extensions. Version 5.12 or later is required to use the Data Security settings.
- Dependencies: Requires libraries for the CEF browser component (see Equo documentation).
Networking & Firewall Specifications
Sovereign executors establish an outbound connection; no inbound connection is required.
- Port: TCP 443 (https and wss).
- Required Endpoints:
<hub-domain>api.<hub-domain>ws.<hub-domain>storage.<hub-domain>
System States & Status Definitions
Environment States:
- Not configured: No executor is added.
- Starting up: At least one executor of the environment is starting up.
- Running: At least one executor is running.
- Stopped: All executors are offline.
- At full capacity: Executors are busy or at concurrency limits.
- Disabled: Environment has been disabled and cannot be used.
Sovereign Executor States:
- Starting up: Executor is being initialized and launched.
- Running: Running and connected to Hub.
- Offline: Disconnected (network issue or machine shutdown).
- At full capacity: Busy and not accepting new jobs.
Licensing & vCore Calculations
- Calculation: Bare-metal executors use all visible CPU cores. Hyperthreading is calculated as two vCores per physical core.
- Limits: Registration fails if the CPU count exceeds available license capacity or team vCore limits.
- Control: vCore usage can be limited via container constraints (Docker) or Linux cgroups.
Executor Agent CLI
- configure: Interactive process to link the agent to a Hub URL and token.
- start: Launches the agent process.
- --executor: Flag used during configuration to point to the KNIME installation directory (containing
knime.ini).
Automatic Truststore Management (Linux Only)
On Linux operating systems, host system CA certificates are automatically merged into the truststore. With agents version >1.1, this automatic truststore management logic is applied consistently to both the Agent and the Executor process, allowing workflows, connectors, and HTTPS calls to trust system/corporate CA certificates out of the box without manual import steps.
Certificate Locations & Scanning
These paths are the standard CA-bundle locations used by common Linux distributions and libraries such as OpenSSL. Windows does not provide an equivalent file-based trust store, so this automatic truststore management applies to Linux only. Previously, only the Executor Agent read these locations by default. The Executor now reads them the same way, so both processes trust the same system and corporate CA certificates without manual import steps.
Bundle files (checked in order, stopping at the first match found):
/etc/ssl/certs/ca-certificates.crt/etc/pki/tls/certs/ca-bundle.crt/etc/ssl/ca-bundle.pem/etc/pki/tls/cacert.pem/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem/etc/ssl/cert.pem
Directories (all locations scanned):
/etc/ssl/certs/etc/pki/tls/certs
Custom Path Configuration (Environment Variables)
If custom certificate locations are required, system administrators can override the default lookup paths using standard environment variables:
SSL_CERT_FILE: Overrides the default CA bundle file path.SSL_CERT_DIR: Overrides the default CA certificate directory paths.