Running workflows
Every time a workflow executes, Knime creates a run: a single execution of the workflow in a chosen environment. A run starts in one of two ways:
- Manual run: you start it yourself from the workflow page.
- Deployment: it runs automatically as a schedule, service, trigger, or data app.
Every run requires two independent choices:
- An environment: what software the run uses.
- A compute class: how much hardware power the run gets.
This guide explains the concepts of running workflows in Knime: environments, runs, and compute classes. For definitions of runtimes and executors, see the Glossary. For a better understanding of deployments, see How deployments work.
Key concepts
| Concept | What it is |
|---|---|
| Run | A single execution of a workflow. Created by editing a workflow, a manual workflow run, or a deployment. |
| Deployment | A persistent, reusable way to run a workflow automatically, as a data app, schedule, service, or trigger. |
| Environment | The software that runs a workflow: a runtime plus its settings and preferences. |
| Compute class | The hardware sizing and compute allocation (CPU cores, RAM/memory, and future capabilities like GPUs) assigned to execute a specific run. |
| Runtime | The Knime-provided software that executes workflows, e.g. Knime Executor 5.13 plus extensions and settings. |
| Executor | The headless Knime process that runs the workflow's nodes. |
Runs
A run is a single execution of a workflow in a chosen environment. Each run contains a copy of the workflow plus metadata such as the creator, permissions, and timestamps.
A run is created when you:
- Edit a workflow in the browser
- Start a manual run
- Execute a deployment
You can inspect a run during or after execution and view the output of each node.
The team's Run history page lists all recent runs for the team, both manual and deployment runs. Each workflow page also lists that workflow's recent runs.
Every run consumes execution credits. The amount depends on the selected environment and compute class. See Optimize workflows for cost and speed.
Manual runs
A manual run is a run you start yourself from the workflow page. You choose the workflow version and the environment, and that version is copied and executed immediately.
Manual runs are useful for testing a workflow before you create a deployment.
Deployments
A deployment is a persistent, reusable way to run a workflow automatically. Unlike a manual run, a deployment runs according to its type:
| Type | When it runs |
|---|---|
| Data app | When the user launches the data app. |
| Schedule | At the selected timestamp, or at fixed intervals. |
| Service | When an external tool sends a request to the HTTP endpoint. |
| Trigger | As soon as the trigger event happens. |
Each time a deployment executes, it creates a new run in the environment and compute class selected for the deployment. All past runs are listed under the deployment.
Environments
An environment defines what software a workflow runs with. It consists of a runtime plus its configurations, for example:
- Python or R scripting environments such as
- Database drivers and Kerberos settings (Kerberos on sovereign environments only)
- Node restrictions
- Log levels
- Who can use it, for example a specific team or all users of your Knime instance
An environment doesn't define hardware sizing. You choose memory and CPU separately through compute classes.
There are two kinds of environments:
- Managed: provisioned and run by Knime in the cloud.
- Sovereign: run by you in your own infrastructure.
You choose an environment whenever you edit a workflow in the browser, start a manual run, or create a deployment. Global admins create and manage environments for all teams in the instance. For details, see Execution Resources guide.
Every user has a default execution environment, so they can run workflows without setting anything up first. Admins can also change the default, and users can pick a different environment per run — for example, a lightweight environment for editing a workflow and a full-featured one for scheduled production runs.
Compute class
A compute class defines the hardware a run executes on — cores and memory. Compute classes are predefined by Knime (Light, Standard, and Performance) and aren't customer-configurable. Each compute class has a multiplier that determines how many execution credits a run consumes.
Users can set a default compute class that's pre-selected for new runs, and choose a different one per run when needed.
Throttled compute class
A special, invisible Throttled compute class is automatically applied to all of an instance's runs once the instance reaches its execution credit limit.
Compatibility
Not every workflow is compatible with every environment — for example, a workflow might need a database driver, or a Python or R package, that isn't available in the selected environment. Before you start a run, check that the workflow is compatible with the environment you've selected. See extensions in the default environment for the extensions available by default.