BIG-IQ CM Logs Not Receiving
Once the disk space has been released, you need to rectify the condition below by running the provided command # for idx in $(curl -ks -u admin:admin https://localhost:9200/_cat/indices | awk '{print $3}'); do if [ $idx != ".opendistro_security" ]; then curl -k -u admin:admin -X PUT "https://localhost:9200/$(echo $(echo $idx | cut -d\+ -f1)*)/_settings?pretty" -H 'Content-Type: application/json' -d'{"index.blocks.read_only_allow_delete": false}'; fi; doneAppWorld LATAM 2026 - "Write Your First iRule" Contest
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!
Need BIG-IP VE Lab License for Personal Study/Learning
Hi F5 Community, I am setting up a personal home lab to learn. F5 BIG-IP for certification preparation. I have deployed BIG-IP VE but need a lab license. to access the management GUI. Could anyone help me get a free lab/evaluation? license for personal learning purposes? Thank you.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.
CLI Tool for BIG-IP - f5 cli
I'm releasing a CLI tool for inspecting and manipulating configuration. It’s a whole suite of tools in one, from `f5 grep` through to the advanced jq-style `f5 query` This tool is based on my last 20 years of using and abusing BIG-IP, and the ideas behind all the tooling I built along the way. https://github.com/bitwisecook/tcl-lsp/blob/main/INSTALL-cli.md https://github.com/bitwisecook/tcl-lsp/tree/main/docs/references/f5_query https://github.com/bitwisecook/tcl-lsp/tree/main/samples/for_f5_query there’s lots of documentation, worked examples, KCS style docs covering it, contending help including shell completion support. It requires Python 3.10+ for now. feel free to discuss here or raise issues on GitHub. This is part of my much larger work on an LSP, MCP, and AI tooling for all editors and harnesses to improve f5 tooling. The `query` verb can do stuff like $ f5 query --name ltm=ltm.conf --name gtm=gtm.conf --merge --raw ' $gtm.gtm.wideip[] as $w | $w.pools[] as $gp | $gp.members[] | last(split(., ":")) as $vspath | $ltm.ltm.virtual[] | select(."full-path" == $vspath) as $vs | $vs.pool.members[] | tsv($w.name, $gp.name, $vs.name, $vs.pool, .address, port(.name)) ' ltm.conf gtm.conf | sort -u api.example.com api_app_pool api_vs /Common/api_pool 10.0.2.20 8443 api.example.com api_app_pool api_vs /Common/api_pool 10.0.2.21 8443 www.example.com example_app_pool web_vs /Common/web_pool 10.0.1.10 80 www.example.com example_app_pool web_vs /Common/web_pool 10.0.1.11 80
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 choose an annual, feature frozen release with three years of guaranteed support, while continuing to access rapid innovation through frequent Continuous Releases (CRs). 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 is expected to be added shortly after launch, with F5 WAF for NGINX and NGINX as a Service planned for the back half of the calendar year, followed by additional NGINX components. 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. Dual Lane Release Model Long‑Term Support (LTS) Annual, feature‑frozen releases designed for production environments. Each LTS is supported for three years with security patches, stability fixes, and full technical support. Continuous Releases (CR) Regular releases that deliver new features and improvements throughout the year. Only the latest CR 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 Minor Release PLS.37.1.0.1 Continuous-release version Bump in minor versions showing new features added The next continuous-release version would be R37.2.0.1 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 CR 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.Along time ago in a land far far away...
I discovered F5 networks, learnt the product suite , taught the training, became an MVP and started an online discussion group in Telegram which was popular back in the day. The world has changed and security has become far more of an issue than it ever was. It seemed the only way to access a resource reliably outside the business was by using the web. So now everthing uses it and its various protocols so pass messaging back and forth around the world. From SAML to OAuth it is all built on the same basic framework and that is why my little commumity had to evolve. I present to you a new space, accessed over the web, cloud backed and accessible to everyone. Complimentary to the user expereience here just more an interactive level. Feel free, feel welcome and enjoy. https://discord.gg/YzDtk9HXXn Only a browser is required for the desktop, choose "Open In Browser". There is an app available for mobile platforms. Feel free to provide any feedback in the suggestions channel on the site or even to this post.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.
