NGINX

Unternehmensdaten

Offizieller Name

Nginx, Inc.

Einheitentyp

COMPANY

Gegründet

2011

Hauptsitz

United States

Marktrolle

B2B SaaS Provider

Offizielle Website

nginx.com

Was NGINX macht

NGINX nutzt ein Open-Core-Modell für Infrastruktursoftware. Während die Open-Source-Distribution von NGINX eine breite Akzeptanz bei Entwicklern und Operations-Teams sichert, bündeln die kommerziellen Produkte erweiterte Enterprise-Funktionen, Support, Management, Sicherheits-Features und Managed-Cloud-Optionen für zahlende Geschäftskunden. Der Mehrwert entsteht durch die Reduzierung der Komplexität bei der Anwendungsbereitstellung, die Erhöhung der Verfügbarkeit und die Standardisierung der Traffic-Steuerung in hybriden und Multicloud-Infrastrukturen. Die Umsätze werden durch Enterprise-Abonnements, den Zugriff auf SaaS-Plattformen, Verbrauchsgebühren über Cloud-Marketplaces, Security-Add-ons und Professional Services generiert.

Strategische Einordnung

KI-gestützte Einordnung aus der bestehenden Unternehmensrecherche; Interpretation und belegte Fakten sind zu unterscheiden.

NGINX ist der kommerzielle Betreuer des NGINX-Webservers und ein führender Anbieter von Software für Enterprise-Anwendungsbereitstellung und IT-Sicherheit. Das Portfolio umfasst Lösungen für Load Balancing, Reverse Proxying, API-Gateways, Kubernetes Ingress, Observability, zentralisiertes Instanz-Management sowie Web Application Firewalls (WAF) und Denial-of-Service-Schutz. Zudem bietet das Unternehmen Managed Cloud Services wie NGINXaaS für Azure und Google Cloud an. NGINX agiert als hundertprozentige Tochtergesellschaft und eigenständige Geschäftseinheit von F5. Das Geschäftsmodell kombiniert Open-Source-Distribution mit kostenpflichtigen Enterprise-Abonnements, SaaS-Management, nutzungsbasierten Managed-Cloud-Preisen und professionellem Support. Zu den Direktkunden zählen Plattform-Engineering-, DevOps-, SRE-, Netzwerk- und Sicherheitsteams in Unternehmen, die Anwendungs- und API-Traffic über hybride, Multicloud- und Kubernetes-Umgebungen hinweg steuern, sichern und überwachen müssen.

Geschäftsmodell und Monetarisierung

NGINX monetarisiert seine Lösungen über Enterprise-Software-Abonnements, SaaS-Plattform-Lizenzen, nutzungsbasierte Managed-Cloud-Preise und Service-Umsätze. NGINX Plus wird als kommerzielles Abonnement mit Enterprise-Support und erweiterten Laufzeitfunktionen vertrieben. NGINX One und der Instance Manager erweitern die Monetarisierung durch SaaS-Steuerung, Analysen und Management. Managed-Angebote wie NGINXaaS für Azure nutzen eine verbrauchsabhängige Abrechnung, darunter ein festgelegter Preis pro Bereitstellung von 0,25 USD pro Stunde. Zusätzliche Einnahmen stammen aus Security-Produkten wie WAF und DoS-Schutz sowie aus kommerziellem Support und Professional Services.

Enterprise-Laufzeit-Abonnements

Software-Abonnement

Managed Cloud Services

Nutzungsbasierte Abrechnung

Sicherheits-Add-ons

Software-Abonnement

Kommerzieller Support und Professional Services

Servicegebühr

Produkte und Fähigkeiten

Für diese Ansicht liegen keine Produkte mit zugeordneten Quellen vor.

Produkte und Marktkategorien

Zuletzt erfasste Signale

Datumsangaben beziehen sich auf die Quellenveröffentlichung. Ältere Einträge sind historischer Kontext, kein Beleg für ein neues Ereignis.

• Gap Between TLS Everywhere and Actual Transport Security

  2026-09-08dev.to

  Infrastructure · Erfasster 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

  2026-08-11

  2 QuellenDEV Community·DEV Community

  Infrastructure · Erfasster 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

  2026-08-09dev.to

  Infrastructure · Erfasster 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

  2026-08-03dev.to

  Confidential Computing / Agentic AI Security · Erfasster 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

  2026-07-29dev.to

  Infrastructure · Erfasster 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.

Unternehmensbeziehungen vertiefen

• Wettbewerber und Alternativen
• Partner und Integrationen
• Eigentumsverhältnisse
• Ähnliche Unternehmen

Fragen zu NGINX

Quellen und Datenabdeckung

Mit NGINX weiterarbeiten

Explorer bietet zusätzliche Unternehmensdetails, eine Watchlist für bis zu 25 Unternehmen und einen automatisch eingerichteten Strategic Intelligence Agent. Das Monitoring läuft standardmäßig täglich; ein Briefing entsteht nur bei relevanten neuen Ergebnissen.

Kostenlos und ohne zeitliche Begrenzung.