# Netty: an event-driven network framework for Java protocol servers > Netty is an asynchronous, event-driven framework for building protocol servers and clients on the JVM. It is a library, not a server you deploy, and its 4.2 line requires Java 8 or newer. **netty/netty** — Netty project - an event-driven asynchronous network application framework. - Repository: https://github.com/netty/netty - Website: http://netty.io - Stars: 35,068 · Forks: 16,271 - Language: Java - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/netty-netty ## What Netty solves, and who ends up using it Netty exists for the layer below HTTP frameworks. If you are implementing a wire protocol, a custom binary format, a proxy, or a client that holds thousands of sockets open, the JDK gives you threads and blocking streams and leaves the rest to you. Netty packages the asynchronous, event-driven part into a reusable library. The README describes it as "an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients." The audience is narrower than the download numbers suggest. You are the right reader if you are writing a server or client for a protocol that is not already solved for you, or if you are building infrastructure that other applications sit on. You are the wrong reader if you want to deploy an application and configure it. Netty has no main method, no configuration file, and no process to start. It is a set of JARs you call from your own code. The repository layout shows how far that scope reaches. Top-level modules include codec-http, codec-http2, codec-http3, codec-dns, codec-mqtt, codec-redis, codec-smtp, codec-stomp, codec-memcache, codec-protobuf, codec-socks, codec-haproxy, codec-marshalling and codec-xml. Each is a protocol implementation built on the same event loop. That is the real product: one concurrency model, many protocols. ## Event loops, channels and the pipeline as the actual mechanism The architecture visible in the repository is a pipeline over an event loop. A channel represents a connection. An event loop owns a set of channels and processes their events on one or a small number of threads. Handlers are placed in a pipeline attached to each channel, and bytes flow through that pipeline as events rather than as blocking reads. This is why Netty is described as event-driven rather than merely non-blocking. The framework does not hand you a socket and let you read from it; it calls your handlers when something happens. The consequence is that a handler that blocks stalls every channel assigned to that event loop. The documentation does not protect you from this. It is the central operational constraint of the design, and it is why CPU-bound or JDBC-bound work in a handler is a common source of production stalls. The module split reinforces the same idea. common/ holds shared utilities, buffer/ holds the byte buffer abstraction, transport and resolver modules handle the underlying I/O and name resolution, and the codec modules sit on top. The 4.2 branch is the current development line; the README states that development of each version takes place in a branch named after its major and minor version, so 4.1 and 4.2 are maintained as separate branches rather than one line moving forward. ## Getting Netty into a build and running the example Netty is consumed as a Maven dependency, not installed as a service. The README points to the downloads page and the wiki for documentation, and the repository ships a bom/ module for dependency management. A typical starting point is the all-in-one artifact, which the repository exposes through the all/ module. The exact coordinates appear in the repository's own build files rather than in the README, so take the groupId, artifactId and version from bom/ or all/ in the branch you are targeting instead of typing them from memory. If you would rather not pull every codec, use the BOM to align versions and depend only on the modules you need, such as netty-codec-http or netty-codec-dns. The bom/ module exists for exactly that purpose. To see something run, the repository includes an example/ directory with its own pom.xml, and a run-example.sh script at the top level. The README does not document the script's arguments, so read example/pom.xml and the script before running it. Building Netty from source is a separate exercise: the README requires the latest stable OpenJDK 8 and Apache Maven, and notes that on Linux or macOS you need additional development packages because the native transport is built as part of the build. That is a build-time requirement only. The README states that JDK 6 is enough to run a Netty-based application on the 4.0 and 4.1 lines, while 4.2 requires Java 8 or newer. ## Where Netty is the wrong tool Netty is not a web server and not a servlet container. If your requirement is to serve HTTP endpoints with routing, session handling and deployment tooling, Netty gives you the transport and leaves the rest to you or to a framework built on top of it. Choosing it directly for that job means writing code that a container would have provided. The second limitation is the blocking trap described above. There is no mechanism in the framework that detects a handler blocking its event loop. The failure mode is latency that appears under load and is hard to attribute, because the thread is not stuck in the code you would expect. The third is the native transport. The optional io_uring transport requires Java 9 or newer, which is a higher floor than the 4.2 line itself, and the README notes that building the native transport on Linux or macOS requires additional development packages installed on the system. Teams that want the native path take on a build and platform dependency that the pure-Java path does not have. Finally, the project has no configuration surface to tune. Sizing event loops, choosing allocators and setting watermarks are decisions you make in code. There is no file to edit when something misbehaves in production. ## Netty against Tomcat, Jetty and Vert.x The most common comparison is with Tomcat and Jetty, and the difference is one of category. Tomcat and Jetty are servlet containers: you deploy an application into them and they own the HTTP layer, the thread pool and the lifecycle. Netty is the layer those containers could be built on. If your application is a set of HTTP endpoints, a container gives you more for less code. If your application is a protocol that HTTP containers do not speak, a container gives you nothing. Vert.x is the closer alternative in spirit. It is also asynchronous and event-driven, but it presents an application toolkit with its own programming model and polyglot support, whereas Netty presents a transport framework that you compose. Choosing Vert.x means adopting its model; choosing Netty means building your own on top of its pipeline. The trade is control against the amount of scaffolding you write yourself. Comparisons with nginx are category errors. nginx is a server binary you configure and run. Netty is a library you compile into your own process. They can sit in the same architecture, with nginx terminating connections in front of a Netty-based service, and neither replaces the other. ## Maintenance, branches and the Apache-2.0 licence The repository is not archived. The most recent push recorded for the default 4.2 branch is 2026-08-06, and releases in the same period include netty-4.1.137.Final and netty-4.2.17.Final, both dated August 2026, with netty-4.1.136.Final in July 2026. That pattern matters for upgrade planning: the 4.1 and 4.2 lines are both receiving releases, so a team on 4.1 is not on an abandoned branch, but it is also not on the branch where new development happens. The README is explicit that development of each version lives in a branch named .. That means upgrading from 4.1 to 4.2 is a branch move, not a patch bump, and the upgrade cost is whatever your code depends on across that boundary. Nothing in the README describes a migration path between the two lines, so that is something to establish from the release notes before committing. Netty is licensed under Apache-2.0. That is a permissive licence, and the repository carries LICENSE.txt and NOTICE.txt at the top level. This is not legal advice: if you redistribute Netty inside a product, read those two files and your own obligations rather than assuming the licence text alone answers the question. ## Conclusion Adopt Netty when you are writing a custom protocol or need one event loop to drive many connections, not when you want a servlet container or a general web server. Verify first that your target Java version matches the branch you pick, since 4.2 requires Java 8 or newer and the io_uring native transport requires Java 9 or newer, and confirm which modules you actually need from the BOM rather than pulling the whole tree. ## FAQ ### What is Netty used for? It is used to build asynchronous, event-driven protocol servers and clients on the JVM. The repository ships codec modules for HTTP, HTTP/2, HTTP/3, DNS, MQTT, Redis, SMTP, STOMP, Memcache, SOCKS, HAProxy, Protobuf, Marshalling and XML, all built on the same event loop model. ### Is Netty a web server? No. It is a network application framework, not a server binary you deploy or configure. It provides the transport and pipeline that a web server or HTTP framework could be built on, and it has no main method or configuration file of its own. ### Is Netty better than Tomcat? They are different categories rather than competing options. Tomcat is a servlet container that owns the HTTP layer, thread pool and lifecycle, while Netty is a framework you compose your own protocol handling with. Netty is the better fit when you are implementing a protocol a container does not speak; Tomcat is the better fit when you are deploying HTTP endpoints. ### How does Netty differ from Jetty? Jetty is a servlet container, so it gives you an application lifecycle and an HTTP layer to deploy into. Netty gives you an event loop and a handler pipeline and leaves the application structure to you. The choice follows from whether your protocol is HTTP-shaped or not. ### What does Netty mean? The README gives no expansion or meaning for the name. It presents Netty only as the name of the project and of the framework itself, so the name carries no documented technical meaning in the repository. ### Is Netty a word? The repository offers no dictionary or linguistic claim about the name. It appears only as a project name in the README, the module names and the artifact coordinates. ## Sources - [Official documentation](http://netty.io) - [Official README](https://github.com/netty/netty#readme) - [Project repository](https://github.com/netty/netty) - [Release notes](https://github.com/netty/netty/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netty-netty