# Actix Net: the lower layer of crates under the Actix web stack

> actix-net is a Cargo workspace of eleven crates that supply runtime, codec, TLS, server, service and tracing pieces for network services in Rust, published individually with a 1.89 MSRV. It is the layer to reach for when a full web framework would be more than you need.

**actix/actix-net** — A collection of lower-level libraries for composable network services.

- Repository: https://github.com/actix/actix-net
- Website: https://actix.rs
- Stars: 776 · Forks: 367
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/actix-actix-net

## Eleven crates in one workspace, published on separate schedules

actix-net is described as a collection of lower-level libraries for composable network services, and the repository is a Cargo workspace rather than a single crate. The workspace members list is the clearest statement of what the project contains:

```toml
homepage = "https://actix.rs"
license = "MIT OR Apache-2.0"
edition = "2021"
rust-version = "1.89"
```

The member crates are actix-codec for framing and codec traits, actix-macros for the derive macros, actix-rt as the runtime, actix-server for the server loop, actix-service for the service abstraction, actix-tls for TLS, actix-tracing for instrumentation, actix-utils for shared helpers, plus bytestring, local-channel and local-waker. Two of those last three are internal building blocks that exist so the others can share an efficient byte string type and coordinate wakeups without pulling in a heavier dependency.

Because each member is its own crate, each is versioned and released on its own schedule. The recent release list shows actix-server 2.10.0 published on 2026-10-13, actix-server 2.9.8 on 2026-10-02 and actix-server 2.9.7 on 2026-09-25, so the server crate alone moved three times in three weeks. This is a workspace that ships in pieces, and dependency management has to be done per crate rather than for the repository as a whole. The last push was on 2026-10-17.

## The workspace manifest patches crates.io back onto local paths

The Cargo.toml contains a patch section that redirects every member crate to its in-repository path, which is a common trick in multi-crate workspaces and has a concrete effect worth understanding. Instead of pulling actix-codec from crates.io during a local build, the build uses the source in the tree, so a change to one crate is picked up by the others without a publish step.

```toml
[patch.crates-io]
actix-codec = { path = "actix-codec" }
actix-macros = { path = "actix-macros" }
actix-rt = { path = "actix-rt" }
actix-server = { path = "actix-server" }
actix-service = { path = "actix-service" }
actix-tls = { path = "actix-tls" }
actix-tracing = { path = "actix-tracing" }
actix-utils = { path = "actix-utils" }
bytestring = { path = "bytestring" }
local-channel = { path = "local-channel" }
local-waker = { path = "local-waker" }
```

The same file also sets the release profile to a single codegen unit with link time optimisation and optimisation level 3, and it defines workspace-wide lint rules. The rust lints deny the 2018 idioms group, nonstandard style and future incompatible code, and warn on missing documentation. The clippy configuration warns on uninlined format arguments and on disallowed names. Those lint tables are enforced for every member at once, which is what keeps eleven crates looking like one project rather than eleven separate ones.

For a user of the crates this is invisible except as a quality signal. For a contributor it is the reason a change in actix-utils cannot quietly introduce a style that the other crates do not follow.

## The justfile is the real entry point for contributors

The repository drives its own checks through a justfile, and it is a better guide to the project's workflow than any prose would be. The check recipe runs the formatter in check mode, then prettier over markdown and YAML files, then taplo for formatting and linting TOML files, and finally cargo +nightly fmt -- --check. The format recipe performs the same operations in write mode.

Lint runs across the entire workspace with all targets and all features enabled:

```bash
    cargo {{ toolchain }} clippy --workspace --all-targets {{ all_crate_features }}
```

The test recipe has an interesting shape. The actix-macros package is tested with the standard cargo test invocation, because it needs the standard harness, and the rest of the workspace is tested with cargo nextest, which is run twice: once with no default features, and once with all features. Running both is how the project checks that a crate behaves the same whether or not a user enables the optional parts.

There is a per-OS split in the file. The linux, macos and windows recipes are declared separately, and the linux variant differs in its final test invocation, which is how platform-specific behaviour is exercised rather than assumed.

## MSRV 1.89 with a policy that allows it to move in non-breaking releases

The README states that the crates in the repository have a Minimum Supported Rust Version of 1.89, and it states a policy alongside that number: MSRV increases are permitted in non-breaking releases. That combination is unusual enough to be worth reading twice. A strict MSRV promise that cannot move is a promise that eventually gets broken, whereas a policy that allows the floor to rise on a semver-minor bump tells users that an upgrade of the minor version may require a newer toolchain.

The project has tooling to keep that promise honest. The justfile has a private downgrade-for-msrv recipe that reads the rust_version field out of cargo metadata, normalises a bare 1.89 into a full 1.89.0, and constructs a toolchain string from it. A clippy-msrv recipe depends on that downgrade step and then runs clippy pinned to the MSRV toolchain, so linting happens against the oldest supported compiler rather than only the newest.

Practically, this affects your upgrade planning. A patch update within a crate is unlikely to move the floor, but a minor update can, and the changelog for the crate is where you would see it. The lockfile in the repository and the pinned dependency graph in Cargo.lock make the reproducibility story concrete, and the project also carries a deny.toml for dependency policy checks and a flake.nix for a reproducible development environment.

## Choosing a subset is the normal way to use these crates

The important structural point for a new user is that actix-net is not a framework you adopt wholesale. It is a set of pieces, and a service may want only some of them. A service that needs an async runtime and a codec but not TLS and not a server loop can depend on actix-rt and actix-codec alone. A service that wants structured logging adds actix-tracing, and one that terminates TLS connections adds actix-tls.

That composition is the point of the project, and it is also the real alternative to going higher up the stack. If you want a complete HTTP application with routing, extractors, middleware and form handling, you are looking at a different layer entirely and this workspace is beneath it. If you are writing a protocol server, a proxy, a gateway or a long-lived socket service, the pieces here are the ones that matter, and pulling in a full web framework to get them would be wasteful.

The examples live next to the code. The README points to example folders for actix-server and actix-tls, which is the shortest path to seeing how a server loop and a TLS layer are meant to be put together in this codebase rather than in someone else's.

## Dual licensing and an enforced code of conduct

The crates in the repository are offered under either of two licences at the reader's option, Apache License 2.0 or the MIT licence, and the workspace package metadata encodes exactly that as MIT OR Apache-2.0. The double option is a common pattern in the Rust ecosystem and it removes a decision point: a downstream project that has a policy against one of them can pick the other without asking the author to change anything.

What the option does not cover is the licences of the dependencies the crates pull in, which is the usual boundary for this kind of statement and is worth keeping in mind when the dependency graph is audited. The repository includes a deny.toml, which is the configuration file used to check dependency licences and advisories, and the presence of that file suggests the check is automated rather than manual.

Contribution is handled under the Contributor Covenant, and the README records a promise from the Actix team to intervene to uphold it. The tree also carries a CODE_OF_CONDUCT.md file and a set of GitHub workflows, so the contribution process is defined in the repository rather than only on a web page.

## Conclusion

Adopt actix-net when you are assembling a network service in Rust and want the runtime, codec and TLS pieces without a full web framework on top, and stay away when you want a batteries-included request router and would rather not compose those yourself. Before pinning versions, check each crate separately, because actix-server 2.10.0 shipped on 2026-10-13 while the rest of the workspace moves on its own schedule, and read the justfile clippy-msrv target to see how the project itself verifies Rust 1.89 compatibility.

## FAQ

### What is actix-net and which crates does it contain?

It is a Cargo workspace of lower-level libraries for composable network services, with members actix-codec, actix-macros, actix-rt, actix-server, actix-service, actix-tls, actix-tracing, actix-utils, bytestring, local-channel and local-waker. Each crate is published and versioned separately.

### What is the minimum Rust version for actix-net?

The crates have a Minimum Supported Rust Version of 1.89, and the README states that MSRV increases are permitted in non-breaking releases. The project verifies that floor with a clippy-msrv recipe that runs linting against the MSRV toolchain.

### Which licence applies to the actix-net crates?

The crates are offered under either Apache License 2.0 or the MIT licence, at the option of the user, and the workspace metadata records it as MIT OR Apache-2.0. Dependency licences are a separate matter and the repository carries a deny.toml for that check.

### How do I run the tests and lints for actix-net?

The justfile holds the recipes. Linting runs cargo clippy over the workspace with all targets and all features, and testing runs actix-macros with cargo test and the rest of the workspace with cargo nextest, once with no default features and once with all features.

## Sources

- [actix/actix-net on GitHub](https://github.com/actix/actix-net)
- [License: Apache-2.0](https://github.com/actix/actix-net/blob/main/LICENSE)
- [Project website](https://actix.rs)
- [README](https://github.com/actix/actix-net/blob/main/README.md)
- [Releases](https://github.com/actix/actix-net/releases)

---

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