FIPS 140-3 Compatible Builds for VictoriaMetrics Enterprise Components

FIPS 140-3 Compatible Builds for VictoriaMetrics Enterprise Components

Share: Share on LinkedIn Share on X (Twitter)

VictoriaMetrics introduces FIPS 140-3 compatible builds for its components, starting with version 1.117.0. These builds utilize Google’s FIPS 140-3 validated BoringCrypto module.

This is critical for customers in regulated environments (federal government, finance, healthcare) to meet FIPS 140-3 cryptographic requirements for data encryption, TLS, and secure communications.

While VictoriaMetrics itself is not a FIPS-certified cryptographic module, these builds ensure all cryptographic operations are handled by the validated BoringCrypto module. This simplifies compliance for system integrators and customers undergoing FedRAMP, HIPAA, or similar audits.

Availability

#

FIPS-compatible binaries are on our GitHub repository; images are on DockerHub or Quay registries.

  • Binaries: Attached to enterprise assets, alongside regular versions. Example: victoria-metrics-darwin-amd64-v1.117.0-enterprise.tar.gz (There is a victoriametrics-prod-fips binary in the archive).
  • Container Images: scratch-based, with a -fips suffix in tags. Example: v1.117.1-enterprise-cluster-fips.
  • Architecture Support: Available for arm64 and amd64.

Performance

#

Our internal tests show no measurable impact on resource consumption or read/write request efficiency with FIPS-compatible builds.

CGO support for vmagent’s Kafka integration was disabled for simplification. This only affects the underlying library choice (Go-native vs. C-libraries) and does not impact functionality.

Please Note

#

These VictoriaMetrics builds use FIPS 140-3 validated cryptographic modules (BoringCrypto).

However, VictoriaMetrics as a complete software solution has not undergone formal FIPS 140-3 certification under the CMVP.

Get Started & Try VictoriaMetrics Enterprise

#

Ready to enhance your observability stack with FIPS 140-3 compatible components?

Request a VictoriaMetrics Enterprise Trial License, or contact our Sales team to get more information.

Leave a comment below or Contact Us if you have any questions!
comments powered by Disqus

You might also like:

What's new in VictoriaMetrics Anomaly Detection (Q1 2026)

Q1 2026 brought incremental but important updates to VictoriaMetrics Anomaly Detection: UI improvements, AI assistance inside the UI, a public traces playground, new false-positive reduction controls, and continued resource optimizations.

VictoriaMetrics at KubeCon Amsterdam: Community Highlights

VictoriaMetrics participated in KubeCon + CloudNativeCon Europe 2026 in Amsterdam. The team delivered multiple talks covering platform design, Kubernetes observability, and distributed tracing optimization. A real-world case study from Miro showcased a cost-efficient, AZ-aware observability architecture built with VictoriaMetrics. With a 15-person team on site, the booth saw strong interest from users tackling scaling, cost, and performance challenges. The company also hosted its first community after-party, “After Deploy,” co-organized with Varnish and Shipfox, extending discussions beyond the conference.

What's New in VictoriaMetrics Cloud Q1 2026? Logs, MCP Server, Better Alerting, and... a Secret Project

Q1 2026 brought VictoriaLogs GA, a hosted MCP Server, a brand new cost calculator, a major expansion of alerting rule presets with a new editor, infrastructure improvements, notifications via generic webhooks and a few things we are cooking.

VictoriaMetrics at KubeCon: Optimizing Tail Sampling in OpenTelemetry with Retroactive Sampling

If you’ve been struggling with the high resource overhead of tail sampling, check out retroactive sampling, an approach that significantly reduces sampling overhead for distributed tracing in OpenTelemetry.