Documentation

Authorization

Telegraf Controller is in Public Beta

Telegraf Controller is in public beta and will be part of the future Telegraf Enterprise offering. While in beta, Telegraf Controller is not meant for production use. The Telegraf Controller documentation is a work in progress, and we are actively working to improve it. If you have any questions or suggestions, please submit an issue. We welcome any and all contributions.

Beta expectations

Provide beta feedback

Telegraf Controller uses session-based authentication for the web UI and token-based authentication for API and Telegraf agent requests. Both mechanisms work together to control who can access the system and what actions they can perform.

User roles

Telegraf Controller enforces a four-tier role hierarchy. Each role inherits the permissions of the roles below it, and higher roles unlock additional administrative capabilities.

RoleDescription
OwnerFull system access. Manages users, tokens, and settings. Only one owner exists at a time. Created during initial setup.
AdministratorFull system access. Same capabilities as the owner except cannot transfer ownership.
ManagerManages configurations, agents, labels, and reporting rules. Manages own API tokens. Cannot manage users or settings.
ViewerRead-only access to configurations, agents, labels, and reporting rules. Cannot manage tokens, users, or settings.

Only one owner can exist at a time. The owner account is created during initial setup and cannot be deleted. If you need to change the owner, the current owner must transfer ownership to another user.

To change the owner of your Telegraf Controller instance, see Transfer ownership.

API tokens

API tokens authenticate programmatic API requests and Telegraf agent connections to Telegraf Controller.

Each token is scoped to the user who created it. The token’s effective permissions are restricted to the creating user’s role—a token cannot exceed the permissions of its owner. If a user’s role changes to a role with less permissions, all of that user’s existing tokens are automatically updated with restricted permissions or revoked to match the new role.

Tokens use the tc-apiv1_ prefix, making them easy to identify in configuration files and scripts.

A token value is shown only once at the time of creation. Store it in a secure location immediately—you cannot retrieve it later.

Endpoint authentication

By default, Telegraf Controller requires authentication for API endpoints. Administrators can selectively require authentication for individual endpoint groups:

  • Agents — agent management endpoints
  • Configs — configuration management endpoints
  • Labels — label management endpoints
  • Reporting rules — reporting rule management endpoints
  • Heartbeat — agent heartbeat endpoints

When authentication is enabled for an endpoint group, every request to that group must include a valid API token or an active session.

To configure which endpoint groups require authentication, see Manage settings.


Was this page helpful?

Thank you for your feedback!


Telegraf Enterprise now in public beta

Get early access to the Telegraf Controller and provide feedback to help shape the future of Telegraf Enterprise.

See the Blog Post

The upcoming Telegraf Enterprise offering is for organizations running Telegraf at scale and is comprised of two key components:

  • Telegraf Controller: A control plane (UI + API) that centralizes Telegraf configuration management and agent health visibility.
  • Telegraf Enterprise Support: Official support for Telegraf Controller and Telegraf plugins.

Join the Telegraf Enterprise beta to get early access to the Telegraf Controller and provide feedback to help shape the future of Telegraf Enterprise.

For more information:

New in InfluxDB 3.8

Key enhancements in InfluxDB 3.8 and the InfluxDB 3 Explorer 1.6.

See the Blog Post

InfluxDB 3.8 is now available for both Core and Enterprise, alongside the 1.6 release of the InfluxDB 3 Explorer UI. This release is focused on operational maturity and making InfluxDB easier to deploy, manage, and run reliably in production.

For more information, check out:

InfluxDB Docker latest tag changing to InfluxDB 3 Core

On May 27, 2026, the latest tag for InfluxDB Docker images will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments.

If using Docker to install and run InfluxDB, the latest tag will point to InfluxDB 3 Core. To avoid unexpected upgrades, use specific version tags in your Docker deployments. For example, if using Docker to run InfluxDB v2, replace the latest version tag with a specific version tag in your Docker pull command–for example:

docker pull influxdb:2