Single-click CDN Experience for F5 Distributed Cloud Load Balancers
Fundamentals The modern CDN has evolved well beyond cache and serve. Today’s platforms are intelligent edge fabrics that combine performance optimization, layered security, multicloud routing, and even workload execution at the edge. Few products embody this evolution more completely than F5 Distributed Cloud CDN, and this post explores both why CDNs matter and what sets F5’s newest approach apart. At its core, a CDN is a globally distributed system of edge servers, called PoPs or Regional Edges (RE), that cache content and handle user requests on behalf of the server origin. When a user requests a resource, DNS resolution routes them to the nearest PoP. If the resource is cached there (a “cache hit”), it’s returned immediately. If not (a “cache miss”), the PoP fetches it from the origin, stores it, and returns it to the user. The speed improvement isn’t just perceptual. Reduced Round-Trip Time (RTT) correlates directly with business outcomes. Every page load shaved makes a difference for search rankings, checkout completion, and ad viewability all improve with lower latency. CDNs don’t just make things faster; they make digital businesses more competitive. To put the difference in concrete terms, here’s how a typical 200KB page might deliver across different scenarios. Platform deep dive Traditional CDNs optimize for one thing: getting cached bytes to users fast. Distributed Cloud CDN starts there but doesn’t stop, it's engineered as a unified platform where content delivery, application security, multicloud connectivity, and edge compute converge under a single operational surface. F5’s approach is architecturally distinct Most CDNs are standalone services that organizations integrate with separate security tools, load balancers, and observability stacks. The operational overhead of stitching these together and keeping policies consistent across them is substantial. F5 takes a different approach: CDN is one capability within the broader Distributed Cloud Platform, meaning it inherits the platform’s DNS, load balancing, WAF, observability, and multicloud networking services. The practical result, noted by enterprise users, is that WAF rules, DDoS policies, and CDN configurations all live in the same console. There’s no context switching between vendors, no policy drift between your security tool and your delivery tool, and no blind spots at the handoff between them. In the newest product update, anyone already using a Distributed Cloud Load Balancer can enable CDN acceleration with a single click: no rearchitecting, no new deployments. Built-in cacheability insights estimate performance improvement and cost savings before activation, so teams can make informed decisions without guesswork. Target use cases: Where F5 Distributed Cloud CDN fits best There are three primary use-case families for enabling an integrated CDN: Secure apps everywhere (WAAP + CDN): Organizations that need comprehensive web app and API protection with WAF, DDoS, bot defense, unified content delivery under a single policy plane and management console. Modern digital experiences: Dynamic, personalized applications spanning multiple public clouds, edge locations, and on-premises infrastructure that need consistent delivery regardless of where origin workloads live. Multicloud & edge initiatives: Enterprises migrating workloads across cloud providers or deploying edge compute who need a platform that bridges delivery, security, and service mesh without re-platforming for each environment. Visibility & Control: You can’t optimize what you can’t see F5’s Distributed Cloud Platform ships with unified observability that spans delivery performance and security posture. Real-time dashboards expose traffic patterns, cache efficiency metrics, origin health, and security event timelines, all from the same interface used to configure policies. Cache efficiency isn’t a static attribute either. Distributed Cloud CDN provides granular control over cache keys, TTL values, and path or header-based caching rules, enabling teams to optimize hit rates for specific content types and access patterns. Cacheability insights indicate which web apps are candidates for acceleration. For security operations, the edge generates rich telemetry: request rates, blocked attack types, geographic traffic distribution, and bot classification outcomes. This feeds into the same observability layer as performance data, giving teams a single pane of glass rather than separate dashboards for CDN and security. The recently announced F5 Insight capability extends this further, bringing OpenTelemetry-powered observability across BIG-IP, NGINX, and Distributed Cloud Services, consolidating performance and security intelligence across an organization’s entire F5 footprint into actionable, unified visibility. Demo Walkthrough Final thoughts A CDN is no longer an optimization. It’s table stakes for any organization serving digital experiences to a geographically distributed audience. The question isn’t whether to deploy one, but which platform best aligns with the complexity of your architecture and the ambition of your security posture. For organizations operating at the intersection of multicloud delivery, API-driven applications, and enterprise security requirements, Distributed Cloud CDN represents a compelling architectural choice: a platform that treats performance and security not as separate concerns to be stitched together, but as integrated properties of the same edge fabric. The bytes will always need to get from somewhere to your users. F5 makes that journey faster, safer, and smarter. Additional Resources Product information: https://www.f5.com/products/distributed-cloud-services/cdn Technical documentation: https://docs.cloud.f5.com/docs-v2/content-delivery-network/how-to/cdn-mgmt/conf-cache-lb Feature announcement blog: https://www.f5.com/company/blog/f5-distributed-cloud-cdn-faster-apps-one-click-enablement-lower-costs
Announcing the first F5 NGINX Commercial Long-Term Support release
Today, we’re introducing a major change in how NGINX delivers software to enterprise customers: the first F5 NGINX Commercial Long-Term Support (LTS) release. Due to 2026's intensifying threat landscape, platform teams are under increasing pressure to keep critical infrastructure secure while minimizing operational disruption. Frequent upgrades, short support timelines, and constantly evolving features make that challenge harder than it needs to be. NGINX recognizes this burden. For the first time, NGINX customers can now choose: an annual, feature-frozen release with three years of guaranteed support, or the frequent updates they’ve always relied on to stay at the “cutting edge”. Why we introduced LTS Modern application environments, especially Kubernetes and API-driven platforms, demand both reliability and velocity. Until now, achieving that balance has often required trade-offs; frequent upgrades, shorter support windows, or unclear lifecycle expectations. The new NGINX LTS track eliminates those tradeoffs for production environments that value long-term stability. What is in the first LTS Release The inaugural NGINX LTS release launches with F5 NGINX Plus. F5 NGINX Ingress Controller. This is just the beginning-the LTS program is designed to grow, with more NGINX products joining in 2027. A clear support lifecycle model Each NGINX LTS release is supported for 36 months from General Availability and includes critical and high-security fixes, stability bug fixes, maintained third‑party dependencies, and full technical support. LTS releases are feature-frozen to protect production stability. Two Release Paths Long‑Term Support (LTS) Annual, feature‑frozen releases designed for production environments that demand stability. Each LTS release is supported for three years with security patches, stability fixes, and full technical support. Frequent Updates The release path customers have always known- delivering new features and improvements on a regular cadence throughout the year. Only the latest release is supported, and fixes are delivered by upgrading forward. Versioning Model The versioning format follows this structure: <product>.<major>.<minor>.<patch>.<package> Examples: LTS Patch Release: PLS.37.0.0.1 -> PLS.37.0.1.2 37.0 Stays the same since this is still the same LTS Patch increments 0 -> 1, a fix has been added Package increments 1 -> 2, a new build or image is produced Security Release: PLS.37.0.1.2 -> PLS.37.0.2.3 A critical CVE was identified Fixed delivered as another patch release Same LTS Release is used in this case Frequent Update Release: PLS.37.1.0.1 Continuous-release version Bump in minor versions showing new features added The next frequent release version would be 37.2.0.1 LTS (Major) Release PLS.37.0.0.1 -> PLS.38.0.0.1 Major increment 37 -> 38 New LTS Release Feature frozen at GA New 3 year support window Security without forced upgrades All supported LTS releases receive timely fixes for critical and high‑severity CVEs, without requiring customers to adopt new features or breaking changes. Easier planning Customers can standardize on LTS for production, adopt frequent updates for innovation, and align upgrades with annual planning cycles. Getting started You can begin using the first NGINX LTS release today by deploying LTS images and following updated installation and upgrade guidance in NGINX documentation. NGINX Long-Term Support (LTS) Our commitment NGINX LTS delivers enterprise‑grade predictability without slowing innovation. Customers can confidently standardize on LTS for production while continuing to adopt new capabilities on their own terms through continuous releases.AppWorld LATAM 2026 - "Write Your First iRule" Contest
Este anuncio ha sido actualizado para incluir una traducción al español. Puede encontrar las instrucciones en español al final de la publicación. The iRules from Las Vegas and Berlin showcased incredible expertise. For this third iRules Contest, we're shifting focus to encouragement and education for the theme: "Write Your First iRule" Community Contest. We're challenging DevCentral community members attending AppWorld LATAM 2026 to design and build an iRule in a welcoming environment. Whether you are a first time iRules writer, or finding your footing, we can't wait to see what you create. (And don’t worry, it doesn't have to be your literal first iRule ever. It's the spirit of trying something new that counts.) The Challenge Plan out and write an iRule that tackles a use-case for BIG-IP's capabilities. You can: Create a new iRule Reimagine existing codeshare iRules from DevCentral Adapt a 20-lines-or-less iRule from the GitHub iRules Toolbox We value your fresh perspective and newer eyes. As this is a learning opportunity, we also encourage having fun with it. Prizes The submissions will be judged for category awards. All participants receive an exclusive contest t-shirt. Place Prize Category Awards $200/each Technical Excellence Award $500 Participation t-shirt What Makes for a Winning Entry? The 100-point scale judging criteria for submissions is defined below across four categories: Technical Excellence (25 points) Is it well-built and production ready? Consider Works correctly Performance-conscious (efficient, minimal resource impact) Follows security best practices Clean, readable code User Impact (25 points) Would you and other users actually use this? Consider: Solves a real operational problem or technical need need Practical applicability and potential adoption Clear business value Thorough documentation Innovation & Creativity (25 points) Does this solution show original thinking? Consider: Fresh perspective on common challenges Unique approach solving a modern problem Does it inspire collaboration and progress? Theme & Alignment (25 points) Does this iRule reflect your learnings from AppWorld LATAM 2026 and community resources? Consider: Applying the knowledge and skills you've learned Approachable to other new iRules writers Shows your effort to try something new to you Important Dates Contest Opens: June 8th, 2026 at 12:00am Pacific Time Submission Deadline: July 31st, 2026 at 11:59pm Pacific Time Winners Announced: August 14th, 2026 How to Enter The contest is open to all F5 partners, customers, and DevCentral members registered for and in attendance at the contest at AppWorld LATAM 2026, except as described in the Official Rules. Please see the Official Rules for complete terms, including conditions for participation and eligibility. Sign up for DevCentral and join the Community Contests group. Find Hannah or Buu at the Community area if you need any assistance. Build and submit before 11:59pm Pacific Time JULY 31, 2026. Edit your draft entry as much as you like, but once you submit, that’s what we’ll review. Here an example entry pinned at the top of the Contest Entries page you should follow. Make sure to add these tags to your entry: "appworld 2026", "latam", and "irules" as shown on that example. IMPORTANT - You need to join the Contests group to submit your entry. New to iRules? Perfect! We welcome participants at all skill levels. If you’re just getting started, check out our Getting Started with iRules: Basic Concepts guide. This contest is a great opportunity to learn by doing. Feel free to bring your favorite colleagues and AI buddies to help craft your entry. Final Thoughts Post any and all of your contest-related questions in comments below. The iRules Contest has a rich history of surfacing creative solutions from the community. Approaching problems differently inspires some of the best ideas we've seen. We're looking forward to seeing and celebrating what you build. Learn it. Build it. Share it. See you at AppWorld LATAM 2026! AppWorld LATAM 2026 - Concurso “Escribe tu Primer iRule” ¡Hola querida comunidad! El Concurso de iRules está de regreso, con un nuevo estilo. Los iRules de Las Vegas y Berlín demostraron una experiencia increíble. Para este tercer Concurso de iRules, cambiaremos el enfoque hacia el estímulo y la educación con el tema: Concurso Comunitario “Escribe tu Primer iRule”. Estamos desafiando a los miembros de la comunidad DevCentral que asistan a AppWorld LATAM 2026 a diseñar y construir un iRule en un entorno acogedor. Ya sea que estés escribiendo un iRule por primera vez, o apenas estés encontrando tu ritmo, no podemos esperar a ver lo que crees. (Y no te preocupes, no tiene que ser literalmente tu primer iRule. Lo que cuenta es el espíritu de intentar algo nuevo.) El Desafío Planea y escribe un iRule que aborde un caso de uso de las capacidades de BIG-IP. Puedes: Crear un nuevo iRule Reimaginar los iRules existentes del codeshare de DevCentral Adaptar un iRule de 20 líneas o menos del GitHub iRules Toolbox Valoramos tu perspectiva fresca y tu mirada renovada. Como es una oportunidad de aprendizaje, también te animamos a divertirte con ello. Premios Las presentaciones serán evaluadas para los premios por categoría. Todos los participantes reciben una camiseta exclusiva del concurso. Puesto Premio Premios por Categoría $200/cada uno Premio a la Excelencia Técnica $500 Participación camiseta ¿Qué Hace a una Entrada Ganadora? Los criterios de evaluación de 100 puntos para las presentaciones se definen a continuación en cuatro categorías: Excelencia Técnica (25 puntos) ¿Está bien construido y listo para producción? Considera: Funciona correctamente Consciente del rendimiento (eficiente, impacto mínimo en recursos) Sigue las mejores prácticas de seguridad Código limpio y legible Impacto en el Usuario (25 puntos) ¿Tú y otros usuarios realmente lo usarían? Considera: Resuelve un problema operativo real o una necesidad técnica Aplicabilidad práctica y potencial de adopción Valor de negocio claro Documentación exhaustiva Innovación y Creatividad (25 puntos) ¿Esta solución muestra un pensamiento original? Considera: Perspectiva fresca sobre desafíos comunes Enfoque único para resolver un problema moderno ¿Inspira colaboración y progreso? Tema y Alineación (25 puntos) ¿Este iRule refleja tu aprendizaje de AppWorld LATAM 2026 y de los recursos de la comunidad? Considera: Aplicar el conocimiento y las habilidades que has aprendido Accesible para otros nuevos escritores de iRules Demuestra tu esfuerzo por intentar algo nuevo para ti Fechas Importantes Apertura del Concurso: 8 de junio de 2026 a las 12:00 a.m. Hora del Pacífico Fecha Límite de Presentación: 31 de julio de 2026 a las 11:59 p.m. Hora del Pacífico Anuncio de Ganadores: 14 de agosto de 2026 Cómo Participar El concurso está abierto a todos los socios y clientes de F5, y miembros de DevCentral que estén registrados y asistan al concurso en AppWorld LATAM 2026, excepto como se describe en las Reglas Oficiales. Por favor consulta las Reglas Oficiales para los términos completos, incluidas las condiciones de participación y elegibilidad. Regístrate en DevCentral y únete al grupo Community Contests. Busca a Hannah o Buu en el área de la Comunidad si necesitas ayuda. Construye y envía antes de las 11:59 p.m. Hora del Pacífico del 31 de JULIO de 2026. Edita tu borrador tanto como quieras, pero una vez que lo envíes, eso es lo que revisaremos. Aquí tienes un ejemplo de entrada anclado al inicio de la página de Contest Entries que deberías seguir. Asegúrate de agregar estas etiquetas a tu entrada: “appworld 2026”, “latam” e “irules” como se muestra en ese ejemplo. IMPORTANTE - Necesitas unirte al grupo Contests para enviar tu entrada. ¿Nuevo en iRules? ¡Perfecto! Damos la bienvenida a participantes de todos los niveles de habilidad. Si recién estás comenzando, consulta nuestra guía Getting Started with iRules: Basic Concepts. Este concurso es una gran oportunidad para aprender haciendo. Siéntete libre de traer a tus colegas favoritos y a tus compañeros de IA para ayudarte a crear tu entrada. Reflexiones Finales Publica todas tus preguntas relacionadas con el concurso en los comentarios a continuación. El Concurso de iRules tiene una rica historia de hacer emerger soluciones creativas desde la comunidad. Abordar los problemas de manera diferente inspira algunas de las mejores ideas que hemos visto. Esperamos con ansias ver y celebrar lo que construyas. Apréndelo. Constrúyelo. Compártelo.Building and scaling AI apps with the F5 AI Summit
The F5 AI Summit (June 23–25) is focused on one thing: what it takes to run AI in production without things falling apart. If you’re building or operating AI apps, expect practical sessions around the parts that usually cause problems—data flow, security, and scaling. Registration is free and if you follow DevCentral, you’ll be sure to see some familiar faces presenting! TL;DR Here are a few things you'll learn at the AI summit: How to design AI architectures that connect data, models, and traffic in a way that actually works at scale Where performance bottlenecks really live (hint: the data path, not just the model) How to secure AI systems with guardrails, policies, and continuous testing What it takes to scale inference—including GPU utilization and traffic control How to run AI on Kubernetes with routing, observability, and policy built in Agenda Highlights Here are details for some of the sessions you won't want to miss... especially the ones from rockstar DevCentral contributors! The Right Ecosystem for Secure AI Buu Lam will moderate a discussion with Ugur Tigli (CTO of MinIO) and Leon Derczynski (Principal Research Scientist at NVIDIA) to break down how cross-vendor architectures are shaping real-world AI deployments. Find out how integrating storage (MinIO), compute (NVIDIA), and application delivery/security layers enables faster data pipelines and more controlled inference flows. Get insights into AI data movement, system interoperability, and runtime security, especially how partnerships can help close gaps between infrastructure components. Reliability Between Compute and Storage Hunter Smit and Mark Menger walk through why data delivery is now the critical layer in AI infrastructure, especially as workloads shift from training to production inference. Learn how keeping pipelines efficient under load—covering how to optimize data paths so GPUs stay utilized and avoid idle time. See the role of application delivery controllers (ADCs) as a control point for storage traffic (including S3), acting as a front door for AI data movement. Delivering AI on Kubernetes: Model-Aware Routing and Traffic Control with NGINX Michael Kingston focuses on how to run AI workloads on Kubernetes with routing and traffic control designed specifically for inference workloads, highlitings capabilities like model-aware routing and policy enforcement, along with updates to NGINX Gateway Fabric and alignment with Gateway API standards. Get a practical look at how to add observability and control at the ingress layer, giving teams better visibility into AI traffic and more consistent behavior in production environments. See how to turn Kubernetes into a reliable control plane for AI inference. Conclusion Expect a more complete picture of the AI stack—from infrastructure and networking to security and runtime behavior. Registration is free! If you’re responsible for making AI systems reliable, fast, and secure in production, this will give you information you can actually apply.F5 NGINX Plus 37.0 Release now available
We’re thrilled to announce the general availability of F5 NGINX Plus Release 37.0. This release delivers an exceptionally broad set of new features, including the ability to monitor agentic traffic, control configurations remotely via a new API, format error logs as JSON with custom variables, monitor upstream latency with high-fidelity metrics, and much more. Additionally, to assist with lifecycle planning, NGINX Plus 37.0 will be the first release supported under our new long-term support (LTS) policy. Wondering why this is the 37.0 and not R37 release? With the introduction of the LTS policy, we’re changing how NGINX Plus is versioned. As always, NGINX Plus inherits all the latest capabilities from NGINX Open Source, the only all-in-one proven and trusted software web server, load balancer, reverse proxy, content cache, and API gateway. We highly recommend upgrading to the most recent NGINX Plus release to take advantage of all the latest features, fixes and security patches in NGINX Open Source and NGINX Plus. Here’s a summary of the most important updates in 37.0: Agentic Observability: Real-time MCP Traffic Monitoring NGINX Plus is ready for the agentic AI era with new observability capabilities that help teams trace and monitor AI agent activity, spot overly chatty agents, identify error-prone MCP tools, detect MCP server latency, and troubleshoot emerging AI application patterns. Control API Reconfiguring NGINX Plus just got much easier. With the new control API, teams can apply updates through a REST API call without the need to watch error logs to verify that reloads succeeded. The result is simpler config management, cleaner integrations, and CI/CD pipelines that are easier to automate. JSON Error Logs with Custom Variables Error logs are now easier to integrate, analyze, and act on. By exporting error logs in JSON format, teams can reduce the need for regex-heavy parsing or custom scripts, simplifying connections to logging pipelines. New customization options also enable richer debugging workflows, including correlation between individual error and access log entries. Enhanced Upstream Latency Metrics Understanding upstream behavior is essential to delivering fast, reliable applications. With latency histograms, teams can now spot user experience issues, API performance problems, and upstream bottlenecks faster than ever. HTTP/2 Support for Upstream Connectivity Applications can communicate with NGINX over HTTP/2 on the upstream side. This gives teams more flexibility to support modern application architectures without requiring backend services to rely on legacy HTTP protocols. Basic Authentication for HTTP CONNECT Forward Proxy Building on the forward proxy support introduced in NGINX Plus R36, 37.0 makes client authentication easier to implement with new Basic authentication support and a streamlined setup experience for JWT-based authentication. Additional Features and Updates inherited from NGINX Open Source: Encrypted Client Hello Multipath TCP ACME Module: Renewal Information Support Upstream connectivity now defaults to HTTP/1.1 with keepalives enabled New Features in Detail Agentic Observability: Real-time MCP Traffic Monitoring Agentic workloads introduce a new kind of traffic pattern: highly dynamic, non-deterministic tool calls that can fan out across multiple MCP servers and shift behavior over time. With the new Agentic Observability module, NGINX can inspect MCP traffic in real time and report throughput, latency, errors, and traces so you can quickly understand which agents are generating traffic, which MCP tools and servers are bottlenecks, and where failures are originating. To get started with Agentic Observability, configure NGINX Plus to use the mcp.js module from the nginx-mcp-js GitHub repository with the NGINX JavaScript module, the nginx-otel module, and an OpenTelemetry backend. See the repository for setup instructions and a sample configuration. The repository also includes an easy-to-deploy demo environment built with Docker Compose, OpenTelemetry, Prometheus, and Grafana. NGINX Control API NGINX Plus 37.0 introduces a new native Control API that provides programmatic access to runtime control and introspection. The API is capable of displaying the status of worker processes, identifying configuration files currently in memory, and updating NGINX configurations. Historically, NGINX configuration updates were initiated via UNIX signals or the nginx -s reload command-line parameter. While syntax issues in the config are caught with this method, error log inspection is still necessary to determine whether reloads succeeded or failed. For example, binding a listening socket to a privileged port would pass a config syntax test, but ultimately fail if NGINX is not running with root privileges. The new Control API provides real-time status on reloads, including downstream errors, as JSON in response to a configuration reload API call. Enabling the Control API Enable the Control API with care. Although it can be configured to listen for API requests on an external socket, this configuration is strongly discouraged. IMPORTANT: For security reasons, do not expose the API on public ports, the public internet, or any broad network. Enable the control listener when launching NGINX by using the -l command-line argument. For example, to expose the API on the Unix socket /tmp/nginx.sock, run the following command: nginx -l unix:/tmp/nginx.sock Configuring the Control API to listen on a Unix socket is currently the best available method for controlling authorization to make requests, because access can be managed through file permissions. The created Unix socket file is accessible only to the user running NGINX. Accessing the API The API is versioned and exposed under the /1 URI. You can use any HTTP client to access the API. The following examples use curl. To access the API exposed on a Unix socket, run the following command: curl --unix-socket /tmp/nginx.sock http://localhost/1/ Response: [ "control", "nginx" ] Inspecting the Running Configuration The following command returns the configuration currently loaded into memory. This is useful for identifying differences between the configuration NGINX is currently using and the configuration on disk. Any differences may indicate that the configuration on disk was changed but not successfully loaded into memory. curl --unix-socket /tmp/nginx.sock http://localhost/1/control/config Sample response: [ { "name": "nginx.conf", "content": " (...) " }, { "name": "stub.conf", "content": " (...) " } ] Triggering a Reload with Structured Feedback The following command causes NGINX to load the configuration from disk into memory. This is equivalent to running nginx -s reload, with the added benefit that the API can return errors beyond configuration syntax issues. curl --unix-socket /tmp/nginx.sock -X PATCH http://localhost/1/control/config Sample response: { "logs": [ “ .... “, “ .... “ ] } JSON Formatted Error Logs NGINX error logs have always provided valuable operational insight, but their traditional string-based format could make them difficult to parse at scale. Without structured fields or consistent delimiters, teams often had to rely on regexes, custom scripts, or complex heuristics to extract the data they needed. JSON is widely used across modern infrastructure for representing structured data, and support for parsing it is nearly universal across logging, monitoring, and automation tools. With JSON-formatted error logs in NGINX Plus, operators and system integrators can eliminate custom parsers and more easily connect NGINX to CI/CD pipelines, log aggregators, and application monitoring platforms. To enable JSON format in error logs, modify the error_log directive by adding the json parameter. error_log /var/log/nginx/error.json error json; Here’s an example of an error log entry formatted in JSON: { "level": "error", "timestamp": "2026-05-04T10:30:15.042+00:00", "pid": 12345, "tid": 12345, "cnum": 3, "msg": "connect() failed", "client": "192.168.1.10", "server": "example.com", "request": "GET /api HTTP/1.1", "upstream": "http://127.0.0.1:8080/api", "errno": 111, "errtext": "Connection refused" } Custom Error Log Variables NGINX Plus access logs are commonly used to inspect traffic and troubleshoot infrastructure integrations, but correlating access log entries with related error log events has historically been difficult. In many cases, teams had to rely on timestamp comparisons, which became increasingly unreliable on high-volume systems with many concurrent requests. NGINX Plus now makes correlation easier with custom error log variables. Using the new error_log_tag directive, operators can add custom context to error log entries, including request identifiers, host information, static strings, and values derived from incoming headers. This makes it easier to connect an error to the request, client, tenant, service, or workflow that produced it. NGINX Plus also adds the $time_iso8601_ms variable, which can be used in access logs to improve timestamp-based correlation with error logs. The error_log_tag directive accepts text-based NGINX variables and complex expressions, and outputs custom data in both JSON and text-formatted error log entries. In the following example, the directive adds a correlation identifier to each error log entry: server { error_log_tag request_id $request_id; error_log_tag x_request_id $http_x_request_id; location /api/ { proxy_pass http://backend; } } Enhanced Upstream Latency Metrics Low-latency application delivery is critical to delivering fast, reliable user experiences. Previously, NGINX Plus reported per-peer upstream latency in milliseconds as a moving average across the full request lifecycle, including the TCP handshake, TLS handshake, request send, and response read. While useful, averages can obscure important details, such as latency spikes, long-tail behavior, or patterns affecting only a subset of requests. With NGINX Plus 37.0, teams can now view latency histograms for each upstream peer. This provides a more detailed view of upstream performance, making it easier to understand latency distributions, analyze percentiles, identify outliers, and correlate upstream behavior with other NGINX Plus metrics and insights. Latency histogram data is available through the NGINX Plus API, can be exported to external observability systems using the Prometheus-njs exporter module, and can be viewed directly in the NGINX Plus dashboard for quick, at-a-glance insight, as shown below. NGINX Plus dashboardshowing new upstream latency data For deeper diagnostics, teams can export latency histogram data to Prometheus and visualize it in Grafana. The example below shows request density by latency bucket alongside p50, p95, and p99 response times, request rates, and upstream errors. By comparing latency distributions with throughput and error rates, operators can more quickly determine whether performance issues are driven by traffic spikes, upstream behavior, or HTTP errors. The following configuration example shows how to enable upstream latency histograms. To collect histogram data, define a shared memory zone in the upstream block. This enables upstream-level telemetry in NGINX Plus, including the new response_time_hist field. http { upstream my_backend { zone my_backend 64k; server backend1.example.com:8080; server backend2.example.com:8080; } server { listen 443 ssl; location / { proxy_pass http://my_backend; } # Expose the Nginx Plus API for metrics retrieval location /api/ { api write=on; allow 127.0.0.1; # restrict to localhost only deny all; } } } To access upstream latency histograms through the NGINX Plus API, use curl to issue the following REST call and pipe the response to jq for easier formatting: curl -s http://localhost/api/9/http/upstreams/my_backend | jq HTTP/2 Support for Upstream Connectivity Previously, NGINX Plus supported upstream HTTP connections using HTTP/1.0 or HTTP/1.1. HTTP/1.1 provided important performance benefits such as keepalive connections, but upstream applications still needed to communicate with NGINX using legacy HTTP protocols. NGINX Plus 37.0 introduces support for proxying and load balancing HTTP/2 traffic directly to upstream servers, allowing teams to extend HTTP/2 deeper into the application delivery path. Use the following example configuration to enable HTTP/2 connectivity to upstreams: upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 2 proxy_set_header Connection ""; ... } } Note: The current implementation of HTTP/2 connectivity to upstreams does not support request multiplexing. Basic Authentication for HTTP CONNECT Forward Proxy NGINX Plus R36 introduced support for configuring NGINX Plus as a forward proxy using the HTTP CONNECT protocol. In 37.0, we’re building on that capability with support for Basic authentication for HTTP CONNECT requests. This gives teams another straightforward option for authenticating clients before allowing them to establish proxy tunnels through NGINX Plus. Use the following example configuration to enable Basic authentication for the HTTP CONNECT forward proxy: server { listen 3128; auth_basic "my proxy"; auth_basic_user_file conf/htpasswd; tunnel_pass; } Long-term Support (LTS) Starting with NGINX Plus 37.0, select releases will be certified as Long-Term Support (LTS) releases. For more details, read about the LTS program and what it means for support policies across LTS and non-LTS releases. The introduction of LTS releases also changes how NGINX Plus is installed, versioned, and updated. Customers should follow the NGINX Plus installation guide carefully and note the updated versioning scheme. Going forward, non-LTS releases will no longer increment the main NGINX Plus release number. For example, the non-LTS release following 37.0 will be versioned as 37.1, while the next LTS release will be versioned as R38.0. Module and package versions will follow the same scheme. For example, NGINX Plus R36 used a package version such as nginx-plus 36-1~noble; starting with 37.0, the package version format changes to nginx-plus 37.0.0-1~noble. NGINX Plus package repository paths are also changing. To pin repositories to the 37.0 release, use /plus/R37.0/... in the repository URI instead of the previous /plus/R36/... format. In some contexts, releases may be referenced by their full version names. For example, the official designator for the 37.0 release is PLS.37.0.0.1, with the final number representing the initial package release. More information can be found about the meaning of version number in the LTS program blog post. Important: If you intend to stay on the LTS upgrade path, we recommend pinning to the /plus/LTS URI. This helps ensure that future upgrades remain on LTS releases and do not unintentionally move your deployment to a non-LTS release. Additional Enhancement Available in NGINX Plus 37.0 NGINX Plus 37.0 is based on the NGINX 1.29.8 mainline release and inherits all functional changes, features, and bug fixes made since NGINX Plus R36 was released (which was based on the 1.29.3 mainline release). For the full list of new changes, features, bug fixes, and workarounds inherited from recent releases, see the NGINX changelog . Changes to Platform Support Added Platforms Support for the following platforms has been added: Alpine Linux 3.23 FreeBSD 15 Ubuntu 26.04 Note: Ubuntu is ending support for older variants of amd64 HW on Ubuntu 26.04. See more: https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/supported-architectures/#architecture-variants NGINX Plus will be supported on amd64v3. Support on older hardware variants can be achieved by running older Ubuntu LTS releases (e.g. Ubuntu 24.04 LTS). Removed Platforms Support for the following platforms has been removed: Alpine Linux 3.20 – Reached End of Support on April 1st, 2026 Deprecated Platforms Support for the following platforms will be removed in a future release: Alpine Linux 3.21 Amazon Linux 2 FreeBSD 13 F5 NGINX in F5’s Application Delivery & Security Platform NGINX One is part of F5’s Application Delivery & Security Platform. It helps organizations deliver, improve, and secure new applications and APIs. This platform is a unified solution designed to ensure reliable performance, robust security, and seamless scalability for applications deployed across cloud, hybrid, and edge architectures. NGINX One is the all-in-one, subscription-based package that unifies all of NGINX’s capabilities. NGINX One brings together the features of NGINX Plus, F5 NGINX App Protect, and NGINX Kubernetes and management solutions into a single, easy-to-consume package. NGINX Plus, a key component of NGINX One, adds features to open-source NGINX that are designed for enterprise-grade performance, scalability, and security. Follow this guide for more information on installing and deploying NGINX Plus 37.0 or NGINX Open Source.F5 NGINX Plus R36 Release Now Available
We’re thrilled to announce the availability of F5 NGINX Plus Release 36 (R36). NGINX Plus R36 adds advanced capabilities like an HTTP CONNECT forward proxy, richer OpenID Connect (OIDC) abilities, expanded ACME options, and new container images packaged with popular modules. In addition, NGINX Plus inherits all the latest capabilities from NGINX Open Source, the only all-in-one software web server, load balancer, reverse proxy, content cache, and API gateway. Here’s a summary of the most important updates in R36: HTTP CONNECT Forward Proxy NGINX Plus can now tunnel HTTP traffic via the HTTP CONNECT method, making it easy to centralize egress policies through a trusted NGINX Plus server. Advanced features enable capabilities that limit proxied traffic to specific origin clients, ports, or destination hosts and networks. Native OIDC Support for PKCE, Front-Channel Logout, and POST Client Authentication We’ve made additional enhancements to the popular OpenID Connect module by adding support for PKCE enforcement, the ability to log out of all applications a client was signed in to, and support for authenticating the OIDC client using the client_secret_post method. ACME Enhancements for Certificate Automation Certificate automation capabilities are more powerful than ever, as we continue to make improvements to the ACME (Automatic Certificate Management Environment) module. New features include support for the TLS-ALPN-01 challenge method, the ability to select a specific certificate chain, IP-based certificates, ACME profiles, and external account bindings. TLS Certificate Compression High-volume or high-latency connections can now benefit from a new capability that optimizes TLS handshakes by compressing certificates and associated CA chains. Container Images with Popular Modules Container images now include our most popular modules, making it even easier to deploy NGINX Plus in container environments. Alongside the previously included njs module, images now ship with the ACME, OpenTelemetry Tracing, and Prometheus Exporter modules. Key features inherited from NGINX Open Source include: Support for 0-RTT in QUIC Inheritance control for headers and trailers Support for OpenSSL 3.5 New Features in Detail HTTP CONNECT Forward Proxy NGINX Plus R36 adds native HTTP CONNECT support via a new ngx_http_tunnel_module that enables NGINX Plus to operate as a forward proxy for outbound HTTP/HTTPS traffic. You can restrict clients, ports, and hosts, as well as which networks are reachable via centralized egress policies. This new capability allows you to monitor outbound connections through one or more NGINX Plus instances instead of relying on separate proxy products or DIY open source projects. Why it matters Enforces consistent egress policies without introducing another proxy to your stack. Centralizes proxy rules and threat monitoring for outbound connections. Reduces the need for custom modules or sidecar proxies to tunnel outbound TLS. Who it helps Platform and network teams that must route all outbound traffic through a controlled proxy. Security teams that want a single place to enforce and audit egress rules. Operators consolidating L7 functions (inbound and outbound) on NGINX Plus. The following is a sample forward proxy configuration that filters ports, destination hosts and networks. Note the requirement to specify a DNS resolver. For simplicity, we've configured a popular, publicly available DNS. However, doing so is not recommended for certain production environments, due to access limitations and unpredictable availability. num_map $request_port $allowed_ports { 443 1; 8440-8445 1; } geo $upstream_last_addr $allowed_nets { 52.58.199.0/24 1; 3.125.197.172/24 1; } map $host $allowed_hosts { hostnames; nginx.org 1; *.nginx.org 1; } server { listen 3128; resolver 1.1.1.1; # unsafe tunnel_allow_upstream $allowed_nets $allowed_ports $allowed_hosts; tunnel_pass; } Native OpenID Connect Support for PKCE, Front-Channel Logout, and POST Client Authentication R36 extends the native OIDC features introduced in R34 with PKCE enforcement, front-channel logout, and support for authenticating clients via the client_secret_post method. PKCE for authorization code flow can now be auto-enabled for a configured Identity Provider when S256 is advertised for “code_challenge_methods_supported” in federated metadata. Alternatively, it can be explicitly toggled with a simple directive: pkce on; # force PKCE even if the OP does not advertise it pkce off; # disable PKCE even if the OP advertises S256 A new front-channel logout endpoint lets an Identity Provider trigger a browser-based sign-out of all applications that a client is signed in to. oidc_provider okta_app { issuer https://dev.okta.com/oauth2/default; client_id <client_id>; client_secret <client_secret>; logout_uri /logout; logout_token_hint on; frontchannel_logout_uri /front_logout; userinfo on; } Support for client_secret_post improves compatibility with identity providers that require POST-based client authentication per OpenID Connect Core 1.0. Why it matters Brings NGINX Plus in line with modern identity provider expectations that treat PKCE as a best practice for all authorization code flows. Enables reliable logout across multiple applications from a single identity provider trigger. Makes NGINX Plus easier to integrate with providers that insist on POST-based client authentication. Who it helps Identity access management and security teams standardizing on OIDC and PKCE. Application and API owners who need consistent login and logout behavior across many services. Architects integrating with cloud identity providers (Entra ID, Okta, etc.) that require specific OIDC patterns. ACME Enhancements for Certificate Automation Building on the ACME support shipped in our previous release, NGINX Plus R36 incorporates new features from the nginx acme project, including: TLS-ALPN-01 challenge support Selection of a specific certificate chain IP-based certificates ACME profiles External account bindings These capabilities align NGINX Plus with what is available in NGINX Open Source via the ngx_http_acme_module. Why it matters Lets you keep more of the certificate lifecycle inside NGINX instead of relying on external tooling. Makes it easier to comply with CA policies and organizational PKI standards. Supports more complex environments such as IP-only endpoints and specific chain requirements. Who it helps SRE and platform teams running large fleets that rely on automated certificate renewal. Security and PKI teams that need tighter control over certificate chains, profiles, and CA bindings. Operators who want to standardize on a single ACME implementation across NGINX Plus and NGINX Open Source. TLS Certificate Compression TLS certificate compression introduced in NGINX Open Source 1.29.1 is now available in NGINX Plus R36. The ssl_certificate_compression directive controls certificate compression during TLS handshakes, which remains off by default and must be explicitly enabled. Why it matters Reduces the size of TLS handshakes when certificate chains are large. Can optimize performance in high connection volume or high-latency environments. Offers incremental performance optimization without changing application behavior. Who it helps Performance-focused operators running services with many short-lived TLS connections. Teams supporting mobile or high-latency clients where every byte in the handshake matters. Operators who want to experiment with handshake optimizations while retaining control via explicit configuration. Container Images with Popular Modules Included Finally, NGINX Plus R36 introduces container images that bundle NGINX Plus with commonly requested first-party modules such as OpenTelemetry (OTel) Tracing, ACME, Prometheus Exporter, and NGINX JavaScript (njs). Options include images with or without F5 NGINX Agent and those running NGINX in privileged or unprivileged mode. Additionally, a slim NGINX Plus–only image will be made available for teams who prefer to build bespoke custom containers. Additional Enhancements Available in NGINX Plus R36 Upstream-specific request headers Dynamically assigned proxy_bind pools Changes Inherited from NGINX Open Source NGINX Plus R36 is based on the NGINX 1.29.3 mainline release and inherits all functional changes, features, and bug fixes made since NGINX Plus R35 was released (which was based on the 1.29.0 mainline release). For the full list of new changes, features, bug fixes, and workarounds inherited from recent releases, see the NGINX changes . Changes to Platform Support Added Platforms Support for the following platforms has been added: Debian 13 Rocky Linux 10 SUSE Linux Enterprise Server 16 Removed Platforms Support for the following platforms has been removed: Alpine Linux 3.19 – Reached End of Support in November 2025 Deprecated Platforms Support for the following platforms will be removed in a future release: Alpine Linux 3.20 Important Warning NGINX Plus is built on the latest minor release of each supported operating system platform. In many cases, the latest revisions of these operating systems are adapting their platforms to support OpenSSL 3.5 (e.g. RHEL 9.7 and 10.1). In these situations, NGINX Plus requires that OpenSSL 3.5.0 or later is installed for proper operation. F5 NGINX in F5’s Application Delivery & Security Platform NGINX One is part of F5’s Application Delivery & Security Platform. It helps organizations deliver, improve, and secure new applications and APIs. This platform is a unified solution designed to ensure reliable performance, robust security, and seamless scalability for applications deployed across cloud, hybrid, and edge architectures. NGINX One is the all-in-one, subscription-based package that unifies all of NGINX’s capabilities. NGINX One brings together the features of NGINX Plus, F5 NGINX App Protect, and NGINX Kubernetes and management solutions into a single, easy-to-consume package. NGINX Plus, a key component of NGINX One, adds features to NGINX Open Source that are designed for enterprise-grade performance, scalability, and security. Follow this guide for more information on installing and deploying NGINX Plus R36 or NGINX Open Source.AppWorld Berlin 2026 – iRules Contest Winning Results
The second iRules Contest of the year wrapped up at AppWorld Berlin this week. This contest was looking towards the future, challenging participants to write an iRule that goes beyond BIG-IP’s built-in capabilities. The theme, using WebSockets or the Message Routing Framework, inspired iRules preventing abuse and intrusion. At the heart of it, we’ve loved the creative innovation of the iRules written for this years’ contests. The AppWorld Berlin iRules Contest submissions were inspiring. Across the board, judges’ feedback on the top contenders shared a common theme: these solutions are interesting. The winning iRules were well-documented, easy to understand, with clear potential value for production use. Without further ado, we’re proud to announce the winners of the AppWorld Berlin iRules Contest: Grand Prize Winner - Goerle_dev Rule: WS-Exfil-Shield: Catching What WAFs Miss After the 101 Handshake Summary This iRule addresses gaps in traditional WAFs by extending session-level, behavior-based threat detection to WebSocket traffic using real-time inspection within F5 BIG-IP. Detection operates in two stages; an initial timing-based heuristic is followed by payload validation using AI. Malicious actors are either blocked or routed to a honeypot for isolation and further observation. This iRule closes the gap that openly documented by major WAF vendors, post-handshake Websocket blind spot, with a practical, SIEM-ready enforcement. 2nd Place - Injeyan_Kostas Rule: WS-Shield: WebSocket Abuse Detection & Adaptive Enforcement Gateway Summary This iRule addresses securing WebSocket traffic by enabling real-time, behavior-based enforcement in F5 BIG-IP to proportionally mitigate abusive patterns without application changes. It introduces a behavioral enforcement engine designed to secure WebSocket traffic with adaptive, real-time mitigation without requiring application changes. Rather than relying on static thresholds, the system dynamically responds to behavior. Clean traffic naturally recovers, while abusive patterns escalate through enforcement tiers until they are cut off. This allows it to detect subtle, persistent attacks that traditional rate limiting often misses. In testing, the iRule identified and disconnected a bot sending repetitive payloads every half second, without triggering a rate threshold. The iRule adds an extensible, behavior-driven security layer that enables adaptable defenses with minimal investment, despite optional external dependencies. 3rd Place - Robb-Fr Rule: Generic iRule Based on Datagroup Parsing Summary This iRule addresses the complexity of migrating large numbers of Apache virtual hosts by centralizing flexible traffic routing and redirection logic within F5 BIG-IP using simple, extensible datagroups. It turns input into a simple form into a datagroup entry that CREATES iRULES for things like redirects, pools, error pages, rewrites, and more. This iRule is accessible to a wide range of F5 practitioners, as F5 expertise is not required. There are no direct iRule edits, and no way for them to break the device. This iRule lowers operational friction by enabling non-NetOps teams to manage complex traffic flows, improving agility during large-scale migrations. Category Awards The 20 Lines or Less Award - Kai_Wilke In honor of Colin Walker - short on lines, long on legend. The scroll bar never stood a chance. Rule: SUPER-WEBSOCKET-HANDSHAKE-LOGGER™® (SWHL) iRule The Layered Defense Award - ChristianEssel For elegant use of nested virtual servers to solve problems the apps won't. Rule: Layered Virtual ICAP Scanning Solution Gratitude A big thank you to all contestants who participated in the AppWorld Berlin iRules Contest. Your creativity, innovation, and willingness to share your ideas continue to push the community forward. Thank you to our judges: John_Alam Joel_Moses Moe_Jartin Chris_Miller Michael_Waechter dennypayne Kevin_Stewart Marcus-f5 SimonKowallik Sorin_Boiangiu Steve Scott Thank you to the DevCentral community. We learn together, grow together, and inspire each other every day. What's Next? Innovation and Creativity have been a key part of the contest rubric. We’re leaning into it, too. As we plan more contests for the year, we’re looking beyond iRules, with potential to expand to all programmability. The future is coming for us all; let’s greet it and move forward together.
