uWebSockets is Apache-2.0 with a fork condition, and one app per thread

The licence is Apache-2.0 with a condition attached to forks

The last section of the README is titled Permissively licensed, and the first line is a reservation rather than a grant: intellectual property, all rights reserved. Then the actual terms.

Where such explicit notice is given, source code is licensed Apache License 2.0, which it describes as a permissive OSI-approved license with very few limitations. Then the condition: modified forks should be of nothing but licensed source code, and be made available under another product name. And then the sentence that settles any ambiguity: if you're uncertain about any of this, please ask before assuming.

So the package metadata reports Apache-2.0 and the README describes something narrower. A fork that is only licensed source, published under a different name, is inside what the project describes. A fork that carries the uWebSockets name and adds your own application code is outside it, by the project's own statement of its terms. That is a materially different position from a plain Apache-2.0 grant, and it is easy to miss because the repository is presented as permissively licensed and the metadata a tooling system reads says Apache-2.0.

The instruction to ask is not boilerplate, it is the author telling you the terms are conditional. If a fork is part of your plan, that mail address in the commercial support section is the address the README points you to.

One SSLApp per thread, and they share the listening port

The example in the README is short and its first comment is the architecture:

/* One app per thread; spawn as many as you have CPU-cores and let uWS share the listening port */
uWS::SSLApp({

    /* These are the most common options, fullchain and key. See uSockets for more options. */
    .cert_file_name = "cert.pem",
    .key_file_name = "key.pem"

}).get("/hello/:name", [](auto *res, auto *req) {

    /* You can efficiently stream huge files too */
    res->writeStatus("200 OK")
       ->writeHeader("Content-Type", "text/html; charset=utf-8")
       ->write("<h1>Hello ")
       ->write(req->getParameter("name"))
       ->end("!</h1>");

}).ws<UserData>

An app object is constructed per thread, the number of them follows your CPU core count, and the library shares the listening port between them. The app is not a connection pool and not a shared object; it belongs to a thread.

The response chain is worth reading for its own sake. `res` is returned by every call so the writes chain, `write` takes a piece, and the response is not finished until `end`, which is what makes the comment about streaming huge files true rather than aspirational. The route syntax is a path with a parameter, `/hello/:name`, read back with `getParameter`. The trailing `.ws<UserData>` is where WebSocket handling is attached, and the template argument is the per-connection user data type.

The top level also has a `cluster/` directory.

The build flags are environment variables, and the Makefile is a Windows shim

The file named `Makefile` in this repository is not the POSIX makefile. It opens with a comment saying it is the NMake shim for Windows, marked WIP, and gives a PowerShell one-liner as its example. The README's own build example is:

WITH_WOLFSSL=1 WITH_LIBUV=1 make examples

That is the POSIX form. The Windows form sets environment variables before invoking nmake, among them `WITH_ZLIB`, `WITH_LTO`, `CC`, `CFLAGS`, `LDFLAGS`, `CXX`, `EXEC_SUFFIX` and `WITH_LIBUV`, with paths pointing into a vcpkg installation, and ends with `nmake`.

Two things follow. The POSIX makefile is `GNUmakefile`, which make picks up by convention, so `make` works on Linux and macOS while the file you would reach for first is the Windows one. And the build configuration is environment variables rather than make variables, which means a CI pipeline has to export them into the environment rather than pass them on a command line.

The other unusual part is that the build tool is a C program. `build.c` and `build.h` sit at the top level, and every target in the shim runs one of two executables, `.\build.exe` or `.\a.exe`, with a fallback between them. You compile the build tool before you can use it to compile the library.

The three layers are named in the compile line, not in a configuration file

The README describes uSockets as a foundation library implementing eventing, networking and cryptography in three different layers, where every layer has multiple implementations and you control the compiled composition with flags. The default target in the shim Makefile makes that concrete, because the compile line names the three source directories explicitly:

$(CC) $(CFLAGS) -DLIBUS_NO_SSL -std=c11 -Isrc -O3 -c src/*.c src/eventing/*.c src/crypto/*.c

`src/*.c` is the networking layer, `src/eventing/*.c` is the event loop, and `src/crypto/*.c` is the cryptography. The `-O3` is unconditional in that line, which is consistent with the README's claim that the library is meticulously optimized for speed and memory footprint.

The consequence is architectural rather than cosmetic. Your eventing and TLS choices are fixed when the binary is built, so there is no runtime switch, and a project that wants to change from a raw kernel event loop to libuv is looking at a rebuild. The two documented flag combinations are:

WITH_OPENSSL=1 make examples

for OpenSSL with the native kernel, and the WolfSSL with libuv pairing above it, with the README deferring to uSockets for the up-to-date list of flags.

Five event-loop integrations claimed, four named

One sentence in the architecture section is worth reading carefully, because the count and the list do not obviously agree. There are currently five event-loop integrations; libuv, ASIO, GCD and raw epoll/kqueue.

Four names for five integrations, unless the last item is two integrations, which is plausible since epoll is Linux and kqueue is the BSD and macOS equivalent, and a server that supports both would count them separately. The wording does not say which.

Either way the practical answer is the same: the choice is a compile flag, so it is a decision about which platforms you will ever ship to. The raw epoll/kqueue option ties you to an operating system family.

For a reader evaluating the library, the honest summary is that the eventing abstraction is a build-time selection from a small fixed set, not a pluggable interface, and that the flags list is maintained in the uSockets project rather than here.

Every security claim in the README is footnoted to a directory you can open

The marketing paragraphs carry superscript footnotes, and following them is the most useful thing a reader can do here. The word simple points at the fuzzing directory, the standards compliant claim points at a report PDF, and the demanding applications claim points at a benchmarks page described as benchmark-driven development.

The security paragraph itself states four things. The library is optimized for speed and memory footprint to the point that it does encrypted TLS 1.3 messaging faster than most alternative servers do unencrypted cleartext messaging. It partakes in Google's OSS-Fuzz with roughly 95 percent daily fuzzing coverage and no sanitizer issues. LGTM scores it a flawless A+ from zero CodeQL alerts. And it compiles with pedantic warning levels.

All of those are self-reported, and the repository lets you check them. The top level contains `fuzzing/`, `autobahn/` for the Autobahn|Testsuite compliance run, `h1spec` for the HTTP/1.1 specification tests, and `benchmarks/`. The badge row also links an OSV query filtered to the OSS-Fuzz ecosystem and affected packages only, which is a vulnerability feed for the project published by a third party.

The claim of a perfect Autobahn|Testsuite score since 2016 comes with the same treatment, footnoted to the report PDF. A project that points its own claims at its own test directories is doing the thing that makes a claim checkable.

The Node route is a different repository, and the TypeDoc belongs to it

The rapid scripting paragraph is short: uWebSockets is written entirely in C and C++, and it also ships a binding for Node.js backends so an app can be scripted in JavaScript, and then it links to uWebSockets.js.

That binding is a separate project. So if you are a JavaScript developer, the library you are evaluating is a native addon with its own repository, its own version line and its own documentation.

The documentation link confirms it. The README says you can browse the TypeDoc for a quick overview, and the URL in the README points at `unetworking.github.io/uWebSockets.js/generated/`, which is the generated API documentation for the JavaScript binding rather than for the C++ headers. The user manual is a separate file, `misc/READMORE.md` in this repository, and the examples are in `examples/`.

So there are three documentation surfaces and you need to know which one answers your question: the TypeDoc for the Node binding, the READMORE manual for the C++ library, and the examples directory for working code. The primary language of this repository is C++, and the examples are `.cpp` files, which is the practical signal about who the design is for.

The examples reach HTTP/3, and support is a Swedish consultancy

The examples directory lists twenty-one files, and the names describe the surface area better than any feature list would. There is `HelloWorld.cpp` and `HelloWorldThreaded.cpp`, `EchoServer.cpp` and `EchoServerThreaded.cpp` for the one-app-per-thread model, `Broadcast.cpp` and `BroadcastingEchoServer.cpp` for the pub/sub side, `HttpServer.cpp`, `HttpCache.cpp`, `Precompress.cpp` and `SecureGzipFileServer.cpp` for HTTP concerns, `ParameterRoutes.cpp` for the router, `ServerName.cpp` for TLS server name handling, `Client.cpp`, `Crc32.cpp`, and `SmokeTest.cpp`.

The one that stands out is `Http3Server.cpp`. HTTP/3 in the examples rather than on a roadmap, in a project whose foundation library provides the networking layer.

Alongside the code there is a company. uNetworking AB is described as a Swedish consulting and contracting company dealing with anything related to uWebSockets, specifically development, support and customer success, with a mailto address and an invitation to get in touch if you are building something large. The README also thanks BitMEX, Bitfinex, Google, Coinbase, Bitwyre, AppDrag and deepstreamHub for allowing the project itself to thrive on GitHub since 2016, and states the project would not be possible without them.

Put the two facts together and the governance is legible: the code is open under a conditional licence, and the commercial path is a consultancy.

Editorial conclusion

uWebSockets fits a team that needs a low-latency HTTP and WebSocket server, that is willing to commit to a compile-time eventing and TLS choice, and that has a C or C++ toolchain plus a place to own the build. It does not fit a JavaScript or Python shop, since the Node route is a separate repository, uWebSockets.js, and it does not fit a plan to fork the project and keep the name, because the README states that modified forks should be of nothing but licensed source code and be made available under another product name. Before adopting, check three things: that licence paragraph, which asks you to write before assuming anything about a fork, the `WITH_LIBUV` or `WITH_OPENSSL` flag combination your target needs, since the eventing and crypto layers are compiled in rather than chosen at runtime, and whether `make` resolves to `GNUmakefile` on your platform, because the file named `Makefile` in this repository is a Windows nmake shim marked WIP.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. uNetworking/uWebSockets on GitHub