OpenResty Inc.

OpenResty XRay 26.7.15 is out! The theme of this release: bringing AI into the diagnostics workflow. New AI Assistant — diagnostics through conversation: • Query product docs and system info, select and run analyzers, review results — all from a single conversational interface that consolidates the entire "read docs → pick analyzer → run → inspect" loop • Sessions are searchable, renamable, and shareable as read-only links, making it easy to preserve diagnostic context for team review AI-powered interpretation: • AI can now interpret analysis tasks and reports, surfacing key findings from dense flame graphs and low-level metrics • Interpretations are viewable and shareable on the bulletin page MCP server interface & SKILL support for AI agent reasoning loops: • AI agent clients like Claude Code, Codex, and Cursor can connect to OpenResty XRay directly • Agents can autonomously run analyzers, read results, and decide which analyzers to run next — forming an analyze → interpret → re-analyze reasoning loop that progressively narrows down root causes • Plug OpenResty XRay’s diagnostic capabilities into your everyday AI-assisted coding and ops workflows Also in this release: selectable flame graph direction, tcmalloc symbol recognition, plus fixes for Helm/Kubernetes deployment, application metric reporting, and vulnerability scanning. Recommended upgrade for all users. https://lnkd.in/gStMMQn6

After a long stretch of work, we finally have results from running open-weight models against our internal OpenResty Coding Evals benchmark. Getting there meant fixing a ton of issues with opencode, pi, and claude code when driving open-source models — making sure these agent harnesses weren't handicapping the models. GLM 5.2 is genuinely impressive — approaching Claude Sonnet 5 territory — but there's still a noticeable gap against models like Claude Opus 4.8. Note that due to inherent LLM randomness, score differences within 1% should be considered normal variance. First image: quality scores. Second image: average total latency per task across agents. Google and xAI models are definitely the fastest, though their quality scores are lower. Still waiting for Kimi K3, Qwen 3.8 Max, and DeepSeek V4 stable to publicly release all model weights. Once they do, we'll add them to the eval. Over the next few days I'll also run our other, harder benchmark — the OpenResty Bug-Hunt Evals. Stay tuned!

When a live stream crashes during a major event like the World Cup, it's usually not because you didn't buy enough bandwidth. Ops teams doing post-mortems keep finding the same root cause: origin-pull architecture spiraling out of control. When viewership explodes by orders of magnitude, the load on your origin doesn't grow linearly — it amplifies. If the request collapsing layer isn't built right, no amount of bandwidth solves a deduplication failure. The other trap that's consistently underestimated is cost: post-event traffic bills growing faster than revenue. Managed CDNs charge per byte — every second of peak is priced linearly. Private CDNs charge by capacity tier, decoupling peak cost from total volume delivered. Origin spend becomes completely independent of audience size. Should you bring your delivery layer in-house? The case rests on exactly these two judgments — not comparing feature checklists, but making a foundational choice about architectural control and cost structure. Our team put together a technical analysis on both. Link in the comments. Our commercial product recently helped power live streams for major sporting events at this scale. https://lnkd.in/gUiKEAkv

During large-scale live events like the FIFA World Cup, a single CDN node can handle tens to hundreds of gigabits of traffic. In this environment, a well-tuned origin-pull and caching strategy is the foundation of streaming stability. CDN platforms routinely serve multiple tenants side by side, making policy changes and parameter tuning a daily reality. Native Nginx offers robust caching and origin-pull capabilities, but every configuration update requires a reload, and each reload introduces the risk of stuttering or stream interruption. In a high-concurrency scenario like the World Cup, that risk can be catastrophic. OpenResty Edge builds on Nginx's proven foundation with deep enhancements: dynamic configuration delivery and zero-downtime updates. Adjustments to caching rules, origin-pull policies, and other streaming-related settings take effect instantly, no reload required, no impact to active playback sessions. Teams can adapt to live event conditions in real time, dramatically improving the viewing experience at scale. In our latest article, we provide a full step-by-step guide to configuring live streaming on OpenResty Edge. https://lnkd.in/gy_VZeyh

🚀 OpenResty 1.31.1.1 is officially out! This is a major feature release packed with powerful new capabilities, significant security improvements, and broad ecosystem upgrades. Here are the key highlights: 1️⃣ Nginx Core & OpenSSL Upgrade: Upgraded from Nginx 1.29.2 to 1.31.1 and OpenSSL from 3.5.5 to 3.5.6, delivering the latest performance improvements, protocol support, and security hardening at the foundation level. 2️⃣ lua-nginx-module v0.10.31: A landmark update introducing the new `precontent_by_lua` and `proxy_ssl_verify_by_lua*` directives, APIs for retrieving server random and master secrets, `tcpsock:getsslsession`, custom trusted CA store support for cosocket TLS handshakes, and new TCP socket options `keepintvl`/`keepcnt`. Several critical crash fixes around QUIC connection teardown, worker shutdown, and SSL session caching are also included. 3️⃣ stream-lua-nginx-module v0.0.19, lua-resty-core v0.1.34rc2 & LuaJIT v2.1-20260415: New `proxy_ssl_certificate_by_lua` directive, `serversslhandshake` on downstream sockets, `tcpsock:settrustedstore()` for per-handshake trusted CA configuration, and a suite of new SSL FFI APIs. LuaJIT introduces `ffi.abi("dualnum")` with numerous fixes for ARM64, s390x, FFI, and the JIT compiler, significantly boosting cross-platform stability and runtime performance. 4️⃣ Ecosystem Component Upgrades: `lua-resty-mysql` adds ed25519 authentication support, `lua-resty-string` gains AES-256-CTR bindings, `lua-cjson` adds comment decoding and indented encoding options, `xss-nginx-module` gains dynamic module build support, and more — continuing to strengthen the OpenResty ecosystem. We strongly recommend all users upgrade to take advantage of the latest features, security improvements, and bug fixes.

OpenResty 1.29.2.5 is officially out! This is a focused security release designed to address a recently disclosed vulnerability and keep your infrastructure protected. Here’s what’s included in this version: - Upstream Nginx Security Patch: Backported the latest critical security fix from Nginx, addressing a buffer overflow vulnerability in `ngx_http_rewrite_module` (CVE-2026–9256). This issue could potentially allow attackers to execute arbitrary code or cause service disruption through specially crafted rewrite rules. This release is a rapid response to the recently disclosed core Nginx vulnerability. We strongly recommend that all users on the 1.29.2.x series upgrade immediately to mitigate potential exploit risks.

🚀 OpenResty 1.29.2.4 is officially out!  This is a critical security-focused release designed to address recent vulnerabilities and harden your infrastructure. Here are the key updates in this version: 1️⃣ Upstream Nginx Security Patches: Fully synced with the latest Nginx security fixes. This includes a critical fix for a buffer overflow vulnerability in ngx_http_rewrite_module (CVE-2026-42945), alongside multiple out-of-bounds read fixes in the charset, SCGI, and uwsgi modules. 2️⃣ HTTP/3 & OCSP Security Hardening: Resolved a key HTTP/3 address spoofing vulnerability (CVE-2026-40460) and a use-after-free risk within the OCSP resolver (CVE-2026-40701), significantly boosting system robustness under complex network protocols. 3️⃣ Dedicated Security Maintenance: This release is a rapid response to recently disclosed core Nginx vulnerabilities. We strongly recommend that all users on the 1.29.2.x series upgrade immediately to mitigate potential exploit risks. 🔗 Relevant links can be found in the comments below. #OpenResty #WebServer #Nginx #Cybersecurity #OpenSource

We recently released version 26.5.11 of OpenResty XRay. The full release announcement can be found in the comments section. The three major highlights are: 1) Enterprise-grade identity and multi-tenant management — The cloud edition now supports OIDC sign-in, so you can tie XRay into your company-wide identity provider with less friction and stronger alignment on security policies. The self-hosted edition now lets you rename customers and set tenant names at initialization, giving you more flexibility when onboarding and operating multiple tenants. 2) D language coverage — We’ve added end-to-end analysis for D applications. On top of that, there are two new flame-graph-style analyzers that focus on garbage-collection behavior: they make it easier to see where new GC allocations concentrate and how object sizes add up, so you can chase down memory hotspots faster instead of staring at only a coarse “memory looks high” number. 3) Deeper system-level diagnostics — Three new analyzers extend what you can see without digging through raw counters everywhere: `lj-gc-state` — LuaJIT garbage collector: surfaces collector settings and live runtime state in one place, which matters when you tune GC-sensitive stacks such as OpenResty/LuaJIT. `sys-nf-conntrack` — kernel connection tracking: lays out the configuration and health of the subsystem that tracks every network connection, which helps when workloads are bound by connection churn or strange tracking-table behavior. `sys-softirq-stats` — softirq behavior: summarizes softirq-driven load with practical tuning hints, addressing cases where concurrency looks fine at the application layer but the machine still feels capped by kernel-side work. OpenResty XRay is our online application analysis platform based on dynamic tracing technology. It can non-intrusively analyze, in real time, a wide variety of issues across different types of applications — including high CPU usage, CPU underutilization, excessive memory consumption or leaks, high disk I/O, long latency, exceptions, crashes, network issues, and security vulnerabilities — without touching the source code or making any modifications to the target application.

We're excited to announce the release of OpenResty Edge 26.6.8! Here are the core highlights of this update: - Kernel-level IP Blocking: Intercept malicious traffic directly at the OS kernel layer for higher performance and lower overhead. - SSL JA4 Fingerprinting: Retrieve client JA4 fingerprints via page rule conditions to enable more precise security policies. - LDAPS Support: More secure and reliable data transmission for enterprise identity authentication scenarios. - AWS EKS Dynamic Tokens: Simplified K8s cluster integration and authentication in cloud-native environments. - WAF Paranoia Level Control: Flexibly tune rule inspection intensity to strike the right balance between security and business compatibility. We also optimized IP address matching performance (upgraded from trie to radix tree), reduced domain update latency, added auto-restart support for the oredge-node systemd service, and fixed several bugs. Full release notes in the comments. #OpenRestyEdge #APIGateway #WAF #OpenResty

Last month, the industry was buzzing with a technical disaster: PocketOS, a US-based car rental SaaS provider, suffered a total system collapse. Their AI agent accidentally triggered a maximum-privilege API, wiping the production database in an instant. Because the backups were stored on the same volume as the primary database, they were also destroyed, rendering the data completely unrecoverable. This incident proves once again that in today’s highly automated world, disaster strikes in milliseconds. This is especially true for gateway systems, where routing rules, security policies, and application configurations are all stored in the database; once lost, no business system can help you reverse-engineer them. While this was not an OpenResty Edge customer case, the automation risks it exposed are universal. To help users completely avoid such extreme risks, OpenResty Edge was designed from the ground up with built-in multi-layer security isolation and data redundancy mechanisms. To this end, we have released the new "OpenResty Edge Data Protection Guide: From Scheduled Backups to Automatic Failover," detailing three levels of data protection for OpenResty Edge: - Scheduled Backups (Cold Backup) – The absolute bottom line against misoperation and malicious destruction; a must for all environments. - Primary-Secondary Streaming Replication – Guards against single points of failure to ensure service continuity; recommended for all production environments. - Automatic Failover Cluster – Achieves automatic switching within seconds; ideal for mission-critical services with the highest availability requirements. In this article, we systematically compare scheduled backups, streaming replication, and failover clusters, providing pragmatic selection advice. Link to the full article is in the comments section. #OpenRestyEdge #DatabaseBackup #AISecurity