# async-nats for Rust: Core NATS and JetStream Client

> async-nats is the current Tokio-based Rust client for Core NATS, JetStream, Key Value, Object Store, and Service API workloads. It favors cross-client API parity and conservative 0.x versioning, while Orbit carries faster-changing Rust-specific abstractions.

**nats-io/nats.rs** — Rust client for NATS, the cloud native messaging system.

- Repository: https://github.com/nats-io/nats.rs
- Stars: 1,556 · Forks: 292
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nats-io-nats-rs

## async-nats Targets Rust Messaging Workloads

The repository solves the problem of connecting Rust applications to NATS, including applications that need more than basic publish and subscribe operations. Its current client, `async-nats`, is built on Tokio and is intended for Rust services, distributed systems, embedded systems, and IoT environments. The README explains that Rust's type system can move many connection and subscription choices into compile-time errors instead of runtime checks.

The supported surface is broader than the Core NATS protocol. `async-nats` lists Core NATS, the JetStream API, JetStream Management API, Key Value Store, Object Store, and Service API support. That matters when selecting a library because an application may begin with ordinary request and reply messaging and later need durable streams, managed consumers, stored objects, or service-style interactions. The README also directs users to each crate's API documentation and to NATS by Example for runnable, cross-client reference examples.

The repository separates the active asynchronous client from the older `nats` crate. The latter is explicitly deprecated and receives only critical security fixes. New Rust integrations should therefore use `async-nats` rather than treating both packages as equivalent choices. The distinction matters because the two crates are connected to the repository history, but they do not share the same maintenance policy.

## Core Client and Orbit Define Different API Boundaries

The architecture is divided between `async-nats`, the core client in this repository, and Orbit, a separate set of crates for higher-level utilities. The core package provides direct APIs over Core NATS and JetStream as exposed by `nats-server`. It also handles wire-protocol coverage, authentication, TLS, reconnection, and the Service API. The README describes this layer as lightweight, unopinionated, and oriented toward API parity with official NATS clients in Go, .NET, Java, JavaScript, and Python.

Orbit sits above the core client. It provides opinionated helpers, Rust-specific abstractions, and experimental patterns that do not need to match the API shape of other NATS clients. Its crates use per-crate versioning, allowing a utility to change more frequently without forcing a version bump across the entire client. The documented rule is direct: thin mappings of features already spoken by `nats-server`, especially features expected across official clients, belong in core. Helpers and abstractions belong in Orbit.

This split has a practical consequence. A Rust developer who wants the lowest-level client behavior or cross-client consistency should inspect `async-nats`. A developer who prefers Rust-specific conveniences should check Orbit separately. The README does not claim that every JetStream or Core NATS capability has an Orbit equivalent, so the higher-level layer should not be treated as a complete replacement. For example, the core table assigns Core NATS connection, publish, subscribe, request and reply, JetStream, KV, Object Store, and Service API operations to `async-nats`, while assigning opinionated helpers, NATS contexts, KV codecs, distributed counters, and partitioned groups to Orbit.

## JetStream, KV, and Service APIs Extend Core Messaging

The feature list shows that `async-nats` can be used for several distinct message-processing models. Core NATS covers direct publish, subscribe, and request and reply operations. JetStream adds the API needed for persisted and managed messaging, while the JetStream Management API addresses administration of streams and consumers. The Key Value Store and Object Store features expose NATS-backed data patterns without requiring an application to implement those interfaces itself.

The Service API is included as well. This makes the client relevant to request and reply microservice designs, but it also means that selecting a NATS client is not equivalent to selecting only a topic publisher. The application still has to decide which server capabilities it needs, whether JetStream behavior is appropriate, and how consumers, acknowledgements, and service endpoints fit its failure model. The README does not document a universal configuration file or a server setup procedure in this repository.

The client is intended to be a protocol-level building block. It does not present Orbit's distributed counters, NATS contexts, KV codecs, or partitioned groups as part of the core API. Those are separate higher-level concerns, and their availability should be checked in the Orbit crates rather than assumed from the existence of JetStream support. The core client covers stream and consumer operations because those correspond to `nats-server` capabilities, while higher-level patterns remain outside its conservative API surface.

## Cargo Installation Starts With the Crates.io Package

The repository does not provide a shell installation command in the README. It directs users to the `async-nats` package on Crates.io and to the crate documentation on docs.rs. The README says to refer to the individual crate docs for API references and examples, so a first real integration should begin by consulting the published `async-nats` documentation and checking its feature configuration before writing application code.

The repository root is a Cargo workspace with two members, `async-nats` and `nats-server`, and it excludes the older `nats` directory. That layout indicates that the current client is developed inside a multi-crate Rust workspace, while the deprecated client is not part of the active workspace members. It does not document which server binary a local developer should install or how to start `nats-server` for a tutorial, so those steps cannot be replaced with invented commands.

The README specifically identifies a datetime feature choice. JetStream and Service datetime fields use `time::OffsetDateTime` by default. Enabling the optional `chrono` feature changes `async_nats::datetime::DateTime` and those fields to `chrono::DateTime<chrono::Utc>`. Because Cargo unifies features across a dependency graph, enabling `chrono` anywhere in the graph selects it for every consumer of `async-nats` in that build. This is the first configuration detail to check before integrating types into an existing Rust workspace. The `Cargo.toml` file documents the feature flags, but the README does not reproduce a complete application manifest.

## Versioning and Deprecated Package Affect Upgrade Planning

The current client is described as having a stable API while remaining on `0.x.x` versioning. The README attributes this to continuing ergonomic changes in the asynchronous Rust ecosystem. It also notes that some dependencies considered stable are still below version `1.0.0`, including `rustls`, and may introduce breaking changes that affect users. Consequently, `async-nats` should be reviewed as a 0.x dependency even though its API is described as stable.

Recent release entries include `async-nats/v0.50.0`, `async-nats/v0.49.1`, and `async-nats/v0.49.0`. The release names show versioned packaging, but they do not document migration procedures. The README does not provide a compatibility matrix for server versions, a rollback command, or a formal upgrade policy. A project should inspect the crate documentation and its own dependency lockfile when changing versions.

The repository is not archived, and its last push was on 2026-10-09. The release history includes versioned releases through 2026-07-20. These are maintenance signals, not a guarantee that every API will remain unchanged. The older `nats` package has a different lifecycle: it is deprecated, receives critical security fixes only, and should not be selected for new work.

The project uses the Apache-2.0 license. The README identifies Apache 2 for both clients. This is relevant when incorporating the crate into a distributed or proprietary application, but the repository does not replace review of the license text or application-specific legal obligations. License review should therefore be treated as a separate step from evaluating the client API.

## async-nats Is the Lower-Level Choice, Not a Full Application Framework

The clearest limitation is the boundary between core protocol access and application policy. `async-nats` offers the APIs needed to connect and interact with NATS, but the README does not claim that it chooses queue groups, retry policies, deployment topology, consumer retention, or service discovery for an application. Those decisions still belong to the service architecture and to the relevant NATS server configuration.

The two-client history also creates migration friction. Applications beginning a new Rust project can accidentally depend on the deprecated `nats` package because both names are associated with the repository. The documented direction is clear, but existing applications must audit their dependency names before assuming that APIs or examples transfer unchanged. The README does not provide a migration guide for the deprecated package.

The Orbit split can also limit expectations. Orbit is useful for opinionated patterns, but the README says it may lag, omit, or extend cross-client parity items. That makes it a different abstraction layer, not a guaranteed superset of core functionality. Teams should inspect both repositories when their design depends on KV codecs, distributed counters, NATS contexts, or other Rust-specific helpers. A core-only integration is therefore appropriate when protocol parity and a conservative API are the priority, while an Orbit-based design is more appropriate when application-specific abstractions matter more than matching official clients.

## Conclusion

Adopt async-nats for a Rust service that speaks directly to NATS and values a conservative client API, especially when JetStream, persistence, or request and reply patterns are required. Do not start with the deprecated nats crate or expect Orbit-style conveniences in the core package. Verify first that the required server capabilities and enabled Cargo features match your design, especially the choice between `time` and `chrono`.

## FAQ

### What is async-nats used for in Rust?

It is the current Tokio-based Rust client for NATS. The README lists Core NATS, JetStream, JetStream Management, Key Value Store, Object Store, and Service API support.

### Should a new Rust project use nats or async-nats?

The README marks `nats` as deprecated and says it receives only critical security fixes. It directs users to `async-nats` for the current client.

### How do I choose between time and chrono in async-nats?

JetStream and Service datetime fields use `time::OffsetDateTime` by default. Enabling the optional `chrono` feature changes `async_nats::datetime::DateTime` and those fields to `chrono::DateTime<chrono::Utc>`.

## Sources

- [Issues](https://github.com/nats-io/nats.rs/issues)
- [License: Apache-2.0](https://github.com/nats-io/nats.rs/blob/main/LICENSE)
- [nats-io/nats.rs on GitHub](https://github.com/nats-io/nats.rs)
- [README](https://github.com/nats-io/nats.rs/blob/main/README.md)
- [Releases](https://github.com/nats-io/nats.rs/releases)

---

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