NGINX
It's open source software for serving web pages, reverse proxying, caching, load balancing, media streaming, and much more. It started as a web server designed to deliver maximum performance and stability. Besides its capabilities as an HTTP server, NGINX can also act as a mail proxy server (IMAP, POP3, and SMTP) and as a reverse proxy and load balancer for HTTP, TCP, and UDP servers.
Reasons to use
NGINX
High-profile companies using NGINX include Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel, and many more
With NGINX, a master process can control multiple worker processes. The master process maintains the worker processes, while these do the actual processing. Because NGINX is asynchronous, each request can run concurrently without blocking the others.
NGINX is designed to deliver low memory usage and high concurrency. Instead of creating a new process for each web request, NGINX uses an asynchronous, event-driven approach in which requests are handled on a single thread.
NGINX was originally created by Igor Sysoev, with its first public release in October 2004. Igor originally conceived the software as a response to the C10k problem, related to the performance challenge of handling 10,000 concurrent connections.
At Coresis we use NGINX as a server and reverse proxy for the Drupal platforms we build, including GOV.CO portals. Its low memory usage and load-balancing capabilities let us provide support and maintenance for high-traffic sites without sacrificing performance.
What role does NGINX play?
NGINX can serve web content and act as a reverse proxy in front of an application. In a Drupal architecture it helps concentrate TLS, compression, caching rules, request limits, and traffic distribution, without moving those responsibilities to the CMS.
Common uses
- Serving static files and delegating PHP to the application runtime.
- Applying caching where personalization and sessions allow it.
- Balancing requests across multiple instances.
- Setting canonical headers and redirects at a single edge.
Performance with verifiable rules
Aggressive caching isn't always better: we distinguish between anonymous content, sessions, forms, and personalized responses before configuring lifetimes. The result is validated with real requests and headers, together with Drupal's internal cache. More information in our support services and the official NGINX documentation.
Decision guide
What NGINX needs to solve in production
NGINX is the entry layer that can route requests, serve files, apply caching, and distribute traffic before it reaches Drupal, Node.js, or other services. A good configuration isn't measured by how many directives it has, but by predictable, observable, and secure rules.
Reverse proxy
A single entry point to route domains and paths to applications with different technologies or deployment cycles.
Content caching
Public responses that can be served without re-executing PHP or querying the origin on every visit.
Balancing and continuity
Distribution across instances with limits, timeouts, and health checks aligned with the application's behavior.
How it fits into the architecture
A common path is CDN, NGINX, then the application. The CDN absorbs global traffic; NGINX keeps rules close to the origin; and Drupal or Node.js resolve only what can't be served earlier. Cookies, headers, parameters, and methods that invalidate or bypass the cache need to be documented so private content is never shown and stale pages are never served.
What to validate before adopting it
- Define the cache key and all its exclusion conditions.
- Preserve protocol, host, and client IP through trusted headers.
- Adjust limits and timeouts for each downstream service.
- Log HITs, MISSes, origin latency, and response codes.
When not to choose it
NGINX doesn't replace a CDN, an application firewall, or authorization logic. It also doesn't fix a slow query or a heavy page: it can temporarily hide the symptom on cacheable content, but authenticated routes will keep exposing the problem. Every layer needs a verifiable responsibility.
How Coresis applies it
At Coresis we use it as part of operating Drupal platforms, with caching rules that distinguish public traffic, editorial sessions, and invalidations. That configuration is reviewed together with the Drupal support service and the delivery layer, not as an isolated file.
Source and related technologies
Compare capabilities and limits in the official NGINX reverse proxy guide.