# CivetWeb: an embeddable C/C++ web server that keeps the MIT licence

> CivetWeb puts an HTTP server inside your own C or C++ application, or runs as a single executable with no installation. The trade-off is a small, deliberately limited feature set and a release cadence that has slowed since v1.16.

**civetweb/civetweb** — Embedded C/C++ web server

- Repository: https://github.com/civetweb/civetweb
- Stars: 3,457 · Forks: 1,050
- Language: C
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/civetweb-civetweb

## What CivetWeb solves, and who ends up using it

Most web servers are processes you deploy next to your application. CivetWeb is aimed at the opposite case: you already have a C or C++ program, and you want that program to answer HTTP requests without shipping a second binary, a runtime, or a configuration management layer. The README states the mission directly: provide an easy to use, powerful, C (C/C++) embeddable web server with optional CGI, SSL and Lua support. It also states that CivetWeb can be used by developers as a library, to add web server functionality to an existing application, and by end users as a stand-alone web server running on a Windows or Linux PC, available as a single executable with no installation required.

The project was forked from Mongoose in 2013, before that project changed its licence from MIT to commercial plus GPL. That history explains the audience. Anyone who wants to link an HTTP server into a closed-source product, or into firmware, or into a desktop application, and who cannot take on copyleft obligations, is the intended user. The README puts it plainly: the project is free from copy-left licenses, like GPL, because you should innovate without restrictions.

It is not a general purpose application server. There is no package manager, no plugin marketplace, and no configuration DSL beyond a config file. If you want to install a server with a package manager and configure virtual hosts in YAML, this is the wrong shape of tool.

## How the embedding actually works: one source file and a header

The build layout tells you most of the architecture. The Makefile defines LIB_SOURCES as src/civetweb.c and HEADERS as include/civetweb.h. The README describes the source as being in a single file for drop in compilation, and lists a separate API documentation directory plus civetweb.h as the interface reference. So the embedding path is: add src/civetweb.c to your build, include civetweb.h, and call the API to start a listener and register handlers.

Everything else is compiled in or out at build time. The README lists the optional pieces: CGI, SSI, HTTP digest (MD5) authorization, WebSocket, WebDAV, experimental HTTP/2 support, HTTPS via OpenSSL, authentication using client side X.509 certificates, resumed download, URL rewrite, file blacklist, IP-based ACL, download speed limits based on client subnet or URI pattern, and an HTTP client capable of sending arbitrary HTTP/HTTPS requests. The Makefile reflects this with flags such as WITH_ALL=1 and WITH_LUA=1, and the Dockerfile uses make WITH_ALL=1 when it builds the container image.

That compile-time model is the central design decision. A build with Lua and OpenSSL pulled in is a different binary from a build with neither, and the documentation is split accordingly: docs/OpenSSL.md for TLS, docs/Docker.md for containers, docs/Embedding.md for the library path. The cost is that you cannot decide at runtime what your server supports. The benefit is that an embedded build carries only the code you asked for.

## Installing CivetWeb and serving a first directory

End users are pointed at pre-built binaries. The README says binaries and releases are downloadable from the GitHub releases page or from SourceForge, and that docs/Installing.md is the install guide for end users using pre-built binaries. There is no installation step for the standalone executable.

Developers build from source. The Makefile includes resources/Makefile.in-os and defines a help target, and docs/Building.md is described as the building quick start guide. A build with every optional feature enabled follows the same pattern the Dockerfile uses:

```bash
make build
make WITH_ALL=1
make install PREFIX=/app
```

After that, the installed binary lives under the prefix you chose. The Makefile sets PORTS = 8080 by default, and the Dockerfile exposes port 8080 and sets the container entry point to the binary plus a config file:

```dockerfile
EXPOSE 8080
ENTRYPOINT  [ "/app/bin/civetweb", "/app/etc/civetweb.conf" ]
```

That entry point is worth reading closely: the server takes a configuration file path as an argument. docs/UserManual.md is the end user guide for the options that file accepts. One of the search phrases people use is Civetweb listening_ports, which is the config key that controls which ports the server binds; the UserManual is where its exact syntax lives, and the default in the Makefile is 8080.

If you want to compile it into your own program instead, the repository ships examples under examples/, including examples/embedded_c/, examples/embedded_cpp/, examples/rest/, examples/ws_server/ and examples/ws_client/. Those directories are the fastest way to see the API in use, and docs/Embedding.md is the companion write-up.

## Where CivetWeb stops being the right choice

The feature list is curated, and the README says so: CivetWeb keeps the balance between functionality and simplicity by a carefully selected list of features. What is missing matters as much as what is present. There is no process manager, no clustering, no built-in metrics endpoint, and no documented rollback procedure for an upgrade. The README does not document rollback. If your deployment model assumes you can revert a server version through a package manager, you are building that yourself.

The release history is the other constraint. The most recent tagged release listed is v1.16 from 2023-04-10, preceded by v1.15 in 2021 and v1.14 in 2021. The repository is not archived and the last push was on 2026-08-01, so development activity exists, but tagged releases are infrequent. Anyone who needs a predictable upgrade train with frequent security releases should weigh that against projects with a tighter cadence.

HTTP/2 is described in the README as experimental. Treat it as such. If HTTP/2 is a requirement rather than a nice-to-have, that word in the README is the signal to look elsewhere or to plan for your own testing.

There is also a platform-specific trap recorded in the README: due to a bug in Git for Windows V2.24, CivetWeb must be used with an earlier or later version. That is a narrow condition, but it is the kind of thing that wastes an afternoon if you hit it.

## CivetWeb versus Mongoose, and why the fork exists

The natural alternative is the project CivetWeb came from. Both are C/C++ embedded HTTP servers with a single-file or near-single-file build model, and both offer CGI, WebSocket and TLS support. The difference the README emphasizes is licensing: CivetWeb was forked from Mongoose in 2013, before Mongoose changed its licence from MIT to commercial plus GPL. CivetWeb kept MIT and states that it is free from copy-left licenses.

That is a real fork in the road for commercial work. If you are linking a server into a product you distribute as a binary without source, the licence of the server library decides whether that distribution is straightforward. The README frames the choice as innovating without restrictions. Whether that matters to you depends entirely on how you ship.

A second alternative is libmicrohttpd, which also appears in the related search terms people use around this project. The approach differs: libmicrohttpd is a library first and is typically paired with an external event loop, while CivetWeb bundles its own threading and connection handling and can also run standalone as an executable. If you already have an event loop and want a library that fits into it, that difference is the deciding factor. If you want a server that runs by itself with no installation, CivetWeb's standalone mode is the part libmicrohttpd does not try to provide.

## Licence, maintenance and what an upgrade costs

The README and the Makefile header both identify the licence as MIT, and the README states that CivetWeb has a MIT license. The LICENSE.md file in the repository root is the authoritative text, and the README links to it. Note the discrepancy worth checking yourself: the repository metadata reports the licence as NOASSERTION, which usually means an automated detector could not match the licence file to a known template. Read LICENSE.md directly rather than relying on the badge. This is a description of what the files say, not legal advice.

The practical licence consequence of MIT is that you can embed the server in a proprietary binary without publishing your own source. That is the whole point of the fork, and it is why the README contrasts MIT with GPL. If your organisation has a policy against copyleft dependencies, MIT clears that bar and GPL would not.

Upgrade cost is dominated by the compile-time configuration. Because features are selected with make flags such as WITH_ALL=1 and WITH_LUA=1, moving to a new version means rebuilding with the same flag set and re-verifying the features you enabled. The unit test target is civetweb_test and the Makefile notes that the unit tests include the source files directly to get visibility to the static functions, which means the test binary is built from source rather than against an installed library. There is a fuzztest/ directory and CI configuration in .github/, appveyor.yml and .travis.yml, so there is a testing story, but the README does not describe a supported upgrade path between releases. Plan for a rebuild and a re-test, not an in-place update.

## Conclusion

CivetWeb fits teams that need an HTTP listener inside a C or C++ binary and cannot accept GPL obligations: the embedding API in include/civetweb.h and the single-file src/civetweb.c are the reasons to pick it. It does not fit anyone who needs a broad module ecosystem, a documented rollback story, or a fast release cadence, since the most recent tagged release is v1.16 from 2023-04-10. Before adopting, check the LICENSE.md file yourself, since the repository metadata reports the licence as NOASSERTION while the README and Makefile header both describe MIT, and read docs/Embedding.md to confirm the API surface matches what you are embedding.

## FAQ

### What is CivetWeb?

CivetWeb is an embeddable C/C++ web server with optional CGI, SSL and Lua support, forked from Mongoose in 2013 and released under the MIT licence. It can be used as a library inside an existing application or as a stand-alone executable that needs no installation.

### Is there a CivetWeb alternative if I need a different licence or a different architecture?

The README names the project CivetWeb was forked from: Mongoose, which changed its licence from MIT to commercial plus GPL in 2013. libmicrohttpd is another embedded HTTP server library, typically paired with an external event loop rather than bundling its own connection handling.

### How does CivetWeb compare with Beast?

The repository does not discuss Boost.Beast, so no direct comparison can be made from the available documentation. What the README does state is that CivetWeb ships as a single source file for drop-in compilation with an API in include/civetweb.h, and that it can also run as a stand-alone server.

## Sources

- [civetweb/civetweb on GitHub](https://github.com/civetweb/civetweb)
- [Issues](https://github.com/civetweb/civetweb/issues)
- [README](https://github.com/civetweb/civetweb/blob/master/README.md)
- [Releases](https://github.com/civetweb/civetweb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/civetweb-civetweb