Environments

An environment defines the runtime your workflows execute in — which KNIME version to use, which extensions are installed, how the JVM is configured, and what additional files are available. Runner builds a Docker image from these settings the first time a schedule in this environment runs. Subsequent runs reuse the cached image, so startup is fast unless the environment changes.

Your environments

The environment list shows all environments in the current project. The Latest Run column is the quickest way to spot trouble: a failed status here means the last run in this environment did not pass, even if you haven't looked at the Runs page yet. Click the status to jump directly to that run.

You can filter by type (KNIME or Shell) and sort by name or last modified date.

Each environment has three actions:

• Clear Cache — deletes the cached Docker image and forces a full rebuild on the next run. Use this after changing system-level dependencies or when a run fails due to a stale image.
• Copy — duplicates the environment with all its settings. Useful for testing a new KNIME version alongside an existing one without starting from scratch.
• Delete — see Deleting an environment.

Creating an environment

Click Add Environment, fill in the fields below, and click Save. The type you select determines which additional sections appear. Creating environments requires the appropriate project role — if you don't have it, the Add Environment button is disabled. See Members & Roles for details.

General

Name — Required. Choose a name that describes what the environment does or what it runs on, for example "KNIME 5.3 — Production" or "Data Export". Members see this name when creating schedules.

Notes — Optional free-text field for documentation about this environment. Supports Markdown. A good place to record why a particular KNIME version was chosen, known issues, or setup steps that aren't obvious from the settings alone.

Type — Select KNIME to run KNIME workflows, or Shell to run shell scripts. The type cannot be changed after the environment is saved — if you need a different type, create a new environment or copy an existing one.

KNIME

These settings are only available for KNIME environments.

KNIME Version — The version of KNIME Analytics Platform to install in the Docker image. Runner supports multiple versions simultaneously; each version produces a separate cached image. When a new KNIME version releases, copy an existing environment, change the version, and run a test schedule before switching production schedules over.

Preference File — An optional .epf file exported from your local KNIME Analytics Platform via File → Export Preferences…. Use this to carry over your local KNIME settings — proxy configuration, credentials storage, database drivers — into Runner's execution environment. The uploaded file is stored in the project's Files.

Preference Entries — Individual key/value preference overrides, applied on top of the preference file if one is provided. Useful for setting specific preferences without exporting a full EPF file, or for overriding individual values from the file. The key field autocompletes from the uploaded preference file.

JVM Arguments — By default, Runner configures JVM arguments automatically for the selected KNIME version. Enable Configure JVM arguments manually only if you need to override this — for example to increase heap memory with -Xmx4G. Use Apply Version Defaults to load the recommended arguments for your KNIME version as a starting point, then adjust as needed. Removing required arguments can cause workflows to fail.

Extension Search — Searches the NodePit node catalogue to find KNIME extensions by name or keyword. Selecting an extension automatically adds its update site and feature identifier to the lists below.

Update Sites — URLs of Eclipse update sites to install extensions from. Most extensions are available from the official KNIME update sites, which the Extension Search handles automatically. Add custom update sites here for third-party or internal extensions — for example, https://download.nodepit.com/5.11 for NodePit extensions on KNIME 5.11.

Features — The feature identifiers to install, for example ws.palladian.nodes.feature.feature.group. Each feature must be available on one of the configured update sites and must not already be included in the base KNIME installation — installing a pre-installed feature causes the image build to fail.

Shell

Shell environments only use the General and Advanced settings. There are no Shell-specific fields — the shell script itself is uploaded on the schedule, not the environment.

Advanced

These settings apply to both KNIME and Shell environments.

Additional Files — Files made available inside the container at /nodepit/<filename>. Use this for JDBC drivers, licence files, certificates, or any other file that workflows depend on at runtime but that does not belong in the workflow itself. Files can be selected from the project's Files or uploaded directly here.

Additional Dockerfile Instructions — Raw Dockerfile instructions appended at the end of the generated Dockerfile. Use this to install system packages or configure the environment beyond what the other settings support — for example, installing Python or R for use with KNIME's scripting nodes.

Executor Tags — Tags that constrain which executors can run schedules using this environment. A run will only be picked up by an executor that has all the required tags set. Leave this empty to allow any executor to run the environment. See Executors for how tags are configured on the executor side.

Editing an environment

All fields can be edited after creation, with one exception: Type is locked once the environment is saved. If you need to change the type, create a new environment.

If your role does not permit editing, the form is shown in read-only mode.

Any change to the environment settings — including KNIME version, extensions, or additional files — takes effect on the next run. Runner detects the change and rebuilds the Docker image automatically. If you want to force a rebuild without changing any settings, use Clear Cache.

Deleting an environment

An environment can only be deleted if it has no schedules or runs referencing it. Remove or reassign those first — the Delete button is disabled until then.