Core NATS will not hold a message for a subscriber that is offline. That is the first decision to make when evaluating NATS Server: can the application use live delivery, or must messages survive for later consumption?
Choose delivery semantics first
The Core NATS documentation describes subject-based publish-subscribe with at-most-once delivery. Interested subscribers connected at publication receive a copy; an offline or not-yet-subscribed client does not receive it later. Core NATS has no message storage or acknowledgments. The documentation also covers request-reply and queue groups, where one group member receives each message.
That model fits live signals when the next update can replace a missed one. It requires care when a missed event would leave application state incorrect. Decide which messages can be lost before choosing Core NATS alone.
JetStream adds persistence and replay through streams and consumers. Streams capture matching subjects; consumers track progress and acknowledgments. The documentation describes at-least-once delivery and redelivery when an acknowledgment does not arrive in time. Handlers therefore need a plan for repeated delivery, such as idempotent side effects.
JetStream configuration includes memory or disk storage, retention, and replication. Its key-value and object stores build on streams and consumers. These are documented capabilities, not workloads verified by our run.
What our recorded run establishes
Our stored run began on October 3, 2026, at 04:48:26.312 UTC, against commit c4eb4fc36b73d5bbe4c036babf77776a95abf8fb. It used a recorded configuration of 3 CPUs, 8 GB of memory, and image golang:1.24-bookworm. No new execution was performed for this review.
The install-labelled step exited 0 after 29.645 seconds, rounded to 30 seconds in the harness. Its retained tail says "go: downloading go1.26.8 (linux/amd64)". This establishes a toolchain download observation and successful command exit, rather than installation of the separate NATS CLI or an installed server check.
The build-labelled step exited 0 after 60.515 seconds, rounded to 61 seconds. Its retained tail is "vet-exit:0". Without the command text or a binary execution check, that evidence is insufficient to claim a compiled server was produced or started.
The go test step ran for 365.322 seconds and exited 1. Its parser summary records 18 passing and 6 failing results with total 24, plus a separate count of 4 packages without test files. Unique and exhaustive coverage was not verified, and the retained tail contains repeated summary lines. These figures should not be presented as 18 individual tests passing out of 24, or as a reconciled package pass rate. Packages without test files are not failed tests.
Visible failures extend beyond OCSP. The retained output includes a logger package failure alongside a Unix syslog delivery error; server failures naming TestAuthCalloutMultiAccounts, TestAuthCalloutLeafNodeAndConfigMode, and TestSystemAccountConnectionLimitsServersStaggered; and failures in the test package. Four visible OCSP groups expected a TLS bad-certificate error but received a connection-closed error with a broken-pipe write. The tail also contains register output without enough context to diagnose it.
The record supports investigating these failures. It does not show that revoked clients were accepted, establish a security vulnerability, or prove that messaging or JetStream is generally broken. It contains no measured messaging workload, installed-binary check, or security audit.
The repository scan recorded 598 files, approximately 474,543 source lines, 14.8 MB, 24 dependencies, 10 CI workflow files, and a tests directory. No Dockerfile or Compose file appeared in that scan. Those observations describe the scanned checkout, not all distribution options or dependency coverage.
Qualify the persistence path you intend to use
Issue #8505 reports a specific JetStream key-value recovery problem on nats-server v2.14.5 with NATS CLI 0.4.0. In the reporter's single-server, single-replica scenario, a TTL-purged key became readable again after an unclean shutdown and file-store state rebuild. The supplied issue extract shows it open and includes the reporter's workaround of retaining purge markers until older values are physically absent.
We did not reproduce that report. It is relevant qualification evidence for applications relying on that deletion path, rather than proof that every JetStream stream has the same behavior. Before storing authoritative state, test the retention, deletion, restart, and recovery paths your application actually uses.
The supplied v2.14.5 release notes remain relevant version documentation. The measured commit c4eb4fc is a separate identifier; this run should not be described as a test of that release tag.
Check rollout controls at the right level
Issue #6563 proposes paused connections and subscription or connection weights. It is not a complete inventory of routing capabilities. The discussion distinguishes existing subject mapping and weighting from the proposed subscription controls. The Core NATS documentation also describes server-side subject mapping that can split traffic by weight.
If gradual rollout is a requirement, specify whether you need subject-level traffic splitting, subscription weights, or paused delivery. Verify the exact mechanism rather than treating the proposal's open status as evidence that all weighted routing is unavailable.
Alternatives and next step
RabbitMQ's supplied README documents AMQP, MQTT, STOMP, quorum queues, and persistent replicated streams. Evaluate it when those protocols or queue and stream types match your requirements. Apache Kafka's README describes a distributed event streaming platform for pipelines, streaming analytics, and integration. Evaluate it for that role. The supplied extracts do not establish a comparative performance or ease-of-operation winner.
For NATS Server, start by writing down which subjects can tolerate missed messages and which require persistence. Then qualify a pinned release with the client behavior, acknowledgments, redelivery, and recovery procedures you intend to deploy. Obtain complete failure logs before assigning causes to the recorded test failures.
How the ratings work
These are editorial assessments of the supplied evidence, not benchmark results. The scale is 1 for evidence of major obstacles, 2 for substantial unresolved qualification, 3 for a documented basis with material verification gaps, 4 for broad supporting evidence with limited gaps, and 5 for comprehensive evidence across the assessed area. Unknown adoption and compatibility do not earn a high score.
Setup receives 2 because successful step exits do not verify a runnable installation. Documentation receives 4 because the supplied material explains delivery semantics, configuration choices, runnable examples, and version caveats, though we did not execute those examples. Community receives 3 because the README supplies contribution and support channels and the issues show maintainer discussion, without verified adoption or response-time measurements. Maturity receives 3 because persistence and version documentation provide a basis for evaluation, while the reported recovery issue and unresolved local failures require qualification.