victoria-metrics

What is victoria-metrics?

The victoria-metrics image packages the victoria-metrics time-series database so you can run a high-performance, Prometheus-compatible metrics backend inside containers without managing custom storage infrastructure. victoria-metrics is designed for high-cardinality environments — it ingests data from Prometheus, Grafana Agent, OpenTelemetry Collector, and other collectors using standard protocols, and stores it far more efficiently than Prometheus's local TSDB. Its single-node build handles most production workloads; the cluster build adds horizontal scalability across vminsert, vmselect, and vmstorage components for teams operating large-scale observability platforms. It supports MetricsQL, a Prometheus-compatible query language, and serves as a drop-in long-term storage backend for teams that prioritize operational simplicity and resource efficiency.

What is Echo's victoria-metrics image?

Echo's victoria-metrics image is a hardened build of victoria-metrics on Echo's hardened base. Echo images are designed to be a drop-in replacement: change the FROM line in your Dockerfile and CVEs go to zero without disrupting your metrics ingestion pipeline. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants:

• Distroless variant — optimized for runtime use, with the smallest possible attack surface
• Default variant — includes essential build tools, package managers, and shells for teams that need operational access

For production victoria-metrics deployments, the distroless variant keeps ingestion, querying, and storage fully intact while minimizing exposure; the default variant suits platform teams that need shell access for configuration tuning, storage inspection, or MetricsQL debugging.

What is the difference between Echo's victoria-metrics image and the public victoria-metrics image?

Public victoria-metrics images are built on bases that include OS-level tooling useful for development and debugging, but which accumulate CVEs across components that run continuously in production. Observability infrastructure is a frequently overlooked attack surface — victoria-metrics nodes ingest metrics data around the clock, often with access to internal network segments and storage credentials, making a vulnerable image a real risk in any serious security program. Echo's build retains everything victoria-metrics needs for data ingestion, query execution, and storage compaction while removing packages that don't belong in a production metrics container. As we covered in our post on how to protect your company from software supply chain attacks, infrastructure tooling images are common blind spots in vulnerability programs precisely because they sit outside the application layer. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my victoria-metrics image with Echo's victoria-metrics image?

Yes. Echo's victoria-metrics image is a drop-in replacement. Update the FROM line in your Dockerfile or the image reference in your Helm chart and your metrics pipeline keeps running — the CVEs disappear, the behavior doesn't. Data ingestion, MetricsQL queries, storage compaction, and Prometheus-compatible scrape endpoints all continue to work without any changes to your existing victoria-metrics configuration or collector setup.

Is Echo's victoria-metrics image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for platform teams operating observability stacks inside FedRAMP boundaries where victoria-metrics nodes handling continuous metrics ingestion and storage must meet cryptographic requirements.

What is Echo's vulnerability management SLA on the victoria-metrics image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for time-series storage components that ingest data continuously and are rarely cycled in production.

Is Echo's victoria-metrics image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production victoria-metrics deployments, the distroless variant is the leaner, more secure choice; for platform teams that rely on shell access for storage inspection, configuration tuning, or MetricsQL debugging, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in victoria-metrics?

Echo's victoria-metrics image is built from source with only the absolute essentials needed to run the time-series ingestion and query workload, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the victoria-metrics version that works for your observability stack without forcing a functional change for the sake of security.

Will Echo's victoria-metrics image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For platform teams running long-term metrics infrastructure under an ATO, Echo's hardened victoria-metrics image keeps the observability layer in-boundary and compliant.