The architectural evolution of Grafana has reached a critical inflection point with the definitive removal of AngularJS support. For years, the observability ecosystem has been transitioning from the legacy AngularJS v1 framework—a JavaScript-based frontend framework that saw its active development lifecycle conclude years ago—toward a modern, robust, and highly perform-ant React-based architecture. This transition is not merely a cosmetic upgrade but a fundamental shift in how plugins are developed, maintained, and scaled within the Grafana ecosystem. The decision by Grafana Labs to pivot toward React was driven by the framework's superior feature set and its massive popularity within the global developer community, which was essential for fostering an open-source environment capable of expanding Grafana's visualization capabilities.
As the industry moves toward Grafana v12, the implications for administrators, DevOps engineers, and data engineers are profound. The deprecation process has been a multi-year endeavor, beginning formally in Grafana v9, followed by a period of "soft" deprecation in Grafana v11 where support was disabled by default. However, with the arrival of v12, the "safety net" of the angular_support_enabled=true configuration toggle is being dismantled. This removal signifies the end of an era for legacy plugins and necessitates a proactive migration strategy for any organization relying on custom or community-driven AngularJS-based panels and data sources.
The Chronology of Deprecation and Migration
The journey from AngularJS to React has been a structured, multi-phase rollout designed to minimize catastrophic failures in production environments. Understanding this timeline is vital for predicting the impact on existing observability stacks.
The initial stages of this transition began as far back as 201-era Grafana v5, where the migration of core components was first initiated. By Grafana v6, the platform had officially introduced a React-based foundation for plugin development. The formal deprecation of AngularJS support was announced in Grafana v9. While the original roadmap intended for removal in Grafana v10, the complexity of the ecosystem forced a strategic delay. This delay allowed users more time to identify dependencies and plan migrations, preventing the sudden breakage of critical dashboards.
The transition progressed into Grafana v11, which entered preview in April 2025 and reached general availability in May 2025. In this version, the engineering team implemented a "disabled by default" policy. This meant that for both on-premise (OSS and Enterprise) and Grafana Cloud instances, any plugin relying on AngularJS would fail to load automatically. However, a critical escape hatch remained: self-managed users could manually re-enable the legacy engine using the configuration parameter angular_support_enabled=true.
With the release of Grafana v12, scheduled for early May 202 and with Grafana Cloud instances receiving the update in April 2026, the final step is being executed. The support for AngularJS is being entirely removed from all instances, including OSS, Enterprise, and Cloud. This means the configuration toggle itself is being deleted from the codebase, making it impossible to revive legacy plugins through configuration.
| Grafana Version | AngularJS Support Status | Impact on Users |
|---|---|---|
| Grafana v5 - v8 | Active Support | Full functionality of all AngularJS plugins. |
| Grafana v9 | Formal Deprecation | Warning messages and deprecation notices introduced. |
| Grafana v10 | Continued Support | Extension of support period to allow for migration planning. |
| Grafana v11 | Disabled by Default | Plugins fail to load unless angular_support_enabled=true is set. |
| Grafana v12 | Complete Removal | Total removal of the engine; no possibility of re-enabling. |
Technical Implications for Plugins and Dashboards
The removal of AngularJS is not a silent event; it is a transformative process that affects both the plugin layer and the dashboard JSON structure. When a plugin is removed from the runtime environment, the consequences ripple through the entire observability stack.
For plugins that were built on the legacy framework, the impact is binary: they either cease to function or are forced into a migration path. In instances where a "core" Angular panel is used within a dashboard, Grafana v12 will attempt a force-migration to the latest React-based versions. This is a critical distinction, as it aims to preserve the visual integrity of the dashboard even when the underlying engine changes.
However, for third-party or private plugins that do not have a React-based successor, the dashboard will experience a functional breakdown. The data source may become unreachable, or the visualization may simply fail to render. To mitigate this, the Grafana documentation provides a comprehensive registry of every plugin that has ever had an AngularJS dependency. This registry serves as a migration map, providing:
- The minimum required plugin version to upgrade to a React-compatible version.
- Specific migration advice for complex configurations.
- A list of alternative plugins that provide similar or enhanced functionality.
For developers, the emergence of the new Scenes framework and the create-plugin tool represents the future of the ecosystem. These tools are designed to simplify the development and maintenance of React-based plugins, ensuring that the community can continue to innovate without the technical debt of the legacy framework.
Automated Detection via detect-angular-dashboards
One of the greatest challenges in a large-scale deployment is the identification of "hidden" dependencies, particularly when dealing with private plugins that are not part of the official Grafiana plugin catalog. To address this, the detect-angular-dashboards utility was developed. This open-source tool allows administrators to programmatically query a running Grafana instance to identify every dashboard that relies on AngularJS-dependent plugins or data sources.
The utility is compatible with Grafana OSS, Enterprise, On-Prem, and Grafana Cloud. It functions by interacting with the Grafana API to inspect the JSON definitions of all existing dashboards.
Requirements and Configuration
To ensure the tool operates with sufficient visibility, specific permissions must be configured within the Grafana instance. The tool's ability to detect plugins is heavily dependent on the permissions of the service account used for authentication.
- Service Account Role: A service account must be created with at least the
Viewerrole for general dashboard scanning. - Plugin Visibility: To detect "private" plugins (those not in the official catalog), the service account requires
Plugins / Plugin Maintainerpermissions. In an OSS environment without Role-Based Access Control (RBAC), anAdminrole is necessary because the/api/pluginsendpoint only returns the full list of available plugins if the token has permission to view and install them. - Environment Variable: The authentication token must be exported to the
GRAFANA_TOKENenvironment variable.
Operational Modes
The detect-angular-dashboards binary provides two distinct modes of operation to suit different administrative needs:
- CLI Mode: This is an on-demand execution mode. It is used for one-off scans, typically during a maintenance window or prior to a planned upgrade to Grafana v12. The administrator runs the command, and the tool outputs the findings immediately to the console or a file.
- Server Mode: This mode is designed for continuous monitoring. It periodically queries the Grafana instance to track the current set of dashboards. It exposes a
/detectionsendpoint that returns a JSON response containing the list of all identified AngularJS dependencies.
Execution Example
A typical execution of the CLI mode, including the redirection of output to a JSON file for later analysis, would look like this:
bash
export GRAFANA_TOKEN=glsa_aaaaaaaaaaa
./detect-angular-dashboards http://my-grafana.example.com/api | tee output.json
When the tool runs, the output structure follows a specific schema, identifying the PluginID, the DetectionType (whether it is a datasource or a panel), and the Title of the affected dashboard.
json
[
{
"Detections": [
{
"PluginID": "akumuli-datasource",
"DetectionType": "datasource",
"Title": "Panel two"
},
{
"PluginID": "grafana-world-map-panel",
"DetectionType": "panel",
"Title": "Angular"
}
],
"URL": "http://my-grafana.example.com/d/ef5e2c21-88aa-4619-a5db-786cc1dd37a9/angular",
"Title": "Global Infrastructure Overview"
}
]
Version Constraints for Detection
It is critical to note that the effectiveness of the detection tool is subject to the version of the Grafana instance being scanned. For administrators running versions of Grafana lower than 10.1.0, there is a significant risk that private plugins—those that are not part of the official Grafana catalog—will not be detected during the scan. Therefore, it is highly recommended to upgrade to at least Grafana 10.1.0 before performing a final audit for the v12 migration.
Strategic Migration and Infrastructure Planning
The removal of AngularJS is a high-stakes event for any organization utilizing Grafana for mission-critical observability. A failure to identify and migrate dependencies will lead to broken dashboards and lost visibility into infrastructure health. The transition requires a structured, multi-step approach.
The first phase of the strategy must involve an audit. Using the detect-angular-dashboards tool, administrators should generate a comprehensive list of all vulnerable dashboards. This audit should be performed against the GRAFANA_TOKEN with sufficient permissions to capture private plugins.
The second phase is the evaluation of identified dependencies. For every plugin flagged, the administrator must check the Grafana documentation to see if a React-based replacement exists. If a replacement is available, the migration plan should include updating the plugin and verifying the dashboard's configuration. If the plugin is a data source, the dashboard.json may need manual editing to point to a new, supported data source.
The third phase is the implementation of testing. Before deploying Grafana v12 to production, a staging environment must be used to run the new version against the identified dashboards. This allows for the detection of any unforeseen breakages in the "force-migration" process of core panels.
The final phase is the decommissioning of the legacy configuration. Once all dashboards are verified as functional on the React-based architecture, the angular_support_enabled parameter should be removed from all configuration files, and the upgrade to v12 can proceed with confidence.
Analysis of the Architectural Shift
The decommissioning of AngularJS represents more than just a technical cleanup; it is a strategic move to ensure the long-term sustainability of the Grafana platform. The reliance on a legacy framework like AngularJS v1 introduces significant risks, including security vulnerabilities that are no longer patched and a shrinking pool of developers capable of maintaining the ecosystem.
By enforcing a transition to React, Grafana Labs is effectively future-proofing the platform. The move to the Scenes framework and the implementation of modern plugin development tools like create-plugin ensures that the complexity of the frontend does not become a bottleneck for innovation. While the removal of support causes short-term friction and necessitates significant labor for administrators, the long-term benefits—including improved performance, enhanced security, and a more robust plugin ecosystem—are indispensable for the modern era of observability. The industry is moving toward a more unified, high-performance standard, and the removal of AngularJS is the necessary catalyst for that progress.