KNIME Documentation

Adapt local workflows for Knime ​

In Knime, workflows live in the cloud: you edit and run them in your browser, on Knime-managed infrastructure. A workflow built on a local Knime Analytics Platform installation can therefore behave differently. File paths, credentials, extensions, database drivers, and Python environments are often specific to your machine and don't carry over automatically. This guide explains how to import local work and what to adjust so it runs correctly on Knime.

Import from local Knime Analytics Platform ​

Import local files to an empty space in your team. This supports single workflows, data, components, folders ot the entire workspace.

  1. Create a new space.
  2. Select Import workspace.
  3. Drag and drop the files and folders from your local workspace.

Editing workflows in the browser ​

Knime in the cloud works independently from Knime Analytics Platform. Workflows do not live in your local machine anymore, but are created and edited directly in the browser. This has the advantage that all executions happen on a Knime managed environment, and you do not need to allocate any local resources or install any local software.

Note

Editing workflows in Knime requires an active internet connection. Your progress is saved automatically.

Workflows in the cloud are also bounded to an environment and a compute class, and consume execution credits when nodes are executed. See the guide to optimize credit consumption.

File handling ​

Local workflows often reference files with an absolute path or a path relative to a Knime Analytics Platform mountpoint. Neither resolves on Knime on the cloud.

Replace local file references with one of the following:

  • A path relative to the workflow's data area, so the file travels with the workflow.
  • A path relative to the workfow space or another space on Knime. You can upload and read files directly from your local file system
  • A connector node for the storage service that holds the file, for example an Amazon S3 Connector or Azure Blob Storage Connector, if the file is hosted on an external file system.

Learn more in the File handling guide.

Connecting Knime to on-premise services ​

Connector nodes for databases, SSH servers, or other on-premises services need a network path from Knime to that service. A connection that works from your local machine, for example over a corporate VPN, doesn't necessarily work from Knime.

If the data is not meant to leave your network, you need to setup sovereign execution.

Call other workflows ​

Workflows that call other workflows usually reference them by a local path, for example a path relative to a Knime Analytics Platform mountpoint. That path doesn't resolve on Knime.

The following nodes call other workflows:

  • Call Workflow Service
  • Call Workflow (Table Based)
  • Call Workflow (Row Based)

To make workflow calling work on Knime:

  1. Import the callee workflows together with the workflow that calls them. See Import from local Knime Analytics Platform.
  2. In each calling node, update the path to point to the called workflow in its space. Use a path relative to the current space, so the call keeps working if the space is copied.

Alternatively, turn the callee workflow into a service deployment and call its endpoint. This way the caller workflow doesn't depend on where the callee workflow is stored.

Credentials and secrets ​

Credentials Configuration nodes and hardcoded usernames or passwords work locally but don't transfer safely to Knime: they are stored with the workflow and visible to anyone with access to the space.

Replace them with a Secrets Retriever node connected to a Secret created on Knime:

  1. Create a Personal, Team, or Admin secret with the same credential type. See Create a secret.
  2. Add a Secrets Retriever node to the workflow.
  3. Select the secret in the node's configuration dialog.
  4. Connect the output port to the node that previously used the hardcoded credential or Credentials Configuration node.

Secrets aren't limited to storing a username and password. They can also hold the login for a specific service, such as Google Drive or Databricks. In these cases, replace the connector's Authenticator node — for example the Google Authenticator — with a Secrets Retriever node instead. See Connect to a file system for examples per service.

Extensions availability ​

Workflow editing and execution on Knime run inside an execution environment. An environment is tied to a Knime version and a predefined set of extensions, managed by Knime.

Before uploading a workflow built locally to Knime:

  • Check whether every extension the workflow depends on is available in the default environment.
  • Replace deprecated or legacy nodes where possible. They can behave differently, or not be available, across environments.

Unlike a local installation, you can't install additional extensions into a managed environment yourself. If your workflow needs extensions outside the default environment, choose one of the following:

  • Register a sovereign executor, set up with the extensions you need.
  • Contact your Knime account manager to request them.

Database drivers ​

Locally, you register a JDBC driver in File → Preferences → KNIME → Databases. This registration is specific to your machine and doesn't transfer with the workflow.

In Knime, database drivers are associated with an execution environment. Admins can upload the necessary drivers when creating a new execution environment. See guide to create an execution environment.

Python environments ​

A local Python installation, and any Conda or virtual environments you configured in File → Preferences → KNIME → Python, are specific to your machine.

On Knime, a workflow using Python nodes can rely on:

  • The bundled Python environment that ships with the Knime Python integration, when the workflow's packages are covered by it.
  • The Python Environment Provider node to define, create and propagate environments within your workflow. See Python Environment Management.