Apache httpd: what the mirrored C web server actually gives you, and how to install it

What Apache httpd solves, and who it is for

Apache httpd is a general-purpose web server written in C. The README describes it as "HTTP/1.1 and HTTP/2 compliant" and states that it has been in continuous development since 1995, originally as a replacement for the NCSA HTTP Server. That history matters less than what it implies: the project is designed around a stable configuration language and a module interface, so an operator can change behaviour by loading a module rather than by patching the core.

The audience is operators and platform engineers who need to terminate HTTP for several applications on one host, apply authentication, rewriting, proxying or TLS in a single place, and keep that configuration under version control. It is also for people who need to extend a server in C. The repository ships modules/ alongside server/ and include/, which is where the module API lives. If you only ever serve a directory of static files, you are paying for machinery you will not use.

One point of confusion is worth settling early, because it shows up in search data constantly. httpd is the name of the daemon binary and of the project; Apache is the foundation that publishes it. The README's own heading is "Apache HTTP Server". On many Linux distributions the package is literally called httpd, which is why "httpd install" and "apache httpd" describe the same act.

How a request moves through httpd

The core is a multi-process, multi-threaded server. A parent process reads the configuration, binds the listening sockets and then forks child processes that accept connections; the parent's job is supervision, restarting or reaping children as needed. This is why a graceful reload does not drop established connections, and why a misconfigured module can take down a child without killing the parent.

Configuration is read at startup from a hierarchy of files. The top-level httpd.conf pulls in fragments, and directives are applied in the order they are parsed, so a later directive can override an earlier one. This is the source of most real-world httpd bugs: an Allow or Require rule placed above the block it was meant to govern, or a RewriteRule whose position in the file changes which requests it sees.

Request handling is a pipeline of phases. After a connection is accepted and the request line parsed, modules registered for each phase get a chance to act: translating the URL to a filesystem path, checking access control, authenticating, authorizing, mapping content types, and finally generating or proxying the response. mod_ssl sits in this pipeline for TLS connections and is included under modules/ssl/ in the distribution. Because each phase is a hook, a module can short-circuit the pipeline, which is how mod_rewrite can send a request somewhere else entirely before any file is touched.

The repository layout reflects that separation: server/ holds the core, modules/ holds the optional behaviour, support/ holds the command-line utilities, and os/ holds platform-specific glue. The build system is autoconf-based, with CMakeLists.txt and README.cmake present as an alternative path.

Installing httpd and serving a first directory

The README does not give installation commands. It says only: "Please see the file called INSTALL. Platform specific notes can be found in README.platforms." So the authoritative steps live in those two files in the repository root, and they differ per platform. What follows is the shape of a source build, which is what INSTALL describes.

First you generate the configure script. The repository ships buildconf for exactly this purpose, because a checkout from version control does not include a pre-generated configure.

./buildconf

The README names the INSTALL file as the place where the build and install procedure is written down, and README.platforms carries the per-platform notes. Read both before running anything, because the flags differ between platforms and the README does not reproduce them.

The default configuration listens on port 80, which is why "httpd port" is a common query. To serve a directory of your own, edit the DocumentRoot and its matching Directory block in httpd.conf. Both must agree, or you get a 403 rather than a page. The repository's docs/manual/ directory contains the documentation shipped with the release, and the project page carries the current version.

After editing, reload rather than restart if you want to keep in-flight connections. The README does not document the reload procedure, so the exact command is a matter for the documentation in docs/manual/ rather than for this page.

Where httpd is the wrong tool

The most common mismatch is a static asset edge. If your workload is serving immutable files to a very high number of concurrent connections, httpd's process model costs memory per child in a way that an event-loop server does not, and the module system buys you nothing. The comparison that search data keeps returning to, httpd versus nginx, is not a question of which is better but of which model fits the traffic. httpd's strength is a configuration language expressive enough to encode application routing, authentication and rewriting in one place; if you do not need that, you are carrying it for free.

The second mismatch is the distribution package. The README warns that packages with "crypto" in the name may bundle OpenSSL object code, and that packages with "nossl" in the name have been built without the cryptographic files. If you are deploying into an environment with import or re-export restrictions, the README directs you to check your country's laws before using any encryption software, and points at the Wassenaar Arrangement for background. That is a packaging decision you have to make deliberately, not a detail to discover after installation.

The third is operational. The README points at mailing lists for release and security announcements and at the bug reporting page for concrete reports. There is no statement in the README about a support contract or a commercial backing entity. If you need a vendor to call, this project does not provide one through its own documentation.

A subtler limitation: because directives are order-sensitive and configuration is spread across included fragments, a large httpd deployment becomes a configuration-management problem rather than a server problem. Nothing in the repository prevents that, but nothing solves it for you either.

What to compare it against

The realistic alternative for most teams is nginx. The difference is architectural, not cosmetic. nginx is built around an event loop with a small number of worker processes, which makes it cheap to hold many idle connections, and its configuration is a tree of blocks rather than a linear directive stream. That makes some things easier (a server block is self-contained) and some things harder (matching httpd's phase hooks requires a different mental model).

For application routing specifically, the honest comparison is not httpd versus nginx but whether you need a separate reverse proxy at all. If your application framework already ships a production HTTP server, adding httpd in front buys you TLS termination, access control and rewriting in one auditable file, at the cost of another process to configure and another upgrade to track. That trade is usually worth it at the point where more than one application shares a host, and usually not before.

Caddy is the other name that comes up, mainly because it handles certificate issuance automatically. httpd does not do that on its own; TLS in httpd means mod_ssl plus certificates you obtain and renew through some other mechanism. If automatic certificate lifecycle is the requirement, that requirement points away from httpd, and no amount of module configuration changes it.

Maintenance, upgrades and the licence

The repository is not archived, and the last push was on 2026-09-22, so the codebase is being committed to. That says nothing about release cadence, and the material contains no release list, so treat version selection as something you resolve from the project page at httpd.apache.org rather than from this repository alone. CHANGES and changes-entries/ at the repository root are where change history is recorded, and README.CHANGES explains how to read it. VERSIONING and ROADMAP are also present and describe how the project thinks about version numbers and direction.

Upgrade cost depends entirely on how you installed it. A distribution package upgrade is a package manager operation, and the risk is that the distribution's build flags differ from what you assumed. A source build means you rebuild and reinstall, and the risk is that your configure flags have drifted from the ones the previous build used. Either way, the configuration file format is the thing to check across a major version boundary, not the binary.

The licence is Apache-2.0. The README defers to the LICENSE file for the terms, and NOTICE and ABOUT_APACHE are also in the repository root. Apache-2.0 is a permissive licence with an explicit patent grant, which is why it is commonly accepted in commercial products, but the cryptographic notice above is a separate consideration from the licence: export classification is a regulatory question, not a licensing one. The README states that the U.S. Bureau of Industry and Security classified the software as ECCN 5D002.C.1 and that the ASF distribution form is eligible for export under the ENC TSU exception. If your redistribution includes the crypto object code, that is the paragraph your compliance reviewer will want to read. This is not legal advice; the README's own instruction is to check your country's laws.

Editorial conclusion

Adopt Apache httpd when you need a long-lived, standards-based HTTP/1.1 and HTTP/2 server with a module system you can extend in C, and when you are prepared to track CHANGES and the security list yourself. Do not adopt it expecting a package manager to keep it current, and do not adopt it for a workload whose whole value is a fast static edge. Before you commit, read INSTALL and README.platforms for your platform, confirm which modules your build enables, and check whether the package you are offered contains the crypto object code or is the nossl variant.

Frequently asked questions

Official sources

1. apache/httpd on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README