Grafana Agent vs Alloy: What Changed and Why

TL;DR: Grafana Agent reached End-of-Life on November 1, 2025 and has been replaced by Grafana Alloy. Alloy consolidates Agent's Static mode, Flow mode, and Kubernetes Operator into a single collector built on the OpenTelemetry Collector while maintaining native support for Prometheus and Loki. If you're using Flow mode, migration is relatively straightforward. If you're using Static mode, the migration process will involve reviewing and testing the converted configuration. Before switching over, verify relabeling rules, recheck resource usage, and confirm that Prometheus and Loki are receiving the same data and labels as before. If you're still running Promtail, it's worth migrating both to Alloy at the same time since Promtail is also End-of-Life.

If you deployed Grafana Agent a couple of years ago, there's a good chance you haven't thought about it since. It quietly collects metrics, ships logs, and generally stays out of the way.

What you may not realize is that Grafana Agent reached End-of-Life on November 1, 2025. That includes Static mode, Flow mode, and the Kubernetes Operator. Grafana Labs has stopped creating bug fixes, security patches, and official support. If you're still running it, your collection layer is probably still performing normally, but is now unsupported.

That doesn't necessarily mean it will stop working tomorrow, plenty of unsupported software continues running for years. It does mean you're taking on the risk yourself, especially as the rest of your monitoring stack continues to evolve.

This article covers why Grafana Labs replaced Agent with Alloy, what actually changes during the migration, and where people tend to run into problems.

Why Grafana Agent was deprecated

One of the biggest issues with Grafana Agent is that it was essentially three agents, not one product:

• Static mode, which used YAML and looked similar to Prometheus.
• Flow mode, which introduced a component-based configuration using River.
• The Kubernetes Operator, which managed Agent deployments inside Kubernetes.

Each had its own documentation, examples, bugs, and learning curve. Before setting it up, you had to first decide which version of Agent to deploy. Grafana Labs solved that by consolidating everything into Grafana Alloy.

Rather than maintaining multiple collectors, Alloy becomes the single collection agent moving forward. It's built on the OpenTelemetry Collector while keeping first-class support for Prometheus and Loki, and replaces Promtail altogether. Instead of separate binaries for different use cases, everything lives in one collector. It's similar enough to Flow mode that if you were already using it, this probably feels like a rebranding exercise, but if you were using Static mode, it's a much bigger change.

Alloy isn't just Grafana Agent with a new name

It's easy to think of Alloy as Agent 2.0, but it's more complex than that. Grafana Labs is betting on OpenTelemetry becoming the long-term standard for telemetry collection. Rather than building around Prometheus first and adding OpenTelemetry later, Alloy starts with the OpenTelemetry Collector and layers Prometheus scraping, Loki log collection, and Grafana integrations on top.

The result is one collector that can ingest almost anything while still feeling familiar if you're already running a Prometheus-based stack. For most users, that means fewer moving pieces and a single collector to manage, and reduced maintenance overhead.

What actually changes during migration

Static mode

Static mode users have the biggest leap to make, since Agent Static mode used YAML with instance-based configuration. Alloy uses .alloy configuration files built from components connected together into pipelines. Instead of one large configuration file describing everything, you explicitly define how data flows from one component to another.

Grafana Labs provides a conversion utility:

alloy convert --source-format=static

It does a good job handling the mechanical translation, but I wouldn't trust the output without reviewing it carefully. If you've accumulated years of custom scrape jobs, relabeling rules, and integrations, expect to spend some time validating the converted configuration.

Flow mode

The process of transitioning from Flow mode to Alloy is much smoother. Flow already introduced the component model that Alloy uses, and most of the migration comes down to renamed components and minor syntax updates. If you're already comfortable with Flow, this is probably an afternoon project instead of a week-long one.

Understanding the component model

Even if you're coming from Static mode, the component model ends up making a lot of sense once you get used to it. Instead of one giant configuration file, Alloy builds pipelines from individual components.

For example:

• prometheus.scrape collects metrics.
• prometheus.remote_write forwards those metrics.
• loki.source.file reads log files.
• loki.write sends those logs to Loki.

Each component has a specific job, and when writing the .alloy file, you explicitly connect them together.

Consequently, it feels more like building a pipeline than writing a traditional configuration file. Once you understand how the pieces fit together, it's generally easier to troubleshoot because you can see exactly where data is flowing.

Things to verify before switching over

Most migrations typically go smoothly, but the problems usually show up in the little details.

Verify relabeling

The conversion tool will translate your relabel_configs, but it's dangerous to assume the behavior is identical.

In Alloy, relabeling happens inside a prometheus.relabel component as part of a pipeline. If your configuration depended on rule ordering, make sure the converted pipeline preserves that behavior.

Recheck resource usage

Don't assume Alloy has the same resource requirements as Agent. If you're combining Prometheus scraping with OTLP receivers or adding log collection into the same instance, memory usage can change enough that your old container limits are no longer appropriate.

If you're still running Promtail, migrate both together

Promtail reached End-of-Life on March 2, 2026, and Alloy replaces that as well.

Instead of migrating Agent now and Promtail later, consider doing both at the same time. Alloy can collect metrics and logs from the same process, which simplifies your collection layer considerably. I wrote an article discussing the transition from node_exporter to Alloy, and another that covers transitioning from Promtail to Alloy.

Validate what reaches your backends

It's easy to verify that Alloy is running, it's much more important to verify that Prometheus and Loki are receiving the same data they were before. Pay particular attention to labels. A missing or renamed label won't trigger an alert, but it can quietly break dashboards, recording rules, and alerting logic.

Is migrating worth it?

If you're running a simple Flow deployment, it probably is. It's a relatively straightforward migration. If you're running years of Static mode configuration across dozens or hundreds of servers, this is an intense project. You'll need to plan it, test it, and validate the results.

The alternative, though, is continuing to run unsupported infrastructure. That means no security updates, no bug fixes, and no guarantee that future versions of Prometheus, Loki, or the surrounding ecosystem will continue working the way they do today. For a handful of servers, that's manageable, but for larger environments, it quickly becomes technical debt that only gets more expensive to deal with later.

Migrating to Alloy isn't exciting work, but it's one of those maintenance tasks that's easier to do on your schedule rather than during an outage.