lighttpd1.4 is the collaboration mirror of a small footprint web server

A mirror, and what that means for the code you read

The repository description is unusually candid about its own status: lighttpd1.4 on github for easier collaboration, with the main repo still on lighttpd.net.

So this is not where lighttpd is developed. It is a GitHub copy of the 1.4 series, created so that people can raise pull requests and issues in the place where most people look, while the project keeps its own infrastructure. The homepage recorded in the repository metadata is the redmine wiki at redmine.lighttpd.net/projects/lighttpd/wiki, and the README points at the same place for documentation.

That distinction is the first thing to establish, because it changes what you should expect from the repository. The default branch is master, the repository is not archived, and the last push was on 2026-07-16. But there are no GitHub releases, and the version number is the giveaway: this is the 1.4 line, which is a maintenance branch rather than the active development branch. If you are starting something new and want the current lighttpd, this is not the tree to build from, and if you are tracking a security fix, you need to check where the maintainers actually applied it.

The project itself is older and broader than the branch suggests. The README describes lighttpd as a secure, fast, compliant and highly configurable web-server which has been optimized for high-performance environments, with a very low memory footprint compared to other web servers, and it explains the name: lighttpd is an httpd which is fast as lightning and light when it comes to memory consumption and system requirements.

The licence is BSD-3-Clause, and the primary language is C.

What the server actually implements

The README's feature list is organised as a spec, and it is more useful than a marketing page because it names the exact behaviours.

On the network side, IPv4 and IPv6. On protocols, HTTP/2, HTTP/1.1 and HTTP/1.0, HTTPS via one of openssl, BoringSSL, LibreSSL, mbedTLS, wolfSSL, GnuTLS or NSS, plus CGI/1.1 and FastCGI.

The advanced features are the ones that make it useful in front of an application. It can load-balance FastCGI, SCGI, reverse-proxy, socket proxy and websocket tunnel, so one webserver distributes requests to multiple PHP servers via FastCGI, and it can stream the same set of protocols. Beyond that there are custom error pages for response codes 400 to 599, virtual hosts, directory listings, URL rewriting, HTTP redirection, and output-compression with transparent caching.

The FastCGI support section is where the PHP story sits, and it is worth reading because it describes how the server talks to the application rather than just that it can. It parses the response header and completes the HTTP header accordingly, and it handles Keep-Alive based on the Content-Length header. The PHP section claims the same speed as or faster than Apache with mod_php4, says it handles various PHP bugs in the FastCGI SAPI, and notes it includes a utility to spawn FastCGI processes, which was necessary for PHP 4.3.x.

That last detail dates the document. The Works with list mentions IE 6.0, Mozilla 1.x and Konqueror 3.1, and the Works on list names Solaris 8 and 9 and SGI IRIX 6.5. The README is an old document, which is normal for a project that has been stable for a long time, but it does mean the feature list is not a complete description of what current lighttpd does.

HTTP/1.1 compliance as a checklist

The compliance section is the part of the README that is genuinely distinctive, because it enumerates status codes rather than claiming conformance.

The server sends 206 for Range requests, 304 for If-Modified requests, 400 for a missing Host on HTTP/1.1 requests, 400 for a broken Request-Line, 411 for a missing Content-Length on POST requests, 416 for out-of-range on a Range header, 501 for a request method that is not GET, POST or HEAD, and 505 for a protocol that is not HTTP/1.0 or HTTP/1.1. It sends a Date header on every request.

For a server that has been in production for a very long time, this list is the kind of thing that gets written after a decade of interoperability reports, and reading it tells you what a client can rely on. The 416 and 501 entries in particular are the ones that a naive implementation gets wrong, and getting 411 on a POST without Content-Length rather than hanging is the difference between a client seeing an error and a client seeing a timeout.

The HTTP/1.1 features list adds the rest: Ranges in the start-end, start-, -end and multiple ranges forms, HTTP/1.0 Keep-Alive together with HTTP/1.1 persistent connections, the GET, HEAD and POST methods, Last-Modified with If-Modified handling, a Content-Length header where it is possible to send one, Transfer-Encoding chunked when Content-Length is not possible, and a Content-Type header.

On the compression side, output compression is on the fly with deflate and gzip, and the security features are chroot, set UID, set GID, and protecting the docroot. The compression pairs with the transparent caching, so a compressed response is cached rather than recompressed per request.

Who it was built for

The Intended Audience section names two cases, and both are narrow enough to be useful as an evaluation criterion.

The first is Ad-Server Front-Ends, described in the README as Banner-Schleuder, for delivering small files rapidly. The second is php-servers under high load, where the role is load-balancing the PHP request over multiple PHP servers.

Both of those are the same shape of problem. You have a large number of small requests, you want to keep the process footprint tiny so that many of them can be served, and you want a thin front end that either serves static content directly or distributes work to a pool of application servers. That is what lighttpd is good at, and it explains why the feature list concentrates on FastCGI balancing, static file delivery, compression and connection handling rather than on application server features.

The security features fit the same profile. A server that runs many worker processes on a shared machine needs to be able to drop privileges and restrict the filesystem, and chroot, set UID, set GID and docroot protection are the tools for that. For an ad server front end that must not be able to read the rest of the filesystem, that is a requirement rather than a nicety.

The trade is that a modern general purpose server also does caching layers, rate limiting, HTTP/2 multiplexing priorities, observability integrations and module ecosystems, and lighttpd is not trying to be that. The README's own framing, a server optimised for high-performance environments with a very low memory footprint, is the specification to hold it to.

Building and running it

The repository supports the usual multiple build systems, which is what you would expect from a project that has been built by many different packagers.

There is a CMakeLists.txt at the root, a meson.build with meson_options.txt, an autogen.sh alongside configure.ac, a Makefile.am, and a SConstruct. There is also a packdist.sh script, a scripts/ directory, a tests/ directory, a doc/ directory, and platform-specific files such as README.FreeBSD, an INSTALL file and a COPYING file. The presence of a FreeBSD README is a decent hint about which platforms the packagers care about.

Running it is two forms of the same binary. As a daemon in the background:

  $ lighttpd -f <configfile>

Or without detaching from the console:

  $ lighttpd -D -f <configfile>

The -f flag points at the configuration file, and -D is the difference between backgrounding and staying in the foreground. For a service manager, a container or a systemd unit, the -D form is usually the one you want, since the process manager wants to own the process rather than have it fork away.

The README does not include a configuration example, and the wiki at redmine.lighttpd.net is where the configuration reference lives. That is the practical gap to be aware of: the README tells you the server exists and what it does, and the wiki is the actual documentation.

Where lighttpd fits, and where it does not

The comparison worth making is with the other small web servers and with the large ones, because the trade is entirely about how much you want the server to do.

Against a general purpose server such as Apache or Nginx, lighttpd's advantage is footprint and start-up cost. A few hundred kilobytes of resident memory per worker means you can run many more of them on a small machine, and the static file serving path is designed around that. The cost is breadth: the module ecosystem, the configuration surface and the operational tooling around it all live elsewhere, and the configuration file syntax is its own thing rather than a subset of something you already know.

Against the classic fast static file server, the difference is that lighttpd is not limited to static files. The FastCGI balancing, the streaming reverse proxy and the websocket tunnel mean it can sit in front of an application as well as serve files itself, and the advertised use case is exactly that combination.

The protocol list is the boundary to check. HTTP/2 is there, HTTP/3 is not, and the README does not claim otherwise. If your clients are on HTTP/3, or if your load balancer terminates HTTP/3 and forwards HTTP/2, that is fine, but if you need the server itself to speak HTTP/3 this is the wrong choice.

There is also the question of where the code lives. Because the GitHub repository is the 1.4 maintenance line rather than the main development branch, a team that wants to contribute, to read the current source, or to pick up a recent fix should start at the lighttpd.net repository and the wiki, and treat this mirror as the collaboration convenience it says it is. The BSD-3-Clause licence means there is no commercial constraint on any of that.

Editorial conclusion

lighttpd suits an operator who needs to serve static files or front a small number of FastCGI applications on a machine with little memory to spare, since the whole point of the server is a low footprint and it handles TLS, compression and CGI without a large dependency tree. It is the wrong tool if you need a large general purpose server with a wide module ecosystem, and it is the wrong tool if you need HTTP/3, which is not in the protocol list. Before building it, read the wiki on the redmine site for the configuration reference, and remember that the GitHub repository is the 1.4 maintenance branch rather than the main development line, so upstream bug fixes for newer versions will not appear there.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. lighttpd/lighttpd1.4 on GitHub
4. Project website
5. README