Introduction
KNIME Business Hub is a customer-managed Hub instance. Once you have a license for it and proceed with installation you will have access to Hub resources and will be able to customize specific features, as well as give access to these resources to your employees, organize them into Teams and give them the ability to manage specific resources.
This guide provides information on how to administrate a KNIME Business Hub instance.
To install a KNIME Business Hub please refer to the KNIME Business Hub Installation Guide.
A user guide is also available here, which contains instructions on how to perform team administration tasks. Team admins are designated by the global Hub admin, and have control over their team’s allocated resources, can add users to their team, create execution contexts and have an overview of the team’s deployments. In this way the Hub administration tasks are distributed and reallocated to those users that have a better overview of their own team necessities.
Create and manage teams
A team is a group of users on KNIME Hub that work together on shared projects. Specific Hub resources can be owned by a team (e.g. spaces and the contained workflows, files, or components) so that the team members will have access to these resources.
Sign in to the KNIME Business Hub instance with the admin user name by visiting the KNIME Business Hub URL.
Then click your profile picture on the right upper corner of the page and select Administration to go to the KNIME Business Hub Administration page. Click Teams in the menu on the left. Here you will be able to see an overview of the existing teams and you will be able to manage them.
Create a team
To create a new team click the yellow plus button on the right.

After you create a new team you will be redirected to the new team’s page. Here you can change the name of the team. To do so click the name of the team under the team logo on the left side of the page. The name of the team can also be changed at any point in time by the team administrator.
From the team’s page you can:
-
Add members to the team
-
Change their role to, for example, promote a user to team admininistrator role
Here you might for example want to assign the team to a team administrator. To do so click Manage team and enter the user name of the user you want to assign as a team administrator for the current team. Then click on the role and select Member and Admin. At the same time you might want to delete the global admin user name from the team members list. To do so click the bin icon corresponding to that user. Click Save changes to finalize the setting.
Allocate resources to a team
To allocate resources to a team navigate to the KNIME Business Hub Administrator page and select Teams from the menu on the left.
Here you can see an overview of the teams available, their allocated resourced, and of their current usage. Click the three dots on the right upper corner of the card corresponding to the team you want to allocate resources to.
Select Manage resources from the menu. A panel on the right will open where you can select the resources you want to allocate.

Here you can change:
-
The maximum number of members allowed in that team
-
The maximum number of execution vCore tokens allowed for that team
Click Save changes when you have set up the resources for the current team.
Manage team members
From the KNIME Business Hub Administration page you can also manage the team members.
Click the three dots on the right upper corner of the card corresponding to the team. From the menu that opens select Manage members. In the side panel that opens you can add members to a team, or change the team members role.
Delete a team
From the KNIME Business Hub Administration page you can also delete a team.
Click the three dots on the right upper corner of the card corresponding to the team. From the menu that opens select Delete. Be aware that this operation will delete also all the team resources, data and deployments.
Users management
To see a list of all the users that have access to your KNIME Business Hub instance you can go to the KNIME Business Hub Administration page and select Users from the menu on the left.

Here you can filter the users based on their team, the type of users and their username and name. To do so click the funnel icon in the users list. You can also search the users by using the magnifier icon and typing the keyword in the field that appears.
Delete a user
You can delete a user from the KNIME Business Hub Administration page. Click the three dots and select Delete. You will need to confirm the user deletion in the window that opens by clicking Delete user. Be aware that this action will also delete all data from the deleted user and it will not be possible to restore the user.
Note that this user will continue to exist in Keycloak itself and you may want to delete it from there as well.
Make a user Global Hub Admin
Users are managed in the backend via the Keycloak instance embedded in KNIME Business Hub. Therefore, the operation of promoting a registered user to the role of Global Hub Admin is done in Keycloak.
To do so follow these steps:
-
First you will need to access the keycloak admin console. To do so you will need the credentials that are stored in a kubernetes secret called
credential-knime-keycloak
in theknime
namespace. To get the required credentials, you need to access the instance the Business Hub is running on and run the following command:kubectl -n knime get secret credential-knime-keycloak -o yaml
This will return a file that contains the
ADMIN_PASSWORD
and theADMIN_USERNAME
. Please notice that they are bothbase64
encrypted. In order to get the decrypted username and password, you can run the following commands:echo <ADMIN_PASSWORD> | base64 -d echo <ADMIN_USERNAME> | base64 -d
-
Then go to
http://auth.<base-url>/auth/
and login. -
In the top left corner click the dropdown and select the "Knime" realm, if you are not there already.
Figure 5. Select the "Knime" realm -
Navigate to the Users menu and search for the user by name or email:
In order for a user to appear in this list, it is necessary that they have logged into your KNIME Business Hub installation at least once.
-
Click the user and go to the Groups tab. Click Join Group and either expand the hub group by clicking it, or search for "admin". Select the admin group and click Join:
Figure 7. Making a user a Global Hub Admin in Keycloak. If you are searching for the group then the group might show up under its full path "/hub/admin" -
Done. The user now has the role of Global Hub Admin, and can access the admin pages from within the Hub application to e.g., create teams or delete users.
Please notice that right now there are some operations that can be performed only by the global admin user that was created contextually to the KNIME Business Hub instance installation. Therefore, it is recommended to not delete the corresponding global admin user even when more users have been promoted to global admin users. |
Docker executor images
In order to create execution contexts for their teams, team admins will need to reference the Docker image of the KNIME Executor that they want to use.
Public Docker executor images are made available by KNIME which correspond to the full builds of KNIME Executor versions 4.7.x.
The currently available executor images have the following docker image name:
-
registry.hub.knime.com/knime/knime-full:r-4.7.0
-
registry.hub.knime.com/knime/knime-full:r-4.7.1-119
-
registry.hub.knime.com/knime/knime-full:r-4.7.2-139
-
registry.hub.knime.com/knime/knime-full:r-4.7.3-160
However you might want to add specific extensions to the KNIME Executor image that is made available to team admins to create execution contexts.
The following section explains how to do so.
Add extensions to an existing Docker image
In order to install additional extensions and features to the KNIME Executor image, you will need to first create a Dockerfile
.
The file is named Dockerfile
with no file extension.
You can use the example Dockerfile
below which demonstrates how to extend the base image with a custom set of update sites and features.
# Define the base image FROM registry.hub.knime.com/knime/knime-full:r-4.7.2-139 # Define the list of update sites and features # Optional, the default is the KNIME Analytics Platform update site (first entry in the list below) ENV KNIME_UPDATE_SITES=https://update.knime.com/analytics-platform/4.7,https://update.knime.com/community-contributions/trusted/4.7 # Install a feature from the Community Trusted update site ENV KNIME_FEATURES="org.knime.features.geospatial.feature.group" # Execute extension installation script RUN ./install-extensions.sh
The KNIME_UPDATE_SITES
environment variable determines the update sites that will be used for installing KNIME Features. It accepts a comma-delimited list of URLs.
The KNIME_FEATURES
environment variable determines the extensions which will be installed in the KNIME Executor. It accepts a comma-delimited list of feature group identifiers.
A corresponding update site must be defined in the KNIME_UPDATE_SITES
list for feature groups to be successfully installed.
You can get the necessary identifiers by looking at Help → About KNIME → Installation Details → Installed Software in a KNIME instance that has the desired features installed.
Take the identifiers from the "Id" column and make sure you do not omit the .feature.group
at the end (see also screenshot on the next page).
The base image contains a shell script install-extensions.sh
which lets you easily install additional extensions in another Dockerfile
.
Once the Dockerfile
has been customized appropriately, you can build a Docker image from it by using the following command:
# Replace <image_name> and <tag_name> with actual values docker build -t <image_name>:<tag_name> .
Python and Conda in Docker images
When you create an Execution Context on KNIME Business Hub based on a full build you will have KNIME Python bundled available. If you need additional libraries you would need to make them available on the Hub instance.
You can do this in two ways:
-
Use the Conda Environment Propagation node.
-
Customize the Executor image used.
To get started with Conda environment propagation, check out KNIME Python Integration Guide. However, any libraries installed using Conda environment propagation will be removed when the executor restarts and installed again next time, so libraries that are used often should be installed as part of the executor Docker image.
In order to do so you need to:
-
Install Python in the executor Docker image
-
Declare to the execution context the path to the Python installation folder so that the executor can execute Python nodes
Install Python in the executor Docker image
The first step is the installation of Python and an environment manager for instance miniconda on a Docker image.
To do so, first you need the Docker Project to hold a miniconda installer near the Dockerfile, for example:
python-image/ container/ |-Miniconda3-py310_23.3.1-0-Linux-x86_64.sh dockerfiles/ |-Dockerfile
You will also need to provide a .yml
file that will contain all the modules, packages and Python version that you need to install in order to execute the Python scripting nodes.
The .yml
file could look like the following:
name: py3_knime # Name of the created environment channels: # Repositories to search for packages - defaults - anaconda - conda-forge dependencies: # List of packages that should be installed # - <package>=<version> # This is an example of package entry structure - python=3.6 # Python - scipy=1.1 # Notebook support - numpy=1.16.1 # N-dimensional arrays - matplotlib=3.0 # Plotting - pyarrow=0.11 # Arrow serialization - pandas=0.23 # Table data structures
Then you need to pull any available executor Docker image, install miniconda in batch mode on the image and define the environment variable for conda, as in the following example.
Also you will need to create your environments, that you specified in the .yml
files.
# getting recent knime-full image as a basis FROM registry.hub.knime.com/knime/knime-full:r-4.7.3-160 # getting Miniconda and install in batch mode COPY container/Miniconda3-py310_23.3.1-0-Linux-x86_64.sh /home/knime/miniconda-latest.sh RUN bash miniconda-latest.sh -b # adding path to Miniconda bin folder to system PATH variable ENV PATH="/home/knime/miniconda3/bin:$PATH" # copy default conda environments into container COPY --chown=knime envs/ ./temp_envs RUN conda env create -f ./temp_envs/py3_knime.yml && \ rm -rf ./temp_envs
When installing conda and creating the environments you will obtain the following paths that will need to be added in the .epf
file of the customization profile during the set up of the execution context.
For example based on the above Dockerfile:
<path to conda installation dir>=/home/knime/miniconda3/ <path to default conda environment dir>=<path to conda installation dir>/envs/<name of the env>
Now you can build the new Docker image, for example:
docker build . -f /dockerfiles/Dockerfile -t knime-full:4.7.3-with-python
Finally retag the image to make it useable for your embedded registry on Business Hub:
docker tag knime-full:4.7.3-with-python registry.<hub-url>/knime-full:4.7.3-with-python
Once you have created the Docker image with Python installed create an execution context that uses the newly created Docker image.
Set up the execution context
Now you need to set up and customize the execution context.
In order to declare to the execution context the path to the Python installation you will need to build a dedicated customization profile and apply it to the execution context.
-
Build the
.epf
file by following the steps in KNIME Python Integration Guide and exporting the.epf
file. To export the.epf
file from KNIME Analytics Platform go to File > Export Preferences… -
Open the file and use only the parts related to Python/conda.
The .epf
file could look like the following:
/instance/org.knime.conda/condaDirectoryPath=<path to conda installation dir> /instance/org.knime.python3.scripting.nodes/pythonEnvironmentType=conda /instance/org.knime.python3.scripting.nodes/python2CondaEnvironmentDirectoryPath=<path to default conda environment dir> /instance/org.knime.python3.scripting.nodes/python3CondaEnvironmentDirectoryPath=<path to default conda environment dir>
Find more details on how to set-up the .epf file in the Executor configuration section of the KNIME Python Integration Guide.
|
Now follow these steps to customize the execution context:
-
Build the
.zip
file containing the customization profile using the.epf
file you just created. -
Upload the customization profile
.zip
file to KNIME Business Hub. -
Apply the customization profile to the execution context.
Advanced configuration
This section covers some of the configuration settings that are available for your KNIME Business Hub instance.
The following configurations are available in the KOTS Admin Console and can be changed after the installation and first minimal configuration steps are concluded successfully.
Configure networking
In the "Networking" section of the KOTS Admin Console you can:
-
Deploy an external load balancer for traffic ingress: this feature takes effect only if your cloud provider and kubernetes distribution support automatic load balancer provisioning.
-
Enable Transport Layer Security (TLS): the encryptio n protocol that provides communications security is highly recommended especially for KNIME Business Hub instances deployed in a production environment.
-
Enable advanced ingress configuration: you can customize the ingress proxy behavior, for example configuring the read/send/connect timeouts.

Configure TLS
If you enable the Transport Layer Security (TLS) you need to have a certificate that is valid for all the URLs defined during the installation.
We recommend to create a wildcard certificate for <base-url>
and *.<base-url>
, e.g. hub.example.com
and *.hub.example.com
.
Check Enable TLS in the "Networking" section of the KOTS Admin Console.
-
Provide your own certificate: Select Provide your own certificate to be able to upload the certificate files.
You will need an unencrypted private key file and a certificate file that contains the full certificate chain. You usually can get a certificate from your company’s IT department or Certificate Authority (CA).
Another possibility, if you have a public domain name, is to use
letsencrypt
to obtain a certificate.Both certificates need to be PEM formatted as requested by the
ingress-nginx-controller
(see the relevant documentation here). -
Select AWS ACM Certificate if, instead, you have deployed an AWS Elastic Load Balancer (ELB). In this case you can use AWS Certificate Manager (ACM) and set the certificate as an annotation directly on the loadbalancer. You can find more information in AWS documentation for ACM here.
Once you obtained the certificate Amazon Resource Name (ARN) in the form
arn:aws:acm:<region>:<account-id>:certificate/<certificate-id>
, insert the ARN in the corresponding field as shown in the image below.
Create a collection
It is possible to create collections on your KNIME Business Hub instance.
KNIME Collections on KNIME Hub allow upskilling users by providing selected workflows, nodes, and links about a specific, common topic.
One example of a collection can be found on KNIME Community Hub here.
This is a feature of KNIME Business Hub - Enterprise edition. |
In order to create a new collection page you need to be a Global Admin of your KNIME Business Hub instance.
The creation of a collection is possible via REST API, and a description of the different configurations can be found in your KNIME Business Hub API doc at the following URL:
api.<base-url>/api-doc/catalog/#/Collections
e.g. api.hub.example.com/api-doc/catalog/#/Collections
.
In order to create a collection the items (i.e. workflows and nodes) that are collected need to be stored and accessible on the same KNIME Business Hub instance where collection is created.
To create the collection you will need then to build a json file with the schema that is available in the API doc in the Collections section, under the POST /collections
request description.
The following is an example that would allow you to build a collection, similar to the one available on KNIME Community Hub here.
In the first section you can for example set up a title, a description, a so-called hero, which is the banner image at the top right of the example collection page, and tags:
{ "title": "Spreadsheet Automation", "description": "On this page you will find everything to get started with spreadsheet automation in KNIME", "ownerAccountId": "account:user:<global-admin-user-id>", "hero": { "title": "New to KNIME?", "description": "Get started with <strong>KNIME Analytics Platform</strong> to import all the examples and nodes you need for spreadsheet automation right now!", "actionTitle": "Download", "actionLink": "http://download-me-quick.999.com" }, "tags": [ "Excel", "XLS" ],
Next you can add different sections and subsections, each with a title and a description, choose a layout, and select the itemType
such as Space, Component, Workflow, Node, Extension, or Collection. For each of these items you will need to provide the id
under which they are registered in your Business Hub installation.
The id
for workflows, spaces, components, and collections can be build by taking the last part of their URL, after the ~
, and adding a *
at the beginning.
For example, the following workflow on the KNIME Community Hub has URL https://hub.knime.com/-/spaces/-/latest/~1DCip3Jbxp7BWz0f/ so its id
would be *1DCip3Jbxp7BWz0f
.
The id
for node and extensions instead needs to be retrieved with a REST call, for example to the search
endpoint of your KNIME Business Hub instance.
"sections": [ { "title": "Workflow examples", "description": "Some subtitle text here. Can have <strong>bold format</strong>", "iconType": "Workflow", "subsections": [ { "title": "How to do basic spreadsheet tasks in KNIME", "description": "Some examples on how to do common things", "layout": "SingleColumn", "numberOfTeaseredItems": 2, "items": [ { "title": "Click Here!", "itemType": "Link", "absoluteUrl": "https://knime.com" }, { "id": "*SJW5zSkh1R3T-DB5", "itemType": "Space" }, { "id": "*vpE_LTbAOn96ZOg9", "itemType": "Component" }, { "id": "*MvnABULBO35AQcAR", "itemType": "Workflow" }, { "showDnD": true, "id": "*yiAvNQVn0sVwCwYo", "itemType": "Node" }, { "id": "*bjR3r1yWOznPIEXS", "itemType": "Extension" }, { "id": "*QY7INTkMW6iDj7uC", "itemType": "Collection" } ] } ] } ] }
Support Bundles and Troubleshooting
When generating a support bundle, no data leaves the cluster.
If necessary, you can download the support bundle and send it to KNIME for the purpose of troubleshooting. Under extreme circumstances, the KNIME team may forward the support bundle to the Replicated support team for additional help.
When generating a support bundle, a limited amount of information will be automatically redacted (IPv4 addresses, connection strings, etc.). You can configure additional redactions and/or manually redact information prior to sending the bundle. See the Configuring redaction in support bundles section for more details.
KNIME Business Hub is capable of generating support bundles in a standard format, even when the admin console isn’t working. This ensures that users are able to provide all of the necessary information for KNIME to be able to identify the problem and prescribe a solution.
Generating a support bundle (GUI)
In order to help troubleshoot an installation, or to simply inspect the logs of the cluster in a user-friendly format, you will need to generate a support bundle.
Simply open the KNIME Business Hub Admin Console, navigate to the Troubleshoot pane, and click the Generate a support bundle button to generate a support bundle.

All generated support bundles will display in the list above. Click the Download bundle button to download the bundle(s) you want to share with KNIME, and please see the Configuring redaction in support bundles section for information on how to redact confidential/personal information before sending.
Generating a support bundle (CLI)
See Replicated documentation for instructions on how to generate a support bundle via the Replicated CLI.
Configuring redaction in support bundles
When generating a support bundle, a limited amount of information will be automatically redacted (IPv4 addresses, connection strings, etc.) but it is not guaranteed to be a comprehensive set of redactions. You may have additional information in your logs or configuration that you do not wish to share with the KNIME engineering team.
One option is to unzip the generated .zip support bundle and manually review/redact information prior to sending the bundle to KNIME. However, there is a lot of information to review and the redaction of certain information can be automated fairly easily. The ideal option is to configure automated redactions via Redactor resources, which will automatically redact information for all future support bundles.
In order to configure automated redactors, first open the KNIME Business Hub Admin Console. Navigate to the Troubleshoot pane and click Configure Redaction.

If you have configured your own custom redactions that you feel would be valuable to other users of KNIME Business Hub, please feel encouraged to share the configuration with KNIME so that it can be considered & potentially added to future releases.
Inspecting support bundles
There are quite a number of of files generated in a support bundle. Not necessarily every file is useful for every problem. However, by collecting the same information in the same way each time, KNIME can ensure the best quality support possible for customers.
It is possible to inspect a support bundle entirely in the admin console. See below for an example screenshot.

Here are the most important folders/files and their purposes:
Path | Purpose | Example (may have properties omitted) |
---|---|---|
|
|
[ { "name": "kotsadm.status", "insight": { "name": "kotsadm.status", "primary": "kotsadm Status", "detail": "At least 1 replica of the Admin Console API is running and ready", "severity": "debug" }, "severity": "debug", "analyzerSpec": "" } ] |
|
|
(typical application logs) |
|
|
{ "kind": "PodList", "apiVersion": "v1", "metadata": { "resourceVersion": "1686941" }, "items": [ ... ] } |
Changelog (KNIME Business Hub 1.3.0)
KNIME Business Hub 1.3.0
(released April 03, 2023)
Important installation notes
-
With the release of KNIME Business Hub 1.3.0 new security features are introduced regarding executor communication. For this reason, KNIME Business Hub requires every executor to be on Analytics Platform version 4.7.1 or higher. You can find a list of the available executor images here.
-
With this release we changed the istio configuration of two services, to allow them to see the IP of the caller if the request is coming from within the cluster. This can cause those two services (
keycloak-proxy
,s3-proxy
) to not start up in some scenarios, with a "too many open files" error in the istio-proxy container of those pods. This can be fixed by increasing the open file limit on the host VM, e.g. by running the following command:
sudo sysctl fs.inotify.max_user_instances=8192
. -
The KOTS App Manager is now on version 1.96.3. This new version fixes an important bug, so it should be updated before updating to KNIME Business Hub version 1.3. To do so use the following command:
curl -sSL https://kurl.sh/knime-hub | sudo bash
. -
If you haven’t updated to KNIME Business Hub 1.2.0, yet, you need to follow update guide in the changelog for 1.2.0 before updating to 1.3.
New Features
Molecule sketcher
Use the new Molecule Widget (Labs) node to accept molecule input from your users. With this new node we made the integration of different sketchers easier and allowed to provide different
sketchers also for the KNIME Analytics Platform. In this release the ketcher sketcher is included. Additional sketchers will follow in the upcoming releases.
Collections
Introduce your users to a topic using collection pages. Collection pages serve as a starting point for your users to explore examples and building blocks related to your chosen topic,
facilitating their onboarding process.
To start creating collections read our guide here.
KNIME Analytics Platform customization profiles
Use Business Hub to distribute preference profiles to either local Analytics Platform clients or to KNIME Hub executors. This can be used to e.g. easily ship database drivers.
More information about Analytics Platform customization profiles here.
Trigger deployment
Trigger is a powerful new type of deployment which allows automating workflow execution based on specific conditions, such as another workflow or component being added or removed to a space.
To get started with Triggers, check out our documentation here.
Changelog (KNIME Business Hub 1.2.0)
KNIME Business Hub 1.2.0
(released March 13, 2023)
KNIME Business Hub 1.1.1 to 1.2.0 Upgrade
-
KNIME Business Hub 1.2.0 is expected to run in a Kubernetes 1.23.x cluster. Prior versions of KNIME Business Hub ran in Kubernetes 1.21.x clusters.
-
For embedded kurl cluster installations, the cluster update process is to:
-
First, check for updates in KOTS Admin Console.
-
Once the KNIME Business Hub 1.2.0 update has been identified and preflight checks have been run, trigger the deployment.
-
After the deployment process has completed, run the following command in the terminal of the host machine to upgrade the Kubernetes cluster version (among other components):
-
curl -sSL https://kurl.sh/knime-hub | sudo bash
-
You will have to enter
y
to various yes/no prompts during this upgrade process.
-
-
New Features
-
New supported Kubernetes versions: 1.22, 1.23, 1.24
-
Keycloak version updated to 19.0.3, see Keycloak documentation: https://www.keycloak.org/docs/19.0.3/server_admin/
-
Support for airgapped environments: Installing KNIME Business Hub in environments with no internet connection. Install instructions: https://docs.knime.com/latest/business_hub_installation_guide/index.html#_introduction
-
Embedded docker registry for custom executor images: Embedded cluster installations using kURL now contain an embedded docker registry for storing custom executor images. Documentation: https://docs.knime.com/latest/business_hub_installation_guide/index.html#embedded-docker-registry-configuration
-
Recreate strategy for Execution contexts: For upgrading execution contexts now rolling updates and recreate strategies are both available.
-
Support for custom certificate authorities
Bugfixes
-
Removed the unused ipv6 listener in the Business User Portal container, that could cause crashes in some environments