Glossary
This page defines the features and limits that make up a Knime plan, and the core execution concepts behind them. Use it to understand what each item in a plan comparison means.
Users and teams
Builders
A builder is a person with a unique ID who can create, edit, deploy, and execute workflows, or administer and govern them. The number of builders determines the price of a plan.
Consumers
A consumer is a person who uses the deployments that builders share with them, such as data apps. A consumer can:
- Open and run data apps that are shared with them
- Use the results that a deployment produces
A consumer can't create, edit, or deploy workflows, and can't administer Knime.
Builders and consumers compared
Builders create and run workflows. Consumers only use the deployments that builders share with them. The following table shows what each role can do.
| Action | Builder | Consumer |
|---|---|---|
| Create and edit workflows | Yes | No |
| Deploy workflows as data apps, schedules, triggers, or services | Yes | No |
| Run workflows and deployments | Yes | Only deployments shared with them |
| Administer and govern workflows | Yes | No |
| Count toward the price of a plan | Yes | No |
Teams
The number of separate team workspaces you can create.
Departmental usage allocation
Shows how much each team or department consumes of the credit pool. The pool itself stays shared across the whole organization.
Consumption
Execution credits
The metered unit for running workflows. One credit equals one node-minute. Where the credits come from depends on your plan:
- Business and Enterprise: Your committed band
For details, see Understanding execution credits.
AI credits
A separate metered pool for AI and K-AI consumption. Knime tracks AI credits apart from execution credits. See Understanding AI credits.
Execution
Compute classes
The tiers of execution speed and performance a workflow can run at. For how compute classes apply to runs, see Compute class. For credit costs, see Execution compute classes.
Runtimes
If a workflow is a program, a runtime is the software that executes it. Every environment, managed or sovereign, runs on a runtime.
A runtime bundles the Knime executor, a set of extensions, and their preference settings. Knime provides all runtimes as container images. You choose which runtime an environment uses instead of building your own image.
See extensions in the default environment for the list of extensions bundled with the default runtime.
Custom runtimes
You can't build or upload your own executor image. Before you configure database drivers or other executor preferences on an environment, contact Knime support. Kerberos is only available on sovereign environments; see Configure Kerberos. For Python packages and custom extensions, see Customize an environment.
Executors
An executor is a headless Knime installation/process that runs workflows in the background, without a graphical interface. It receives commands from Knime or the browser editor and executes the workflow's nodes.
When a run starts, an executor configured by the selected environment picks it up and executes it. In managed environments, each run executes in its own isolated container, which is discarded when the run ends. This gives each run a clean state and keeps runs from affecting each other. In sovereign environments, executors run in your own infrastructure.
Custom (execution) environment
The ability to define your own sovereign execution environment for running workflows, instead of using the default shared environment that Knime manages. A custom environment can include extensions, and builder guardrails for nodes and for Python and R scripting packages.
Private environment
A fully isolated deployment of Knime, instead of shared SaaS infrastructure. Available as a paid add-on for Enterprise only.
Deployments and assets
Deployments
The number of workflows you can run in production. Deployments include schedules, data apps, triggers, and REST services.
Private assets
Saved items that aren't in production yet, such as components and draft workflows that you haven't deployed.
Private sharing
The ability to share workflows and other assets with specific people instead of the whole organization. Included in every plan.
Private gallery
A private gallery of reusable components and workflows for your organization, separate from the public Community Gallery. See Private gallery.
Workflow labels
A labeling system to organize and classify workflows.
Access and integration
API access keys
The ability to generate keys for programmatic access to Knime through its API.
Secrets
Stored credentials, API keys, and tokens that a builder saves securely and reuses in workflows.
AI gateway governance
Central management and governance of AI model access and usage across your organization. See GenAI gateway.
Governance and compliance
Builder guardrails
Admin controls that limit what builders can do, for example restricting certain nodes or enforcing policies.
Job history
How far back you can view records of past execution jobs. The range depends on your plan and is customizable.
Audit trails
A log of user actions that records who did what and when, for compliance and security reviews. Enterprise includes a configurable full export covering 365 days. See Audit trails.