Open-Source Observability · jacksontj

promxy

Promxy is an aggregating proxy that unifies multiple Prometheus instances into a single API endpoint, enabling high-availability and cross-shard query aggregation without modifying existing Prometheus infrastructure. It simplifies operations at scale by eliminating the need for multiple data sources in Grafana and allowing queries to span all monitored data.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/jacksontj/promxy

1.3k

GitHub stars

157

Forks

Primary language

MIT

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	jacksontj/promxy
Owner	jacksontj
Primary language	Go
License	MIT — OSI-approved
Stars	1.3k
Forks	157
Open issues	14
Latest release	v0.0.96 (2026-07-06)
Last updated	2026-07-05
Source	https://github.com/jacksontj/promxy

What promxy is

Written in Go, Promxy implements a scatter-gather proxy pattern that forwards requests to multiple Prometheus ServerGroups, merges responses, and exposes a Prometheus-compatible `/v1` API. It supports query federation, HA failover (filling gaps when one shard is unavailable), and optional remote_write for recording/alerting rule outputs.

Quickstart

Get the promxy source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/jacksontj/promxy.git2cd promxy3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Multi-shard Prometheus HA setup

Organizations running N identical Prometheus instances for redundancy can use Promxy to present a unified query interface, automatically filling gaps when one shard restarts or fails.

Global aggregation queries across shards

Enables Grafana dashboards and alerting rules to run cross-shard queries (e.g., 'global error rate <10%') without federation complexity or replication.

Transparent Prometheus proxy layer

Insert Promxy between existing Grafana/alerting tools and Prometheus infrastructure with zero changes to either layer, treating it as a drop-in aggregation endpoint.

Implementation considerations

Promxy must be able to reach all configured Prometheus ServerGroups; network isolation or authentication barriers require proxy configuration per servergroup.
Configure the `ignore_error` option carefully—by default, unavailable servergroups fail the query (safe for alerting); enabling it silently serves partial data.
Recording rules and alerting rule outputs require a remote_write target; promxy itself does not store metrics, so define where evaluated rules should be written.
Scatter-gather queries scale linearly with servergroup count; monitor query latency as you add shards and consider query optimization or result caching if needed.
Ensure consistent scrape configs and retention across all prometheus instances in a servergroup; mismatches may cause unexpected gaps or inconsistencies in merged results.

When to avoid it — and what to weigh

Single Prometheus instance — If you operate a single Prometheus server without HA requirements, Promxy adds operational overhead with no benefit.
High-frequency real-time analytics — Promxy's scatter-gather design inherently adds latency; queries complete at the speed of the slowest backend. For sub-second SLAs or real-time workloads, consider direct Prometheus access.
Local time-series database write requirements — Promxy has no local TSDB; recording rules require external remote_write backend. If you need local persistence of computed metrics, use native Prometheus instead.
Highly heterogeneous Prometheus versions — Promxy targets the `/v1` API but features vary by Prometheus version (subqueries, SD options); mixing very old and very new instances may cause inconsistent behavior.

License & commercial use

MIT License. Permissive OSI-approved license permitting commercial use, modification, and redistribution with minimal restrictions.

MIT license explicitly permits commercial use without royalties or special permissions. Typical MIT obligations apply: include license and copyright notice in derivatives. No warranty provided; review Promxy's operational readiness for your SLA requirements independently.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Strong
Assessment confidence	High

Security considerations

Promxy is a network proxy; ensure it is deployed in trusted network segments and that backend Prometheus instances are not exposed to untrusted clients through it. Authentication/TLS between Promxy and backends is configurable but not detailed in provided documentation—review servergroup auth config before production use. No built-in rate limiting or DDoS protection stated; consider reverse-proxy hardening if internet-facing.

Alternatives to consider

Thanos

Provides global query view across Prometheus instances, object storage integration, and long-term retention. More complex but offers query deduplication and compaction; better for large-scale multi-region setups.

VictoriaMetrics + federation

VictoriaMetrics can scrape multiple Prometheus instances and expose a unified API with better performance characteristics. Single-binary deployment; no scatter-gather penalty.

Prometheus native federation

Built-in Prometheus federation (scrape /federate endpoint) avoids external proxy; simpler for small setups but limited aggregation and HA semantics compared to Promxy.

Software development agency

Build on promxy with DEV.co software developers

Promxy simplifies HA setups and multi-shard aggregation. Deploy it as a stateless proxy between Grafana and your Prometheus shards—no changes to existing instances needed. Contact us to review architecture and evaluate fit for your monitoring scale.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

prometheus django-prometheus prometheus-operator

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Observability DevOps Infrastructure API Development & Integration Cloud Deployment Talk to DEV.co

promxy FAQ

Do I need to modify my Prometheus instances to use Promxy?

No. Promxy is a pure proxy; no sidecars, custom builds, or configuration changes to Prometheus are required. Point it at your existing instances and expose Promxy to your Grafana/alerting tools.

What happens when one Prometheus instance goes down?

By default, Promxy returns an error to avoid serving incomplete data (safe for alerting). You can set `ignore_error: true` on a servergroup to return partial results instead; trade accuracy for availability.

How does Promxy handle recording rules?

Promxy can evaluate recording rules across all shards, but has no local storage. Outputs must be sent to an external time-series backend via remote_write (e.g., Prometheus, Thanos, VictoriaMetrics).

Is Promxy suitable for queries with very large result sets?

Promxy's scatter-gather design means query latency is bounded by the slowest backend. Prometheus <2.2 had inefficient JSON marshaling; upgrading or using remote_read API can help, but direct Prometheus access is faster for latency-critical use.

Software developers & web developers for hire

DEV.co helps companies turn open-source tools like promxy into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source observability stack.

Ready to consolidate your Prometheus infrastructure?

Talk to DEV.co Schedule a Consultation