Grafana data-source plugins may ship a backend component or be frontend-only. What does the backend component do, and which Grafana capabilities stop working when a data source does not have one?
answer
- frontend-only = browser builds request, server proxy forwards it
- backend = separate binary, RPC, QueryData + health + resources
- no browser ⇒ backend required (alerting, caching, reports, streaming)
- plugin manifest declares backend/alerting capability
- signing policy: backend plugins run server-side code
basics
~20 sA frontend-only plugin builds the request in the browser and Grafana's proxy forwards it. A backend plugin runs as a server-side process that executes queries without a browser — required for anything evaluated headlessly: alert-rule evaluation, caching, snapshots-without-a-viewer and streaming.
solid answer
~50 sA **frontend-only** data-source plugin is browser code: it renders the query editor and constructs the request, and Grafana's data-source proxy forwards that request server-side, injecting the stored credentials. It works fine for interactive dashboards. A **backend** plugin additionally ships a server-side binary that Grafana launches as a child process and speaks to over a local RPC channel. It implements query execution, a health check, and optionally resource endpoints and streaming. Grafana declares this capability in the plugin's metadata (`backend: true`, and `alerting: true` for rule evaluation). The distinction matters because anything Grafana must do **without a browser open** requires the backend path: unified alert-rule evaluation on the server's schedule, query caching and recorded/precomputed queries, server-rendered reports and dashboards shared without a viewer session, and live streaming. It also gives cleaner secret handling and plugin-owned request logic. So when picking a community data-source plugin, "does it have a backend, and is it signed?" is a deployment question, not a detail.
go deeper
Know that some data sources have a server-side component and some are browser code proxied by Grafana, and that alerting needs the server-side one.
Explain the RPC-managed child process, the declared capabilities in the plugin manifest, and the list of features that require headless execution.
Add the operational and supply-chain angles: independent failure of plugin processes, signing policy, architecture-specific binaries, version coupling.
Decide plugin policy for a shared platform — which third-party backends are permitted, how they are reviewed and updated, and what the blast radius is when one runs beside every stored credential.
## Two plugin shapes Grafana's data-source plugin API has evolved to support two shapes, and a given plugin may be either. **Frontend-only plugin.** Everything is browser code. The plugin supplies the configuration form and the query editor, and when a panel runs it constructs an HTTP request. That request does not go straight out: it goes to Grafana's **data-source proxy**, a server-side route that looks up the data source, injects the configured authentication (basic auth, bearer token, custom headers, TLS client certificate) and forwards it. The proxy exists exactly so that credentials never have to be handed to the browser. **Backend plugin.** In addition to the frontend bundle, the plugin ships an executable that Grafana starts as a managed child process and communicates with over a local RPC channel. The backend implements a small interface: execute a set of queries for a time range and return data frames; report health for the "Save & test" button; optionally expose resource endpoints (used by query editors to fetch label names, table lists, autocompletion data) and streaming channels. The plugin's manifest declares its capabilities, and Grafana's UI and alerting layer consult those declarations — a plugin without the alerting capability simply cannot be selected in an alert rule. ## What the backend unlocks, and why The unifying principle: **a browser is not always available.** Any Grafana feature that must execute a query outside an interactive dashboard session needs code that can run on the server. - **Alert-rule evaluation.** Rules are evaluated by the server on a schedule, day and night, with no browser anywhere. A frontend-only data source has no code path the scheduler can call, so it cannot back an alert rule. - **Query caching.** Caching sits in front of server-side execution; if the request is assembled in the browser and merely proxied, there is no normalised query object to key a cache on. - **Precomputed / recorded queries.** Same reason: a server-side scheduler must be able to run the query itself. - **Server-side rendering and headless sharing.** Reports, scheduled PDFs and dashboards shared with viewers who have no session require the server to produce data without an interactive user. - **Streaming and live data.** Push-style channels are a server capability. - **Better secret and connection handling.** A backend can hold pooled connections, use SDKs that were never designed for a browser (native database drivers, cloud provider SDKs with signing), and keep secrets entirely in process. ## Operational consequences **Process management.** Backend plugins are separate OS processes supervised by Grafana. They can crash, leak memory or be starved of CPU independently, and they appear as child processes in your container. A misbehaving third-party backend plugin is a real availability risk in a shared Grafana, and plugin-level logging is where you look when a data source starts failing without any change to the backing system. **Signing.** Grafana verifies plugin signatures and refuses to load unsigned plugins by default; loading an unsigned or locally built plugin requires an explicit allow-list setting. This is a genuine supply-chain control: a backend plugin runs arbitrary code on your Grafana host with access to configured credentials. **Deployment.** Backend plugins are platform-specific binaries, so they must exist for your architecture — a point that bites on ARM hosts — and they are installed into the Grafana image or volume rather than being pure JavaScript delivered to the browser. **Version compatibility.** Because the backend speaks a versioned RPC contract with Grafana, plugin versions are tied to Grafana version ranges more tightly than frontend-only plugins are. ## How to use this in an interview The question behind the question is usually: *"we want to alert on data from system X — what do we need?"* The correct answer is that the data source must have a backend component that declares alerting support; if it does not, you either replace the data source, get the metric into a system that does have one, or evaluate the condition outside Grafana entirely. Saying "just add an alert to the panel" both ignores the plugin capability and misunderstands where alerting lives. The secondary question is a governance one: on a shared Grafana, allowing arbitrary community backend plugins means allowing third-party code to run server-side next to every configured credential. That is a decision for the platform owner, with signing policy and an allow-list as the controls.
- A team wants to alert on data from a community data source and finds they cannot select it when creating a rule. Why?The plugin does not ship a backend component with alerting support, and rule evaluation happens on the server with no browser involved, so there is no code path the evaluator can call. Options are to use a plugin version that adds a backend, to ingest that data into a system that already has one, or to evaluate the condition outside Grafana and feed the result in as an alert.
- What is the security consideration when installing a third-party backend data-source plugin?It is arbitrary code running as a server-side process on the Grafana host, with access to the data-source configurations and their decrypted credentials, and with the host's network reachability. That is why Grafana enforces plugin signatures by default and requires an explicit allow-list for unsigned plugins; on a shared instance, plugin installation should be a reviewed platform decision rather than a self-service one.
saying these in an interview costs you the question
- Assuming every data source can back an alert rule
- Thinking a frontend-only plugin means credentials are exposed to the browser — the proxy still injects them server-side
- Treating backend plugins as merely a performance optimisation
- Ignoring plugin signing and architecture-specific binaries when planning a deployment
- Believing the plugin's backend runs inside the Grafana process rather than as a supervised child process