Skip to content

Platform Command Line Interface

The Tenzir Platform Command-Line Interface (CLI) allows users to interact with the Tenzir Platform from the command line to manage workspaces and nodes.

Install the tenzir-platform package from PyPI.

pip install tenzir-platform
tenzir-platform auth login
tenzir-platform workspace list
tenzir-platform workspace select <workspace_id>

The tenzir-platform auth login command authenticates you with the platform.

The tenzir-platform workspace list command shows all workspaces available to you. The tenzir-platform workspace select command selects a workspace for subsequent operations.

The unique ID of the workspace, as shown in tenzir-platform workspace list.

tenzir-platform node list
tenzir-platform node ping <node_id>
tenzir-platform node create [--name <node_name>]
tenzir-platform node delete <node_id>
tenzir-platform node run [--name <node_name>] [--image <container_image>]

The following commands interact with the selected workspace:

  • tenzir-platform node list lists all nodes in the selected workspace, including their ID, name, and connection status.
  • tenzir-platform node ping pings the specified node.
  • tenzir-platform node create registers a new node at the platform. This command creates a new API key that a node can use to connect to the platform. It does not start or configure a node.
  • tenzir-platform node delete removes a node from the platform. This command does not stop the node; it only removes it from the platform.
  • tenzir-platform node run creates and registers an ad-hoc node, then starts it on the local host. This command requires Docker Compose. The platform deletes the temporary node when you stop the run command.

The unique ID of the node, as shown in tenzir-platform node list.

The name of the node as shown in the app.

The Docker image to use for the ad-hoc created node. We recommend using one of the following images:

  • tenzir/tenzir:latest to use the latest release.
  • tenzir/tenzir:main to use the current development version.
  • tenzir/tenzir:v5 to pin to a major release.
  • tenzir/tenzir:v5.1 to pin to a minor release.
  • tenzir/tenzir:v5.1.3 to use a specific release.

The Tenzir Platform provides secret storage that pipelines running on a Tenzir Node can access.

tenzir-platform secret add <name> [--file=<file>] [--value=<value>] [--env]
tenzir-platform secret update <secret_id> [--file=<file>] [--value=<value>] [--env]
tenzir-platform secret delete <secret_id>
tenzir-platform secret list [--json]

The following commands manage secrets in the Tenzir Platform:

  • tenzir-platform secret add adds a new secret to the platform. You can provide the secret value directly via the --value option, read it from a file using the --file option, or source it from an environment variable using the --env flag. The platform identifies the secret by the provided <name>.

  • tenzir-platform secret update updates an existing secret identified by <secret_id>. Like adding a secret, you can provide the new value via --value, --file, or --env.

  • tenzir-platform secret delete removes a secret from the platform. The command identifies the secret to delete by its <secret_id>.

  • tenzir-platform secret list lists all secrets available in the platform. Use the --json flag to output the list in JSON format for easier integration with other tools.

The unique name to identify the secret. Pipelines use this name when accessing the secret.

The unique identifier of the secret, as shown in the output of tenzir-platform secret list.

Specifies a file containing the secret value. The platform securely stores the file’s contents as the secret value.

Specifies the secret value directly as a command-line argument.

Indicates that the command should source the secret value from an environment variable. You must set the environment variable before running the command.

Outputs the list of secrets in JSON format when used with the tenzir-platform secret list command.

Users can configure workspaces to use external secret stores instead of the Tenzir Platform’s built-in secret store.

Currently, the platform only supports AWS Secrets Manager as an external store.

By default, the platform mounts external secret stores as read-only. You cannot add or update secrets from the CLI or web interface. Some external secret store implementations may offer write access options.

tenzir-platform secret store add aws
--region=<region>
--assumed-role-arn=<assumed_role_arn>
[--name=<name>]
[--prefix=<prefix>]
[--access-key-id=<key_id>]
[--secret-access-key=<key>]
tenzir-platform secret store set-default <store_id>
tenzir-platform secret store delete <store_id>
tenzir-platform secret store list [--json]

When a node accesses a secret using the secret("foo") function in a pipeline, the platform looks up the secret named foo in the workspace’s default secret store and returns the value to the node.

When using an external secret store, the platform needs the necessary permissions to read secret values from that store.

For AWS Secrets Manager, the Tenzir Platform uses AWS Security Token Service (STS) to assume a role with the necessary permissions. You must create this role and configure one of the following options:

  1. Create an IAM user. Download access keys and pass them via the --access-key-id and --secret-access-key arguments. This approach is the easiest to set up but only acceptable for self-hosted testing or development instances of the Tenzir Platform because it stores long-term credentials in the Tenzir Platform.

  2. Assign the permissions to the task role of the websocket gateway. We recommend this option for users running the Sovereign Edition of the Platform and deploying it to their own AWS account.

  3. Assign the permission to assume the configured role to Tenzir’s AWS account with the ID 660178929208. This option only works with our publicly hosted platform instance on https://app.tenzir.com.

We plan to add an OIDC-based option as an alternative to options (1) and (3).

tenzir-platform alert add <node> <duration> <webhook_url> [<webhook_body>]
tenzir-platform alert delete <alert_id>
tenzir-platform alert list

The following commands set up alerts for specific nodes. When a node remains disconnected for the configured duration, an alert triggers by sending a POST request to the configured webhook URL.

The node to monitor. You can provide either a node ID or a node name, as long as the name is unambiguous.

The amount of time to wait between the node disconnect and triggering the alert.

The platform sends a POST request to this URL when the alert triggers.

The body to send with the webhook. Must be valid JSON. The body may contain $NODE_NAME, which the platform replaces with the name of the node that triggered the alert.

Defaults to {"text": "Node $NODE_NAME disconnected for more than {duration}s"}, where the platform sets $NODE_NAME and {duration} dynamically from the CLI parameters.

Given nodes like this:

$ tenzir-platform node list
🟢 Node-1 (n-w2tjezz3)
🟢 Node-2 (n-kzw21299)
🔴 Node-3 (n-ie2tdgca)

We want to receive a Slack notification whenever Node-3 is offline for more than 3 minutes. First, we create a webhook as described in the Slack docs. Next, we configure the alert in the Tenzir Platform:

tenzir-platform alert add Node-3 3m "https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ" '{"text": "Alert! Look after node $NODE_NAME"}'

If Node-3 doesn’t reconnect within 3 minutes, a message appears in the configured Slack channel.

These CLI commands are only available to local platform administrators. The TENZIR_PLATFORM_OIDC_ADMIN_RULES variable defines who is an administrator in your platform deployment.

tenzir-platform admin list-global-workspaces
tenzir-platform admin create-workspace <owner_namespace> <owner_id> [--name <workspace_name>]
tenzir-platform admin delete-workspace <workspace_id>

The tenzir-platform admin list-global-workspaces, tenzir-platform admin create-workspace, and tenzir-platform admin delete-workspace commands list, create, or delete workspaces, respectively.

Either user or organization, depending on whether the workspace associates with a user or an organization.

The selected namespace determines the default access rules for the workspace:

  • For a user workspace, the platform creates a single access rule that allows access to the user whose user ID matches the given owner_id.
  • For an organization workspace, the platform creates no rules by default. You must manually add them using the add-auth-rule subcommand described below.

The unique ID of the workspace owner:

  • If <owner_namespace> is user, this matches the user’s sub claim in the OIDC token.
  • If <owner_namespace> is organization, this is an arbitrary string that uniquely identifies the organization the workspace belongs to.

The name of the workspace as shown in the app.

The unique ID of the workspace, as shown in tenzir-platform workspace list or tenzir-platform admin list-global-workspaces.

These CLI commands are only available to local platform administrators. The TENZIR_PLATFORM_OIDC_ADMIN_RULES variable defines who is an administrator in your platform deployment.

tenzir-platform admin list-auth-rules <workspace_id>
tenzir-platform admin add-auth-rule allow-all <workspace_id>
tenzir-platform admin add-auth-rule user <workspace_id> <user_id>
tenzir-platform admin add-auth-rule
email-domain <workspace_id> <connection> <domain>
tenzir-platform admin add-auth-rule
organization-membership <workspace_id> <connection> <organization_claim> <organization>
tenzir-platform admin add-auth-rule
organization-role <workspace_id> <connection> <roles_claim> <role> <organization_claim> <organization>
tenzir-platform admin delete-auth-rule <workspace_id> <auth_rule_index>

Users with admin permissions can use the tenzir-platform admin list-auth-rules, tenzir-platform admin add-auth-rule, and tenzir-platform admin delete-auth-rule commands to list, create, or delete authentication rules for all users, respectively.

Authentication rules allow users to access the workspace with the provided <workspace_id> if the user’s id_token matches the configured rule. Users gain access to a workspace if any configured rule allows access. The following rules exist:

  • Email Suffix Rule: tenzir-platform admin add-auth-rule email-domain allows access if the id_token contains a connection field that exactly matches the provided <connection> and an email field that ends with the configured <domain>.

  • Organization Membership: tenzir-platform admin add-auth-rule organization-membership allows access if the id_token contains a connection field that exactly matches the provided <connection> and an <organization_claim> field that exactly matches the provided <organization>.

    Note that you can freely choose the <organization_claim> and <organization>, so you can also repurpose this rule for generic claims that are not necessarily related to organizations.

  • Organization Role Rule: tenzir-platform admin add-auth-rule organization-role allows access if the id_token contains a connection field that exactly matches the provided <connection>, an <organization_claim> field that exactly matches the provided <organization>, and a <roles_claim> field that must be a list containing a value exactly matching <role>.

    We recommend using organization role rules to check if a user has a specific role with an organization.

  • User Rule: tenzir-platform admin add-auth-rule user allows access if the id_token contains a sub field that exactly matches the provided <user_id>.

  • Allow All Rule: tenzir-platform admin add-auth-rule allow-all allows access to every user. Use this rule to set up a workspace that all users of a platform instance can access.

Last updated: