Applications are becoming more distributed, and the connections between them are becoming more complex. Platform teams must securely expose services, enforce consistent access policies, keep application traffic available when infrastructure components are disrupted, and meet increasingly demanding security requirements.
At the same time, AI agents, tools, and inference models are creating a new class of machine-to-machine interactions that enterprises need to identify, connect, and govern.
Consul 2.1.0 addresses both realities: improving the networking foundation customers depend on today while introducing new building blocks for governing emerging agentic workloads.
»Simplify and govern application access with an enhanced API Gateway
As organizations expose more services, application teams need to manage different protocols, TLS certificates, service discovery, authorization policies, and backend health. Handling each concern independently can increase both application complexity and the operational burden on platform teams.
Consul 2.1.0 expands API Gateway to centralize more of those responsibilities.
The Consul API gateway now supports end-to-end HTTP/2 and gRPC, allowing these protocols to be maintained from client to backend rather than being downgraded on the upstream connection. Consul can also automatically register DNS for services exposed through the API Gateway and provide downstream TLS using Connect CA certificates when an operator does not explicitly supply another certificate. Passive health checking adds another layer of protection by enabling unhealthy backend instances to be identified through Envoy outlier detection.
For enterprises that need to apply organization-specific security and traffic policies, external authorization and external processing provide additional extensibility.
External authorization allows access decisions to be delegated to external HTTP or gRPC authorization services, enabling organizations to enforce policies at the gateway instead of implementing the same authorization logic independently within every application.
Similarly, external processing allows organizations to introduce custom request and response processing into supported traffic paths. This can support scenarios such as request transformation, header enrichment, and other organization-specific processing requirements.
For application teams, this means fewer networking and security concerns need to be embedded into individual services. For platform teams, it provides a more consistent place to govern how applications are exposed and how traffic is handled.
»Improve application continuity by reducing DNS dependence on the control plane
Service discovery is fundamental to distributed applications. But when applications depend on the Consul control plane for DNS resolution, temporary control-plane disruption can also affect their ability to resolve the services they need to reach.
Consul 2.1.0 introduces opt-in localized DNS for configured virtual upstreams.
For these configured paths, a local UDP listener can resolve upstream FQDNs to their virtual IP addresses without requiring every DNS request to reach the Consul control plane. During certain control-plane disruptions, workloads can therefore continue resolving upstreams already represented by this local configuration.
The distinction is important: localized DNS is a targeted resilience capability, not a replacement for Consul DNS or a guarantee that the entire service mesh can function independently from its control plane.
For organizations operating business-critical applications, however, reducing an application's runtime dependence on the Consul control-plane DNS can remove one potential source of disruption during maintenance or temporary control-plane availability issues.
»Modernize the networking foundation with nftables
Consul transparent proxy helps applications participate in a service mesh without requiring developers to explicitly configure every upstream connection. Behind the scenes, Linux traffic-redirection rules ensure that applicable application traffic flows through an Envoy proxy.
Consul 2.1.0 modernizes this foundation by moving the Consul connect redirect-traffic command from iptables/ip6tables to native nftables. IPv4 and IPv6 rules can now be applied atomically in a single pass using the nftables inet address family, rather than through separate iptables and ip6tables operations.
This matters operationally because separate rule programming can create an intermediate state in which only part of an intended network configuration has been applied. Atomic updates provide a cleaner model while moving Consul toward the modern Linux packet-filtering framework.
An important consideration when upgrading
This modernization also introduces an upgrade consideration for existing environments.
Consul 2.1.0 does not automatically remove Consul-managed iptables or ip6tables rules created by previous versions. Customers performing an in-place host or VM upgrade should remove those rules before applying the new nftables configuration. Running both can result in double NAT or inconsistent traffic redirection. The new implementation also requires the nft binary and appropriate Linux kernel support, and there is no automatic fallback to iptables.
For customers, nftables represents both networking modernization and a more consistent approach to programming IPv4 and IPv6 traffic interception, with migration planning required when upgrading existing installations.
»Strengthen security for today's regulatory needs and tomorrow's cryptographic risks
Security requirements are evolving on two fronts.
Organizations in regulated industries need infrastructure that supports established cryptographic standards today. At the same time, security teams are beginning to consider how advances in quantum computing could affect data being encrypted now but retained by an attacker for future decryption.
Consul 2.1.0 helps customers address both concerns.
Prepare TLS communications for a post-quantum future
One emerging concern is commonly described as “harvest now, decrypt later”: an attacker could capture encrypted information today and retain it in the hope that future cryptographic capabilities make it possible to decrypt.
Consul 2.1.0 adds support for configuring X25519MLKEM768 hybrid TLS key exchange on supported mesh and agent communication paths. The hybrid approach combines the established X25519 classical key-exchange mechanism with ML-KEM-based post-quantum cryptography. Consul 2.1.0's release notes describe configurable ECDH/KEM curves for sidecar mTLS and agent RPC, HTTPS, and gRPC communication, including automatic hybrid X25519MLKEM768 injection under the documented TLS configuration.
Rather than requiring organizations to replace classical cryptography outright, the hybrid approach provides a path for beginning to introduce quantum-resistant key establishment while retaining a classical cryptographic component.
The scope is deliberately specific. This strengthens TLS key exchange. It does not make certificate signatures post-quantum or make an entire Consul deployment “post-quantum secure.”
For security-conscious organizations, the value is the ability to begin incorporating hybrid post-quantum protection into their networking strategy before quantum-related risks become an urgent migration exercise.
Support regulated deployment requirements with FIPS 140-3
For organizations operating under established cryptographic compliance requirements, Consul Enterprise provides FIPS 140-3 builds. These builds link to a cryptographic module holding a FIPS 140-3 certificate, and separate FIPS artifacts are provided for Consul Enterprise and related components.
Compliance is not simply a property of installing a binary. Customers are responsible for operating Consul in an appropriate FIPS-compliant configuration, including applicable TLS, gossip encryption, mTLS, deployment, and cryptographic requirements. The documented independent validation of how Consul integrates the FIPS 140-3 module is also still in progress.
Together, the FIPS and hybrid post-quantum capabilities allow organizations to address two different security horizons: established regulatory requirements and emerging cryptographic risk.
»Build a foundation for governed agentic connectivity with Consul agentic runtime fabric (beta)
Traditional applications are not the only workloads organizations now need to connect.
AI agents increasingly interact with other agents, invoke enterprise tools and MCP servers, and communicate with inference models hosted inside and outside an organization's infrastructure. As these workloads move from experimentation toward enterprise use, they introduce familiar but increasingly important questions:
What is communicating? What can it connect to? Under which identity? Which policies govern that connection? And how should access to inference providers be controlled?
Consul 2.1.0 introduces new Enterprise building blocks for addressing these patterns.
AI workloads can declare roles such as AI agent, MCP server, and inference model as part of their service registration. This provides Consul with additional context about the type of workload participating in the network.
An inference gateway introduces a governed connectivity layer for model access. The gateway can terminate inbound mesh mTLS, enforce Consul intentions, apply processing and routing policy, and route workloads to eligible inference models. The 2.1.0 implementation also supports external inference models through terminating gateways and priority-based model selection and failover.
The release further introduces Enterprise OAuth capabilities for AI agents and MCP servers, including OAuth client lifecycle management and on-behalf-of token exchange capabilities.
The architectural distinction is important:
Consul is not trying to determine what an AI agent should do or orchestrate how agents complete tasks. It provides the connectivity, identity, and policy foundation for governing how agents, tools, and models communicate.
For organizations moving agentic applications toward production, this creates a path to apply familiar enterprise networking principles to a new class of machine-to-machine communication.
These agentic capabilities should be evaluated according to their documented maturity, supported integrations, and deployment requirements.
Learn more: Explore the Consul Agentic Runtime Fabric documentation
»Gain centralized visibility with Consul Operations Hub (beta)
As organizations expand Consul across datacenters and environments, another challenge emerges: understanding the overall state of the Consul estate without examining every environment independently.
Platform and operations teams may need to understand what infrastructure exists, how services connect, what intentions control communication, and whether security configurations are consistent across environments. Gathering that information independently can become increasingly difficult as the Consul footprint grows.
Consul Operations Hub is designed to provide a more centralized operational perspective.
It provides centralized, read-only visibility across self-managed Consul Enterprise datacenters, bringing information such as inventory, topology, intentions, and security state into a common operational view.
For operations teams, the primary value is not another place to configure Consul. Instead, it is the ability to understand distributed Consul environments from a centralized perspective, helping teams investigate topology, connectivity, and security posture without first assembling that picture manually across individual datacenters.
Operations Hub is intentionally read-only in this beta. It does not write configuration back to participating clusters or perform automated remediation.
This makes it a visibility and operational-awareness capability rather than another control plane.
Learn more: Explore the Consul Operations Hub documentation
» Get started with Consul 2.1.0
Consul 2.1.0 focuses on several challenges facing infrastructure teams as application environments evolve:
Simpler application access and traffic governance through expanded API Gateway, authorization, and processing capabilities.
Greater runtime resilience by reducing DNS dependence on the control plane for supported virtual upstreams.
A modern networking foundation through native nftables-based transparent proxy traffic redirection.
Stronger preparation for security and regulatory requirements through hybrid post-quantum key exchange and FIPS 140-3 Enterprise builds.
A foundation for governed agentic connectivity, extending Consul's connectivity, identity, and policy principles toward agents, tools, and inference models.
Improved operational awareness through centralized visibility with Consul Operations Hub Beta.
Before upgrading, customers should review the Consul 2.1.0 release notes and upgrade guidance, with particular attention to nftables migration requirements, platform prerequisites, security considerations, and the maturity and supported configurations of beta capabilities.
Ready to get started?
Download Consul 2.1.0: Install and download Consul
The official installation page provides Consul 2.1.0 binaries for supported architectures across Linux, macOS, Windows, FreeBSD, and Solaris, along with package-manager installation options and checksum verification information.
