NGINX
Enterprise application delivery, traffic management and security software.
Available information varies by company and source.
Profile record updated:
Company facts
- Official name
- Nginx, Inc.
- Entity type
- COMPANY
- Founded
- 2011
- Headquarters
- United States
- Market role
- B2B SaaS Provider
- Official website
- nginx.com
What NGINX does
NGINX uses an open core infrastructure software model. The open source NGINX distribution drives broad adoption among developers and operations teams, while commercial products package enterprise features, support, management, security and managed cloud deployment for paying organisations. Value is created by reducing application delivery complexity, improving availability and standardising traffic control across hybrid and multicloud estates. Revenue is generated through enterprise subscriptions, SaaS platform access, cloud marketplace consumption charges, security add-ons and professional services.
Category differentiation
This entity is the commercial software business behind NGINX and its enterprise products, not merely the open source project alone. It is infrastructure and application delivery software, not an adtech, martech or digital publishing company.
Strategic context
AI-supported assessment from the existing company research; distinguish interpretation from sourced facts.
NGINX is the commercial maintainer of the NGINX web server and a provider of enterprise application delivery and security software. It sells products spanning load balancing, reverse proxying, API gateway, Kubernetes ingress, observability, centralised instance management, web application firewall and denial-of-service protection. The company also offers managed cloud services such as NGINXaaS for Azure and Google Cloud. NGINX operates as a wholly owned subsidiary and business unit of F5. The business model combines open source distribution with paid enterprise subscriptions, SaaS management, managed cloud consumption pricing and professional support. Its direct customers are enterprise platform engineering, DevOps, SRE, network and security teams that need to route, secure and monitor application and API traffic across hybrid, multicloud and Kubernetes environments.
Company news briefing
Briefing updated:
NGINX has formalised protections against the 'HTTP/2 Bomb' DoS vulnerability with the release of version 1.29.8, alongside continued hardening against HTTP request smuggling through strict parsing protocols. The platform is accelerating the standardisation of QUIC and HTTP/3 to enable low-latency 0-RTT handshakes and improved resilience. These updates, combined with its deployment as a high-performance caching layer in cost-optimised vector search architectures, reinforce NGINX’s position as a critical Layer 7 control plane for secure, high-throughput AI and enterprise web infrastructure.
Business model & monetisation
NGINX monetises through enterprise software subscriptions, SaaS platform subscriptions, usage-based managed cloud pricing and service revenue. NGINX Plus is sold as a commercial subscription with enterprise support and advanced runtime features. NGINX One and Instance Manager extend monetisation through SaaS control, analytics and management. Managed offerings such as NGINXaaS for Azure use consumption-based billing, including a stated fixed price per deployment of $0.25 per hour. Additional monetisation comes from security products such as WAF and DoS protection, plus commercial support and professional services.
- Enterprise runtime subscriptions
- Software Subscription
- Managed cloud services
- Pay-per-Use
- Security add-ons
- Software Subscription
- Commercial support and professional services
- Service Fee
Products & capabilities
No products with linked sources are available in this view.
Products & market categories
Recent recorded signals
Dates refer to the source publication. Older entries are historical context, not evidence of a new event.
Gap Between TLS Everywhere and Actual Transport Security
Infrastructure · Recorded impact score: 1/5
This article discusses the common misconception of 'TLS everywhere' in cloud-native architectures, where TLS is often only implemented at the edge, leaving internal traffic unencrypted. It identifies four key layers where TLS is typically absent: ingress-to-pod, pod-to-pod, application-to-database, and cluster infrastructure certificates. The author details implementation strategies to close these gaps without necessarily adopting a service mesh, including re-encryption at the ingress, using cert-manager for automated certificate management, and implementing mTLS at the application level for smaller service estates. The article provides practical configuration examples, such as NGINX ingress annotations, cert-manager Certificate resources, and Prometheus alerting rules for certificate expiry. It emphasizes the importance of automating certificate rotation and monitoring time-to-expiry to prevent outages.
- TLS is often terminated only at the edge, leaving internal traffic unencrypted in many systems.
- Kubernetes does not encrypt pod-to-pod data plane traffic by default.
Resilient Real-Time Systems with WebSockets & Redis Pub/Sub
Infrastructure · Recorded impact score: 1/5
This technical guide explains how to build resilient, low-latency real-time systems by combining persistent WebSocket client-server connections with Redis as a central pub/sub broadcast layer, distributed state store, and cache. It describes architectural patterns for scaling (single server, multiple WebSocket servers + single Redis, and Redis Cluster), and explains when to integrate durable queues (Kafka/RabbitMQ/AWS SQS) for persistence and guaranteed delivery. The article includes a concrete Node.js example (ws and ioredis: server.js, publisher.js, client.html) and Docker, plus client reconnection best practices (exponential backoff) and session persistence in Redis to allow resuming on another instance. Operational topics covered are Redis high availability (Sentinel/Cluster), sharding and serialization, backpressure handling, load balancing, security, idempotency, and monitoring. It also discusses operational deployment patterns, monitoring metrics, and security practices for production environments.
- Combines persistent WebSocket client connections with Redis Pub/Sub as a broadcast layer and Redis as a distributed state store and cache.
- Covers scaling patterns: single server, multiple WebSocket servers + single Redis, and multiple servers with Redis Cluster for sharding and horizontal scale.
Mitigating HTTP Request Smuggling Attacks
Infrastructure · Recorded impact score: 2/5
The article explains HTTP Request Smuggling, an attack that leverages discrepancies in how front-end proxies (load balancers, WAFs) and back-end servers parse HTTP/1.1 request boundaries when both Content-Length and Transfer-Encoding headers are present or malformed. It describes common variants (CL.TE, TE.CL, TE.TE), concrete examples showing how smuggled requests can be interpreted differently by proxy and backend, and the resulting risks: bypassing security controls, cache poisoning, session hijacking, and credential theft. Recommended mitigations include upgrading to HTTP/2 end-to-end, normalizing/rejecting ambiguous requests at the edge (e.g., return 400 when both headers appear), using consistent server software across layers, disabling connection reuse, strict HTTP parsing (Nginx/Gunicorn settings), WAF rules, and timeouts. The article also provides testing guidance (curl, Python socket example, Burp Suite extension) and log-monitoring suggestions to detect attempted smuggling.
- HTTP Request Smuggling exploits inconsistent parsing of request boundaries between front-end proxies and back-end servers when both Content-Length and Transfer-Encoding headers are present or malformed.
- Common smuggling variants include CL.TE, TE.CL, and TE.TE; these can cause the back-end to treat leftover bytes as a new request, enabling attacks like cache poisoning and session hijacking.
Agentic AI Exposes Gaps in Confidential Computing
Confidential Computing / Agentic AI Security · Recorded impact score: 3/5
The article warns that agentic AI workloads—autonomous, multi-step agent chains that spawn helper subprocesses and share memory—can defeat current confidential computing attestation and auditing models. A described scenario shows an auxiliary worker escaping an enclave boundary, creating plaintext exfiltration and leaving no trace in sealed audit logs. The piece argues existing enclaves assume static code/memory boundaries and cannot track dynamic subprocess creation, causing visibility, integrity, and compliance blind spots across multi-hop inference pipelines. Recommended mitigations include supporting dynamic subprocess attestation, per-transaction attestation tokens, tamper-evident attestation chains appended to workflow state, and hardened Layer 7 control planes (application-layer load balancers) that enforce per-hop attestation and logging. The article also references LSE CenTest and the LSE Layer 7 load balancer as examples of platforms that address these challenges.
- Agentic AI workloads often spawn dynamic helper subprocesses that can map memory outside enclave boundaries, creating potential plaintext data exfiltration paths.
- Current enclave attestation and audit subsystems are typically static and do not record activity from dynamically created subprocesses, producing visibility and integrity gaps.
NGINX Architecture and Configuration Explained
Infrastructure · Recorded impact score: 2/5
This technical article explains NGINX's mental model, architecture, and configuration best practices, drawing from the official docs. It covers the master-worker process model, the single-threaded event loop using OS event notification (epoll/kqueue), zero-downtime reload choreography, request routing via server and location blocks, common config contexts (main → http → server → location), and practical directives for static serving, reverse proxying, load balancing, HTTPS, rate limiting, and logging. The post emphasizes operational rules (never block the worker loop, run nginx -t before reload) and highlights configuration snippets and recommendations that make NGINX predictable and performant in production.
- NGINX uses a master process plus multiple worker processes; the master handles privileged tasks and workers handle requests.
- Each worker is single-threaded and uses an event-driven, non-blocking loop (using epoll on Linux, kqueue on BSD/macOS) to serve thousands of concurrent connections.
Explore company relationships
Questions about NGINX
What is NGINX?
NGINX is an enterprise infrastructure software business that develops the NGINX open source distribution and sells commercial application delivery, traffic management and security products.
Who uses NGINX?
NGINX is used by enterprise platform engineering, DevOps, SRE, IT and security teams running web applications, APIs and Kubernetes workloads.
How does NGINX make money?
NGINX makes money through enterprise subscriptions, SaaS management products, managed cloud services, security add-ons, commercial support and professional services.
Sources & coverage
This profile uses public, official and technically observable information. Missing information does not prove that a product or relationship does not exist. The list below does not imply that every profile statement has been verified.
16 publicly documented primary sources and citations linked across the market graph.
Continue your research on NGINX
Explorer includes additional company details, a Watchlist for up to 25 companies and your personal Strategic Intelligence Agent. It monitors your market daily and delivers tailored briefings with clear strategic context whenever relevant news occurs.
Free, with no time limit.