Traefik Proxy 3.6 "Ramequin": Where Every Layer Counts

Traefik Proxy 3.6 has arrived, and like the exquisite Ramequin cheese 🧀—a rare specialty from France's Bugey region—this release achieves something unique. With native Knative integration completing the trilogy, Traefik becomes the only proxy capable of seamlessly handling Cloud Native workloads (containers), Traditional workloads (VMs), and Serverless workloads in one unified platform. Revolutionary multi-layer routing solves complex traffic decisions by enriching requests through hierarchical layers, eliminating the painful workarounds teams have endured for years. Combined with the fresh new Gateway API 1.4 support, this makes v3.6 a significant milestone in Traefik’s journey. Let’s taste it!

Unique Features That Set New Standards

Multi-Layer Routing: The End of Workarounds

The most anticipated feature of this release solves a fundamental challenge in modern cloud-native routing: making routing decisions based on information that doesn't exist in the original request. Whether you need to authenticate first, then route based on user roles, check feature flags to decide between microservices and monoliths, or route enterprise customers to stable infrastructure while directing free users to staging infrastructure, multi-layer routing transforms complex workarounds into elegant, declarative configuration.

Traditional routing approaches force teams into painful compromises: duplicating authentication logic across every microservice, building separate routing proxies that add latency and complexity, or maintaining giant configuration files that break when requirements change. 

Multi-layer routing introduces hierarchical relationships between routers, where parent routers enrich requests with additional context, and child routers make routing decisions based on that enriched information.

The magic lies in progressive request enrichment. Each layer adds context that subsequent layers use for increasingly specific routing decisions. Authentication happens once at the parent level, while routing decisions are made at the child level based on the enriched result—no duplication, no external proxies, no compromises.

Here's a real-world example: routing API requests to different backends based on customer subscription tier:

http:
  routers:
    # Root router - matches all API requests and applies auth
    api-parent:
      rule: "Host(`api.example.com`) && PathPrefix(`/`)"
      middlewares:
        - auth-with-tier
      entryPoints:
        - websecure
      tls: {}
      # No service defined - this is a parent router
    
    # Leaf router - routes enterprise customers to stable
    api-enterprise:
      rule: "HeaderRegexp(`X-Customer-Tier`, `(enterprise|business)`)"
      service: stable-backend
      parentRefs:
        - api-parent
    
    # Leaf router - routes free tier to canary
    api-free:
      rule: "Header(`X-Customer-Tier`, `free`)"
      service: new-version
      parentRefs:
        - api-parent

  middlewares:
    auth-with-tier:
      forwardAuth:
        address: "http://auth-service:8080/validate"
        authResponseHeaders:
          - X-Customer-Tier
          - X-Customer-Id
          - X-User-Email

  services:
    stable-backend:
      loadBalancer:
        servers:
          - url: "http://api-v1-stable:8080"
    new-version:
      loadBalancer:
        servers:
          - url: "http://api-v2-canary:8080"

The hierarchy supports three router types: Root Routers attached to entryPoints that apply shared middleware and define TLS configuration, Intermediate Routers that can have children while inheriting configuration from their root, and Leaf Routers that must define a service and handle the final routing decision. Child routers cannot be called directly—requests must flow through their parent, ensuring you can't circumvent authentication or other parent-level logic.

This unlocks previously complex patterns like authentication-based routing (where admin and user requests to the same endpoint route to different backends based on role), feature flag-based migrations (routing users to microservices or monoliths based on feature flag evaluation), and sophisticated progressive rollouts where routing decisions depend on customer context, subscription tiers, or experimental configurations. Learn more in the documentation and in the dedicated blog post.

Knative Integration: The Universal Proxy for Any Workload

Traefik v3.6 introduces Knative provider support, achieving a key milestone: Traefik is now the only proxy that can seamlessly operate across Cloud Native workloads (containers), traditional workloads (Virtual Machines), and serverless workloads. This unprecedented versatility makes Traefik a truly unique platform capable of handling any kind of workload your infrastructure demands.

The Knative provider automatically handles service discovery, scaling events, and traffic routing for Knative workloads, providing a unified experience across your entire application landscape. Teams can now use a single proxy solution for their complete infrastructure, dramatically simplifying operations while maintaining the specialized optimizations each workload type requires.

Let’s enable the KNative provider in Traefik first:

experimental:
  knative: true
providers:
  knative:
    namespaces:
      - "serverless-apps"
      - "production"

The following Service manifest configures the running Traefik controller to handle the incoming traffic.

---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: WHOAMI_NAME
              value: "Knative Test Service"

Once everything is deployed, sending a GET request to the HTTP endpoint should return the following response:

$ curl http://whoami.default.example.com

Name: Knative Test Service
...

Special recognition goes to idurgakalyan for spearheading this innovative integration that completes Traefik's transformation into the universal proxy for modern infrastructure (#11448). Learn more in the documentation and in the dedicated blog post.

Gateway API 1.4 Support: Leading the Standards Evolution

Traefik v3.6 embraces the future with full Gateway API v1.4 support, incorporating significant advancements that solidify Kubernetes networking standards. This release brings two major features from the Experimental to the Standard channel, making them production-ready for enterprise deployments.

BackendTLSPolicy graduates to Standard, enabling secure TLS configuration from Gateway to backend services with production-grade reliability. This critical security feature allows you to enforce end-to-end encryption, ensuring that traffic remains protected even between internal services.

SupportedFeatures status reporting also reaches Standard, providing clear visibility into which Gateway API features your implementation supports. This eliminates guesswork and enables better operational planning by exposing feature compatibility directly through Kubernetes status fields.

Additional Enhancements That Make a Difference

Health Checking Evolution

• TCP Health Checks (#11238 by ddtmachado)—Native TCP health checking capabilities for non-HTTP services. Learn more.
• Passive Health Checks (#11351 by Nelwhix)—Intelligent health monitoring that observes actual traffic patterns to determine service health. Here’s the documentation.

New Load Balancing Strategies

• Least Time Strategy (#12167)—Route requests to servers with the lowest response times for optimal performance. Learn more in our configuration guide.
• Highest Random Weight Algorithm (#9946 by mathieuHa)—Advanced probabilistic load balancing for enhanced traffic distribution. Check out Traefik MCP Gateway, which already leverages it to handle agent requests more efficiently.

Provider Enhancements

• AWS ECS IPv6 Support (#12179 by wizbit)—Full IPv6 compatibility for Amazon ECS deployments. ECS provider docs.
• Docker Non-Running Container Discovery (#10645 by acouvreur)—Enhanced container discovery capabilities for development workflows.

Kubernetes Integration

• ExternalName Service Support (#12065 by james-callahan)—Publish Kubernetes ExternalName services through Traefik for external service integration.
• Highest Random Weight in CRD (#12061)—Advanced load balancing options in Kubernetes Custom Resources.

Security and Performance

• ACME Certificate Resolver Options (#11977 by ldez)—Enhanced certificate management capabilities with new resolver configurations. See our ACME documentation.
• HTTP/2 HPACK Table Size Configuration (#12050 by GCHQDeveloper548)—Fine-tune HTTP/2 performance with configurable HPACK table sizes.

Developer and User Experience

• Plugin Syscall Support (#11939 by david-garcia-garcia)—Extended plugin capabilities with syscall support for advanced integrations.
• Dashboard Improvements (#12145 by leccelecce)—More compact table layouts for improved dashboard usability.

Observability

• Provider Namespace Logging (#12002 by shreealt)—Enhanced visibility during startup for Consul, Consul Catalog, and Nomad providers.
• Authentication Middleware Warnings (#12085 by kianelbo)—Improved security awareness with maxBodySize configuration warnings.

The Artisans Behind Every Layer

Like the careful aging process that creates Ramequin's distinctive character, Traefik v3.6 is the result of months of dedication from our incredible community. To every developer who opened an issue, every contributor who submitted a pull request, every user who provided feedback—you are the artisans behind Traefik's continued excellence. Your passion and expertise continue to drive innovation in cloud-native networking and contribute to routing requests to millions of applications and APIs worldwide.

Ready to taste the fresh new Traefik 3.6 "Ramequin"?

Essential Resources and Next Steps

• Download Traefik 3.6: GitHub Releases | Docker Hub
• Documentation: Complete Documentation | Migration Guide
• Community: GitHub Repository | Community Forum
• Learn More: Official Website | Blog