Traefik Proxy 3.7: Ingress NGINX, Without Ingress NGINX

Traefik Proxy 3.7, codenamed Langres, is the most consequential release we've shipped this year. It brings 85+ Ingress NGINX annotations now natively supported (and the experimental flag finally dropped), a brand-new certificates view in the dashboard, middlewares on services, full Gateway API v1.5 support, and retries and failover driven by HTTP status codes.

If you're running Ingress NGINX today, Traefik Proxy v3.7 is your drop-in replacement. Bring your existing manifests, enable the provider, and Traefik takes over. No YAML rewrite. No annotation conversion. No big-bang cutover. That's the headline. Let's get into the rest.

85+ Annotations, 90% of Snippets Use Cases, and It's All Production Ready

When we first introduced the Ingress NGINX provider in v3.5, we framed it as a migration foundation. Nine months, dozens of community PRs, and one official Ingress NGINX retirement announcement later, Traefik has become a true drop-in replacement.

In v3.7, the Ingress NGINX provider supports more than 85 of the most common annotations natively, covering more than 90% of real-world usage patterns we have observed across hundreds of production clusters. We didn't pick them by guessing. The open-source Ingress NGINX-migration tool (part of the Ultimate Migration Kit we shipped earlier this year) sends us anonymized usage data when users opt in (e.g., which annotations are deployed, in what combinations, and at what frequency). Every annotation we added in this release was prioritized from real production patterns across hundreds of clusters.

The breadth covers the entire long tail: authentication, session affinity, routing and redirects, proxy tuning, load balancing, rate limiting, canary deployments, custom headers, custom error pages, default backends, access control, and observability. The complete list of 85+ supported annotations and their behavioral notes lives in the NGINX Ingress Provider documentation.

The most strategically important addition is partial support for configuration-snippet, server-snippet, and auth-snippet (#12715, #12778 by @juliens). Snippets are the universal escape hatch of Ingress NGINX, used heavily in production: they let users embed raw NGINX directives that the controller pastes verbatim into the generated nginx.conf file before reloading the worker processes. Because the user-provided text becomes part of the runtime configuration without parsing or validation, a malicious or simply malformed value can inject arbitrary NGINX behavior into the controller. Snippets aren't the specific vector exploited by IngressNightmare (that was a different annotation), but they are the most extreme expression of the same architectural pattern: user input templated into the controller's runtime config.

The Kubernetes maintainers explicitly cited snippets as one of the "serious security flaws" that drove the retirement decision. But refusing snippets in Traefik would break too many real migrations, and copying Ingress NGINX's approach would recreate the vulnerability class. So we did neither: Traefik parses snippet content into structured input, maps it against a curated allowlist of common, safe directives (header manipulation, rewrites, variable interpolation for client IPs and URI components), and rejects everything else. Unlike Ingress NGINX, Traefik does not generate a raw config file at all, so there is nothing for the raw user text to be pasted into. The 90% of real-world snippet use cases just work, on a simpler and safer foundation.

Behind the scenes, what does this mean operationally? There is no YAML to rewrite. Bring your existing Ingress resources, enable the provider with a few lines of static configuration, and Traefik translates them into its internal object model securely:

providers:
  kubernetesIngressNginx:
    enabled: true

The full step-by-step path, including running the audit, deploying Traefik alongside your existing controller, and progressively shifting traffic, is in the Ingress NGINX to Traefik migration guide. We're also publishing a 3-part blog series alongside this release that walks through it end-to-end. The first post, Ingress NGINX Migration: Measure Twice, Cut Once, covers the audit step in depth: how to inventory your annotations with the migration tool and translate the NGINX ConfigMap into Traefik's configuration model. Parts 2 (install) and 3 (progressive cutover) follow weekly.

And after a year of community-driven maturation, the provider has graduated. The experimental flag is gone. The Ingress NGINX Provider is now a first-class citizen in Traefik. If you are still on Ingress NGINX, this is your drop-in replacement, validated by IBM Cloud, Nutanix, OVHcloud, SUSE, TIBCO, and a long list of organizations that have already made the switch.

TLS Certificates in the Dashboard: A Community Gift

TLS Certificates in the Traefik Proxy Dashboard

Some of the best Traefik features come from outside our core team. v3.7 ships a brand-new Certificates menu in the dashboard (#12628), authored by @holomekc as an external contribution that we are particularly proud of.

For years, certificates were the invisible part of Traefik's runtime. You configured them, you deployed them, and you trusted that everything was working. The new dashboard view brings that visibility front and center: you can now see every TLS certificate in use, the domains it covers, its expiration, and where it is attached across HTTP and TCP routers.

This is exactly the kind of operator-quality-of-life feature that does not show up in benchmarks but transforms day-to-day operations. Renewal anxiety, expired certs in production, missing domains on a wildcard cert: the dashboard now answers all of these at a glance.

Middlewares on Services: A Cleaner Routing Model

Until now, middlewares in Traefik attached to routers or entryPoints. That mostly worked, but it produced a pattern that anyone running Traefik at scale knows well: when a service is exposed by ten routers, you end up duplicating the same middleware reference ten times. And when that middleware is a forwardAuth or a rate limiter that fundamentally belongs to the service, not the route, the duplication is a smell.

v3.7 fixes this with middlewares on services (#12544 by @juliens, co-authored with @lbenguigui). You can now attach middlewares directly to a service definition, and they apply to every router that targets that service.

http:
  services:
    api:
      loadBalancer:
        servers:
          - url: "http://api-backend:8080"
      middlewares:
        - rate-limit
        - auth

This change matters beyond the convenience of fewer YAML lines. It moves middleware semantics closer to where they belong conceptually. Authentication that protects a service should live on the service. Rate limiting that protects a backend's capacity should live on the backend. The router stays focused on what it is for: matching requests.

The same change also unlocks Gateway API filters on HTTP backends, a long-standing gap in our Gateway API support that this single PR closed.

Gateway API v1.5: Leading the Standard, Setting the Pace

Traefik v3.7 ships with full support for Gateway API v1.5.1 (#12768 by @mmatur), the latest revision of the Kubernetes networking standard. Traefik is part of the very small circle of gateways that keep pace with the Gateway API project with the regularity of a metronome: every minor release of the spec lands in a Traefik release within days. This release brings two notable additions on top of v1.5 baseline:

Multiple certificateRefs on Gateway listeners (#12590 by @mortennordbye). A listener can now reference multiple certificates, with Traefik selecting the correct one on each SNI. This eliminates a class of workarounds that involved either splitting a single logical Gateway into several, or fronting it with extra TLS termination.

Secret support for BackendTLSPolicy.caCertificateRefs (#12927 by @kevinpollet). End-to-end TLS to backend services with private CAs now works with secret-stored CA bundles, removing the last friction point for production-grade BackendTLSPolicy deployments.

Combined with the new middlewares-on-services semantics that bring Gateway API filters to HTTP backends, v3.7 closes the remaining feature gap between the Ingress provider and the Gateway API provider.

Retry and Failover Driven by Status Codes: Resilience That Resembles Reality

Traefik has had a Retry middleware and a Failover service since the early days. Both were good, but both shared the same blind spot: they only fired on connection failures and explicit health-check signals, not on what your application was actually telling them.

That changed in v3.7.

The Retry middleware now supports retries based on HTTP response status codes, a configurable per-attempt timeout, and an opt-in flag for non-idempotent methods (#12667 by @LBF38). If your backend occasionally returns a 502 under load, you can configure Traefik to absorb that and retry without the client noticing:

http:
  middlewares:
    smart-retry:
      retry:
        attempts: 3
        initialInterval: 100ms
        retryOn:
          statusCodes:
            - 502
            - 503
            - 504
        timeout: 2s

The Failover service now triggers on response status codes too (#12596 by @lbenguigui). Combined with the new service failover support in the TraefikService CRD (#12733 by @jspdown), you can declare blue-green and active-passive setups directly in Kubernetes without leaving Traefik's CRD model:

apiVersion: traefik.io/v1alpha1
kind: TraefikService
metadata:
  name: api-failover
spec:
  failover:
    service: api-primary
    fallback: api-backup
    healthCheck: {}
    errors:
      status:
        - "500-504"

Real production failures rarely look like clean connection refusals. They look like 502s during a slow rollout, 503s when an autoscaler is catching up, 504s when a downstream dependency degrades. v3.7 lets Traefik respond to those signals natively, without external service meshes or sidecar acrobatics.

More Goodies

A non-exhaustive selection of the rest, because every release has a long tail of quality-of-life improvements that do not need their own section but absolutely deserve a mention:

Routing & Rules

Wildcard host in Host and HostSNI matchers (#12884 by @juliens)
Providers routing precedence configuration (#12895 by @juliens)
Per-Ingress entry points selection on Nginx Ingresses (#12727 by @ajacques)
ipAllowListStrategy option for allowlist-source-range and whitelist-source-range (#12932 by @mathieuherbert)

Middleware

New encodedCharacters middleware (#12555 by @gndz07)
authSignInURL in forward auth (#12293 by @kyounghunJang)
errorRequestHeaders in Errors middleware (#13034 by @gndz07)

TLS

Graceful handling of missing TLSStore secrets (#12522 by @david-garcia-garcia)
Fragmented TLS Client Hello support (#12787 by @rtribotte)
CertificateTimeout ACME configuration option (#12278 by @ceko)

Observability

Stdio access logs alongside OTLP logging (#12307 by @Mulgish)
OTel-conformant trace context attributes in access logs (#12801 by @mmatur)
Kubernetes Ingress logs fields (#12913 by @rtribotte)
File path support for metrics.influxdb2.token (#12458 by @barhun)

Web UI

Server weight in service detail view (#12325 by @murataslan1)
Dashboard name configuration (#12410 by @gndz07)

MISC

Global option to disable X-Forwarded-For appending (#12374 by @lbenguigui)
Cipher suites configuration with ServersTransport (#11965 by @NEwa-05)
maxResponseBodySize on HTTP provider (#12788 by @gndz07)
maxResponseBodySize on ForwardAuth (#12694 by @gndz07)
Knative v1.20.0 support (#12441 by @idurgakalyan)

Several security advisories were also addressed across the v3.7 cycle. The full list, with CVE IDs, severity, and patched versions, is on the Traefik Security Advisories page. Security continues to be a first-class part of every release.

A Toast to the Community

Traefik 3.7 is the work of a community that takes its time and gets it right. More than 80 contributors shipped code into this release, from first-time PR authors fixing typos in documentation to long-time maintainers landing entire subsystems. With 63k+ GitHub stars and billions of downloads behind us, every release is a community release, and v3.7 is more than most.

To everyone who opened an issue, reviewed a PR, sent us migration data through the audit tool, contributed an annotation, or shared their production war stories: thank you. You are why Traefik continues to set the standard for cloud-native ingress. Want to add yours to v3.8? traefik/traefik#12631 tracks the remaining Ingress NGINX annotations and is a great on-ramp for first-time contributors, but contributions are welcome across the entire codebase, on any topic.

Ready to upgrade?

Essential Resources and Next Steps

Download Traefik 3.7: GitHub Release | Docker Hub
Documentation: Complete Documentation
NGINX Migration: ingressnginxmigration.org | Migration Tool | NGINX Migration Guide
Community: GitHub Repository | Community Forum