Environments

An environment defines the runtime your workflows or scripts execute in — for example, which KNIME version to use and which extensions are installed, or which Docker image to run. 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, Shell, or Docker) 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, Shell to run shell scripts, or Docker to run any containerized workload — Python, Node.js, or anything else you can package into an image. 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 into this environment's image. New environments default to a recent supported KNIME version, but you can pick any other supported version instead. 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. Entering nightly installs the latest KNIME nightly build; nightly environments are never cached and rebuild from scratch on every run, which is slower and not recommended for production.

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.12 for NodePit extensions on KNIME 5.12.

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.

Docker

These settings are only available for Docker environments. Docker environments open Runner up to virtually any containerized workload — not just KNIME workflows and shell scripts, but Python, Node.js, or anything else you can package into an image. Point the environment at an existing image or your own Dockerfile, then tailor each schedule with its own command and environment variables without ever touching the underlying image.

Source — Image to pull an existing image from a registry, or Dockerfile to build one from a Dockerfile you upload. Switch to Dockerfile if you need to install additional tools or dependencies on top of a base image.

Image — Required when Source is Image. The image reference to pull, for example python:3.12-slim. Include a registry host for images outside Docker Hub, for example ghcr.io/acme/my-image:latest. Pick an image that already provides whatever runtime the schedule's Command needs — python:3.12-slim for a Python command, node:20-alpine for Node.js, or a minimal alpine image for shell commands. See the Command examples in Schedules for each.

Dockerfile — Required when Source is Dockerfile. Select a Dockerfile already uploaded to the project's Files or upload a new one directly.

Private Registries — Credentials for pulling images from private registries. Add one entry per registry host, each with a host, username, and password. Add an entry for every private registry your image — or, for a Dockerfile source, any base image referenced with a FROM instruction — is hosted on.

Always Pull — When enabled, Runner checks for a newer version of the image before every run instead of reusing the cached one. Use this for images tagged latest or another mutable tag where you want runs to always pick up the newest build. Leave disabled for immutable, version-pinned tags to avoid the extra pull on every run.

Build Arguments — Only available for a Dockerfile source. Name/value pairs passed as Docker build arguments (--build-arg) to the build, for example to parametrize a base image version referenced in the Dockerfile with ARG.

Advanced

These settings apply to all environment types.

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. For a Docker environment with Source set to Dockerfile, these files are also available to the Dockerfile's own COPY and ADD instructions during the build — schedule-level additional files are not, since those are only mounted at runtime.

Additional Dockerfile Instructions — Raw Dockerfile instructions appended at the end of the 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. For a Docker environment with Source set to Dockerfile, these instructions are appended after your own uploaded Dockerfile, not just a Runner-generated one.

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.

Executor Architecture — Restricts runs to executors supporting one of the selected CPU architectures (x64, arm64). Leave empty to allow any architecture. KNIME environments are always fixed to x64, since that's the only architecture KNIME supports, and this field is disabled for them. See How runs are dispatched for how architecture matching works.

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.