NGINX vs Apache - Which Web Server Is Right for You?

Today's IT and DevOps teams have not one, but two, feature-rich open source Web servers to choose from: NGINX and Apache HTTP Server (which is often called simply "Apache"). At a high level, both platforms do the same core thing: Host and serve Web content. Both also offer comparable levels of performance and security.

Yet when you dive into the details, you'll find that there are many differences between NGINX and Apache. Each platform takes its own approach to configuration management, performance optimization, and more. Understanding these differences is essential for making the right choice when deciding between NGINX and Apache as a Web hosting solution.

General Overview

What is Apache?

Apache is a Web server released under the open source Apache 2.0 license. Like all Web servers, it hosts Web content – such as HTML pages, PHP files, and audio and video – and serves the content to users when they visit a website. It can host content for websites on the public Internet, or for internal company websites on an Intranet.

As noted above, the full name of the Apache Web server is Apache HTTP Server. (Sometimes, the name is stylized as Apache HTTPd Server, although technically speaking HTTPd – short for HTTP daemon – is only one component of the server.) But most people call it simply "Apache" colloquially. This practice can be a bit confusing because "Apache" can also refer to the Apache Software Foundation, a non-profit organization that oversees dozens of open source projects, of which the Apache HTTP Server is just one (although it also happens to be the oldest and – arguably – most important Apache Software Foundation project).

Thus, you might hear someone say, "Apache develops Hadoop," because Hadoop (an open source big data platform) is another project overseen by the Apache Software Foundation. Or, people will talk about "Apache Spark," another big data tool whose development is overseen by the Apache Software Foundation. But that does not mean that Apache the Web server is responsible for creating Hadoop or Spark; the relationship between the projects is simply that they are governed by the same non-profit organization and share the same software license, the Apache license. (Specifically, most Apache projects use the Apache 2.0 license, which dates to 2004.)

History of Apache

The Apache HTTP Server originated in 1995, when a group of Web administrators began collaborating to improve upon NCSA HTTPd. The latter was an early Web server platform created at the University of Illinois at Urbana-Champaign's National Center for Supercomputing Applications. NCSA HTTPd, which became available in 1993 (only four years after Tim Berners-Lee introduced the Web itself), was one of the first Web servers ever created.

NCSA HTTPd's original lead developer, Robert McCool, left the National Center for Supercomputing Applications in 1994. His departure stunted the development of NCSA HTTPd. This shift inspired a group of independent Web administrators to use the NCSA HTTPd code to build a new Web server, which became Apache HTTPd. (Developers chose the name Apache because the tool was "a patchy server," in the sense that it was created by applying a variety of software patches to NCSA HTTPd.) Development of NCSA HTTPd ceased entirely within two years of the Apache server's release.

From the start, Apache was an open source Web server that could be freely downloaded and used by anyone. These characteristics distinguished it from most other Web servers available at the time. It also evolved quickly thanks to the large group of volunteers who helped to extend its features. For these reasons, by April 1996 it had become the most widely used Web server in the world. Its popularity only increased as Linux-based operating systems grew in importance in the late 1990s and early 2000s, and more and more IT teams looked for open source Web server software that could run on the Linux systems they were setting up. Apache retained its position as the most popular Web server in the world for about twenty years, until it was overtaken by NGINX.

The group of Web admins who created the Apache Web server began collaborating around other open source projects as well, which is how the Apache server project spawned the launch of the Apache Software Foundation in 1998.

The original version of Apache was overhauled in the early 2000s, leading to the release of Apache 2.0 in 2002. The 2.x version remains the current version line of Apache today.

Benefits of Apache

Since its early days, Apache has offered a variety of benefits that have made it a popular Web server solution for many IT and DevOps teams.

One advantage, at least in the eyes of many IT professionals, is that Apache is open source. Its open source model not only makes it free of cost, but also allows community developers to extend and modify it easily. While NGINX is also open source, some other popular Web servers, like Microsoft IIS, are not.

Apache also offers a modular plugin system that makes it easy to add functionality to an Apache installation by installing modules that enable Apache to serve different types of Web content, log information, compress data, and so on. Modules in Apache can be easily activated and deactivated, providing a flexible solution for extending and controlling how Apache behaves.

In addition to hosting websites on a server, Apache offers the advantage of being able to be configured to run locally on a PC or laptop. This allows Web developers to test websites directly on their workstations, which typically enables faster performance (because data does not have to travel over a network) and simpler testing configurations.

Finally, although Apache was closely tied to Linux (which is how the "LAMP stack," short for Linux-Apache-MySQL-PHP, became popular) historically, modern versions of Apache can run on virtually every type of operating system -- Windows, Linux, macOS, and even Android. In addition, Apache configurations can typically be easily migrated from one type of operating system platform to another without requiring significant modifications. These features make Apache a highly cross-platform Web server solution.

What is NGINX?

NGINX is a Web server that is designed to also work as a reverse proxy server, a load balancer, and an HTTP cache. NGINX is open source and governed by a BSD license.

While Apache can be configured to perform these various additional tasks, it was designed first and foremost as simply a Web server.

History of NGINX

NGINX was created by a Russian software developer named Igor Sysoev. His reason for developing NGINX was to solve the so-called "C10k problem," which refers to the challenge of designing network sockets that are capable of handling 10,000 or more connections concurrently. (In other words, 10,000 active hosts connected to a single server at the same time.)

This type of scale had not been a major concern when Apache was created in the mid-1990s; back then, when the Web remained new, network administrators were not yet dealing with high levels of traffic. But this had changed by the mid-2000s, leading to interest among Sysoev and others in creating a new Web server that would be more responsive than Apache when serving large numbers of clients at the same time.

Sysoev released NGINX to the public in 2004. At first, the server made a relatively small splash; until circa 2010, few IT teams were considering NGINX as a serious alternative to Apache. But as the Web continued to grow, NGINX gained more and more prominence as a Web server that promised to surpass Apache in performance when handling large numbers of concurrent connections. Around 2016, NGINX finalled surpassed Apache in overall popularity and became the most widely used Web server in the world. It retains that distinction today.

A company associated with the NGINX project, called NGINX, Inc., was founded in 2011, and was later bought by F5 Networks in 2019. It sells support services for NGINX, as well as add-on components. The core NGINX software is free to download and use, but, as noted below, an alternative commercial version of NGINX (which costs money) provides additional features.

Benefits of NGINX

NGINX offers many of the same benefits as Apache. It's open source and (in its core open source form, at least) freely available to use.

Unlike Apache, however, NGINX has a somewhat simpler configuration system. Some of the functionality that would have to be added to an Apache installation using modules is included in NGINX by default, which means that there is less setup for admins to perform. For example, NGINX caches Web content by default in order to enable faster performance when multiple users request the same content.

The tradeoff for NGINX's simpler configuration is that it is more difficult to add functionality to NGINX once it is installed. This is because NGINX does not offer as many modules as Apache. In addition, functionality that could be added to Apache after installation using a module must be included in NGINX at the time that NGINX is compiled in many cases. This makes it more difficult to turn functionality on and off in NGINX, because doing so would require NGINX to be recompiled – a process that takes time and requires software tools that are not typically installed on servers by default.

NGINX also has a smaller overall resource footprint than Apache or other popular Web servers in most cases. It takes up less storage space and consumes less memory. For these reasons, NGINX can help to save money because it can run well on servers that are less powerful than those that host Apache. This advantage is particularly important if NGINX runs in the cloud, in which case IT teams can choose less expensive virtual machine instances to host it. (It's worth noting that both NGINX and Apache can be installed and run even on cheap PCs, it's not as if either Web server requires truly high-end hardware. However, NGINX tends to do a better job than Apache of maintaining strong performance when faced with large volumes of connections even if it is running on less expensive hardware, due to its lower resource consumption.)

Apache vs NGINX – Detailed Comparison

Now that we've walked through what Apache and NGINX are, let's look at how they compare in the various categories that matter to IT and DevOps teams.

Performance

Put simply, if all other factors are equal, Apache performs better when hosting sites that experience relatively low levels of traffic – perhaps 1000 requests or fewer per hour. NGINX performs better for sites that experience lots of requests simultaneously. This difference is not surprising; as noted above, developing a Web server that performs well at scale was the chief goal of NGINX's creator.

Part of the reason for the performance differences between Apache and NGINX is that Apache stores some of its configuration information for individual websites in .htaccess files. Each time a user visits a website, Apache has to read the .htaccess file before it can determine how to serve the relevant Web content. In cases where Apache needs to serve many website files at once, this adds up to a lot of file reads. Thus, when many users are requesting Web content at the same time, the I/O capacity of the Apache host server will be maxed out, delaying performance. In contrast, NGINX doesn't have .htaccess files; it stores its configuration in a way that can be accessed without requiring excessive file reads.

NGINX also typically offers better performance at scale because it caches Web content by default. Caching means that content that was recently requested by one user will be saved in a place where it can be accessed again quickly the next time a user issues the same request. This saves time because the data doesn't need to be generated again from scratch, for each request. Apache can be configured to cache data using the mod_cache module, but it doesn't do so by default.

On top of this, because NGINX's memory consumption is lower, it tends to be able to handle more connections simultaneously without overloading the host server. If Apache is faced with large volumes of requests, it may end up consuming all of the system memory and requiring data to be stored in swap partitions or page files, which slows performance significantly.

Static vs. Dynamic Content

There are two main approaches to creating websites. One is to build them using static content, such as plain HTML files. With static content, the Web server delivers the same content to each user for a given request. Content cannot typically be changed on-the-fly; the server can serve only the specific content that is uploaded to it. Changing the content would require regenerating the files and uploading them again to the server.

The other approach to serving content is to build dynamic content using programming languages like PHP, Ruby, or Python. These programming languages can be used to write scripts that are executed by the Web server whenever a user visits a website. Depending on conditions specified in the scripts, different data can be generated for each user.

Today, most complex websites rely heavily on dynamic content. It is much easier to build sites that are interactive, tailored to different user needs, and so on, using dynamic content.

When it comes to serving simple static content, Apache and NGINX both take the same basic approach: They deliver the static files requested by a website visitor.

But with dynamic content, Apache and NGINX take fundamentally different approaches. Apache interprets dynamic content directly (using whichever module it needs to read a particular type of dynamic file), then delivers the results to users. In contrast, NGINX is designed to rely on separate programs, such as FastCGI or WebSphere, to parse dynamic content. Those programs deliver the results to NGINX, which in turn passes them on to the user. (This is one of the scenarios in which NGINX functions as a proxy server in addition to a Web server.)

These different approaches to dynamic content have tradeoffs. With Apache, configuring the Web server to parse dynamic content is easier; it typically requires only installing the modules you need to parse files written in languages like PHP or Ruby. However, Apache is not always as efficient at interpreting dynamic files as a standalone server designed specifically for that purpose; as a result, Apache may not perform as well when serving dynamic content under a heavy load.

NGINX, in contrast, tends to perform better when dealing with dynamic content at high levels of traffic. But setting up NGINX to serve dynamic content is more work because it requires configuring multiple programs: NGINX itself and whichever separate programs will interpret dynamic content.

Operating System Support

As noted above, Apache and NGINX both run on virtually every modern operating system. That said, NGINX’s support for Windows remains in beta. Installing NGINX on Windows requires some manual effort, and the server is not deemed ready for production-level use in that environment.

In contrast, Apache offers full support for Windows, Linux, and several other operating systems. If you want to run a feature-rich open source Web server on Windows, Apache is really the only production-ready option.

The above notwithstanding, it’s worth noting that Apache and NGINX deployments are both much more common on Linux than on Windows or other platforms. That is where their followings were always strongest historically; moreover, teams seeking an open source Web server are often naturally inclined to choose an open source operating system to host it too.

Security

There are many different layers and dimensions to consider when securing a Web server, such as the application itself, any external servers with which it interacts, the network, the host operating system, and the data that the server accesses. A full discussion of how Apache and NGINX handle these various security requirements is beyond the scope of this page; however, it is fair to say that Apache and NGINX are both designed to be secure by default.

Still, there are important additional steps that IT and DevOps teams should typically take to harden Apache and NGINX beyond their defaults, such as enabling SSL encryption, disabling HTTP 1.0/1.1 support (unless it is strictly required), and making sure that the Web server runs on the host using a user account that does not have access to any extraneous resources.

An argument could be made that NGINX is somewhat more secure by default than Apache in certain respects. For example, NGINX does not enable directory listings (which allow anonymous users to browse the contents of a website directory in their browser) by default, while Apache does in many cases. However, this type of security risk is relatively minor compared to larger issues like a lack of SSL encryption, which would need to be addressed in both an NGINX or an Apache installation.

Flexibility

When coupled with modern deployment and management tools, Apache and NGINX are both relatively flexible to install and control. Both can be installed using Docker containers, which enables a flexible deployment process on any operating system that supports Docker. It is also relatively easy to migrate both an Apache and an NGINX deployment from one host server to another; some configuration files may need to be changed, but in general the configurations would not require a major overhaul. From this perspective, both Web servers are also quite flexible.

Still, Apache could be said to be more flexible in some respects. Loading and unloading modules is simpler in Apache than it is in NGINX (for more on this, see the following section). Apache also offers more cross-platform compatibility because it is fully supported on Windows and Linux, whereas NGINX supports Windows only in beta mode. And NGINX, as noted above, requires external programs to handle dynamic content; these programs impose more configuration overhead and can make migration or scaling somewhat more difficult. These flexibility advantages for Apache may not be overwhelming, but they do make Apache a little more agile in certain respects.

Modules

As noted above, Apache and NGINX both allow admins to install and enable modules. Modules add extra functionality to the Web servers. In fact, without any modules, neither Apache nor NGINX would be able to do much at all; even relatively simple functionality, like serving sites based on PHP, would require a module for both servers.

However, the approach that each server takes to modules is different. In Apache, modules are dynamic and flexible. They can be easily enabled or disabled at any time using simple tools (like a2enmod a2dismod).

NGINX’s module system is more rigid. It has two types of modules, static and dynamic. Static modules can be used with any version of NGINX, but they have to be built into NGINX at the time it is compiled; they can’t be simply added later. NGINX also offers dynamic modules, which were introduced in 2016 with the release of NGINX Plus R11. The caveat, however, is that dynamic modules work only with NGINX Plus, the commercial version of NGINX. If you want to use the purely open source, free-of-cost version of NGINX, you are limited to static modules.

It’s worth noting that static modules in NGINX are not quite as difficult to work with as they may seem, due to the fact that it is relatively easy to replace an existing NGINX instance with a newer one, even if the instance has active connections. If you want to add a static module to NGINX but didn’t include that module when you first compiled it, you can simply replace your current NGINX instance with a new version that has the module you need built in. This process effectively allows static modules to be enabled on-the-fly in NGINX without disrupting an ongoing NGINX workload, although it requires more effort than Apache’s module system would.

Documentation

Apache and NGINX are both very well-documented platforms. It’s very unlikely that admins would ever run into an issue or have a question whose answer could not be found within the Apache or NGINX documentation.

Both servers also have large and active community-support forums and listservs where admins can ask for help if they need. It is also possible to obtain paid commercial support for both Apache and NGINX. In Apache’s case, the support comes from third-party vendors. For NGINX, support is available from NGINX, Inc., the same organization that helps sponsor NGINX development.

Integrating Apache and NGINX with Sumo Logic

Whether you choose to host your websites using Apache, NGINX, or both simultaneously, Sumo Logic makes it easy to aggregate, manage, and monitor Web server logs. Setting up Sumo Logic to manage logs from servers is simple; admins simply need to enable logging in the server, configure a Sumo Logic collector, and create field extraction rules to control how Sumo Logic interacts with log data.

For a full walkthrough of the steps, check out the Sumo Logic documentation for Apache and NGINX.