Tarantool CE/EE Documentation portal logo
Support
Updated at September 15, 2026   08:55 AM

Tarantool Cluster Manager 1.11

Release date: September 15, 2026

Latest release in the series: 1.11.0

In TCM 1.11.0, initial setup capabilities have been extended — you can now create users with multiple secrets, including token-type secrets, already at the bootstrap stage. File-level protection of cluster configuration (Key ACL) has been added, along with per-cluster configuration signing and support for creating static TCM clusters from a ready-made YAML configuration — both via configuration and via the Web UI. Configuration export capabilities have been extended: a /api/config/export handler, a TCM configuration page, and a tcm config export CLI command have appeared. Audit logs and syslog output have been switched to the RFC 5424 format, and authentication method management has been moved to a separate administrative section. In addition, support for a new storage role has been added on the TQE page, and addon support has been discontinued. The release also includes a number of fixes in the Stateboard, TQE, migrations, workers, and storage areas.

Users with multiple secrets at bootstrap

You can now create a user with multiple secrets right at TCM's first startup, via the initial-settings field in the configuration, specifying a description for each secret using the secret-description field or the --secret-description CLI flag of the ./tcm user add command. Support for token-type secrets has also been added — both via the ./tcm user add CLI command and via initial-settings.

New way to create users with a large number of secrets:

- fullname: Administrator    id: 22200000-0000-0000-0000-000000000003    description: "System administrator"    secrets:      - public-key: alice-public-key-2024        secret-type: password        secret-key: SecurePassword123!@#        secret-description: Alice's password      - secret-type: ldap        public-key: alice-ldap-key-2024        secret-description: Alice's ldap    role-ids:      - 20000000-0000-0000-0000-000000000001    clusters:      - 20000000-0000-0000-0000-000000000001:cluster.stateboard.read:true      - 20000000-0000-0000-0000-000000000002:cluster.stateboard.read:true      - 20000000-0000-0000-0000-000000000003:cluster.stateboard.read:true

File-level access control for cluster configuration

Added Key ACL — the ability to restrict access to individual cluster configuration files for each user, with separate read and write permissions. Key ACL is enabled independently of the regular ACL for spaces/funcs: the Use Key Access Control List (Key ACL) toggle is located next to the existing Use ACL switch when assigning a cluster to a user.

Once enabled, in the Clusters → ACL section, when creating an entry, select the Key type using the Space / Func / Key switch — specify the user, cluster, file name, and the required permissions. For the Key type, the Name field is replaced with File name, and the Execute checkbox is unavailable.

How it works:

  • Files without an explicit ACL entry are inaccessible for both reading and writing. Creating new configuration files is also unavailable.
  • You can create an entry with a wildcard file name * — it applies to all files without an exact match.
  • Files without read permission are not shown in the list.
  • Files without write permission open in read-only mode.

Configuration signing and static clusters

Added the ability to specify configuration signing separately for each cluster (the security.integrity-check and security.signature-private-key-file options in initial-settings.clusters when creating a cluster via TCM configuration, or in the UI when editing a cluster), allowing each cluster to use its own key and operate in mixed environments with integrity checking either enabled or disabled. The TCM configuration itself now uses a separate signing key. Security has been improved — TCM is now immediately locked if integrity checking is enabled (security.integrity-check: true) and signature verification fails.

Also added integrity monitoring for all protected data storages: the system automatically verifies digital signatures on any data change and blocks access when integrity violations are detected.

A static provider configuration has appeared, allowing you to create a TCM cluster based on a provided YAML configuration. The capabilities of such a cluster are limited: the user cannot change the configuration in the Web UI, configuration changes are not tracked, applying and fetching migrations are unavailable, and the cluster is always shown as successfully migrated. In the cluster creation and editing wizard, a from configuration provider option with a code editor has been added for this — static clusters can now be created and edited in the UI just like other storage types.

Configuration export

TCM now has the ability to export configuration. The exported configuration now begins with a warning comment listing the removed credentials and fields that need to be filled in before using the configuration. The list of hidden fields has also been expanded — storage usernames and passwords, cluster usernames, security.bootstrap-password, security.bootstrap-api-token, and test.login-credentials are now replaced with placeholders, while security.encryption-key, security.encryption-key-file, and security.signature-private-key-file are fully excluded from the exported file. The ability to export configuration from storage has appeared — this export was not previously supported; if the Tarantool version does not allow this, an informative message is displayed telling you to upgrade it.

Exporting configuration with hidden user passwords is now possible not only via the CLI but also via the Web UI: a handler for exporting configuration at the /api/config/export path has been added, and the Tools section now has a TCM configuration page that lets you export the TCM configuration via the UI.

Flags of the tcm config export CLI command:

  • --output, -o: path to the configuration file; defaults to stdout.

RFC 5424 in audit and logging

The audit log protocol now generates records in the RFC 5424 format instead of the previous CEE-prefixed JSON payload. Both datagram and stream transport are supported — in stream mode, each frame ends with a newline character per RFC 6587. Log output records via syslog are now also generated in the same RFC 5424 format.

Authentication method management

Authentication method management has been moved out of user settings into a separate administrative interface — the SettingsAuthentication Methods section with an improved UI/UX. Access is now restricted to administrators with the admin.users.write permission, which provides clearer separation of responsibilities and strengthens security control.

New TQE storage role

Added support for a new TQE role — roles.tqe-storage.

Stateboard updates

Stateboard now has a ring chart of module versions, which shows the versions of each module across instances and highlights with a warning those whose versions diverge. The module segment on the chart and the icon in its center are colored yellow if the module is represented by different versions on different instances or is missing on at least one of them; hovering over the chart opens a table listing the modules and their versions, where missing versions are marked as missing, and rows with a discrepancy are also highlighted. In addition, instance boxes in the list are colored yellow when a module version discrepancy is detected, and green when everything is consistent. Version mismatches are determined across the entire cluster.

In addition, a rebalancer icon and a search feature have been added to the Web UI — this makes it easy for users to find rebalancer nodes in large clusters using the is:rebalancer filter.

Nested configuration paths and mandatory IDs

Added support for creating cluster configuration files at nested paths (for example, /cluster/config/creds). The initial-settings configuration now requires IDs for users, roles, and ACL entries.

addon support discontinued

addon support has been discontinued — addon initialization no longer performs any actions.

Fixed

  • A user password validation error at bootstrap, caused by the password policy being applied only after the user was created.
  • A password policy validation error when creating and updating user secrets.
  • A connection error for a TLS cluster where the password is stored in a file — configuration with a password file is now handled correctly.
  • Warnings that occurred after clicking the Start All Tarantool button: the StartAllTarantool resolver no longer closes connections taken from the cluster pool.
  • Codec cache synchronization issues when updating cluster integrity parameters.
  • An error that could cause cluster configurations to be returned in a different order.
  • An error on the TQE metrics page that prevented the corresponding chart from being displayed when a metric was selected.
  • An error when fetching cluster metrics if any configuration was in draft state.
  • An error that prevented the migration list from updating when switching to a disabled cluster.
  • An error that showed a success notification when one migration applied successfully and another failed; the user now also sees a message that subsequent migrations cannot be applied until the failed ones are fixed.
  • Warnings that occurred with etcd authentication enabled: the worker prefix could be missing from the configuration, causing requests to be sent to the normally forbidden etcd root.
  • An error that caused system spaces to appear in Stateboard bucket statistics; sorting of instances and spaces has also been added.
  • An error where the response itself disappeared when the response panel was reopened.