build(deps): bump nats-server to v2.14.7

[dagil-nvidia]

Overview:

Moves the pinned nats-server from v2.12.14 to v2.14.7, the newest stable release on the current line. v2.12.14 is built on a Go toolchain two minor releases behind current; the 2.14 line carries the current one.

Details:

nats_version in container/context.yaml is the single source for the .deb that dynamo_base.Dockerfile installs, and container/compliance/native_packages.yaml carries the same version string for attribution. Both move together.

nats skipped 2.13 entirely, so 2.12 to 2.14 is the adjacent line rather than a two-line jump, and the upstream 2.14 upgrade guide covers 2.12 compatibility directly.

v2.14.7 rather than v2.14.6: both carry the current toolchain, v2.14.7 is the newer of the two, and v2.15.0 is still pre-release (v2.15.0-RC.2).

Summary

• container/context.yaml: nats_version: v2.12.14 to v2.14.7
• container/compliance/native_packages.yaml: matching nats-server version bump

Validation

• python3 container/render.py --framework vllm --device cuda --cuda-version 13.0 --target runtime --platform linux/amd64 - renders; emitted ARG NATS_VERSION=v2.14.7
• pre-commit run --files container/context.yaml container/compliance/native_packages.yaml - all applicable hooks pass (check yaml, codespell, mixed line ending, trim trailing whitespace)
• Release-asset check against the upstream tag - nats-server-v2.14.7-amd64.deb and nats-server-v2.14.7-arm64.deb are both published, so the nats-server-${NATS_VERSION}-${TARGETARCH}.deb pattern in dynamo_base.Dockerfile resolves on both build architectures

Not validated locally: no container build was run. The image build is what exercises the dpkg -i step and the runtime nats-server startup, so full CI is the gate here.

Where should the reviewer start?

container/context.yaml. The only question worth asking is whether 2.12 to 2.14 is acceptable as a single step for the messaging plane; the rest is a version string in two places.

Related Issues

🚫 This PR is NOT linked to an issue:

• Confirmed - no related issue

Summary by CodeRabbit

• Updates
  • Updated the bundled NATS Server version to v2.14.7.
  • Updated Dynamo's default NATS version to v2.14.7.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-16T04:27:16.307727Z	0c903fe	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 1a07966c-0002-43b3-aebc-e98ed71fec48

📥 Commits

Reviewing files that changed from the base of the PR and between 30e1580 and 0c903fe.

📒 Files selected for processing (2)

• container/compliance/native_packages.yaml
• container/context.yaml

Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review.

---

Walkthrough

Changes

NATS version alignment

Layer / File(s)	Summary
Update NATS version declarations container/context.yaml, container/compliance/native_packages.yaml	The Dynamo default and nats-server native package record now use v2.14.7 instead of v2.12.14.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 0c903

The NATS version update is consistently wired across the configuration and compliance records, with no concrete merge-blocking risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely identifies the dependency update from nats-server to v2.14.7.
Description check	✅ Passed	The description includes all required sections, explains the version change, identifies the affected files, provides validation results, states the review starting point, and confirms that no related …

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0c903fe23d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dagil-nvidia]

/ok to test 0c903fe

[dmitry-tokarev-nv]

Approving. Zero P0, zero P1, zero P2 and zero P3 findings. This is a two-line version string change and it holds up under every check I ran.

What I established about the delta

The author's claim that nats skipped 2.13 is correct. I listed all 305 upstream tags and there is no v2.13.* tag of any kind. Each 2.14 release note repeats the same line: "Please note that the 2.13.x version was skipped."

I read the release notes for every version in the range, v2.14.0 through v2.14.7, plus the upstream 2.14 upgrade guide at docs.nats.io/release-notes/whats_new/whats_new_214. Three answers:

1. Wire protocol and client handshake: no break. The server still reports proto=1 and the same INFO shape. I measured this, see below.
2. Configuration keys and defaults: no key was renamed or removed, and no default changed that this repository depends on. The one format change is the domain-aware $JS.ACK and $JS.FC subject format. It is opt-in behind the js_ack_fc_v2 feature flag in 2.14, and it becomes the default in 2.15. A repository-wide grep for $JS.ACK, $JS.FC, feature_flags and js_ack_fc_v2 returns nothing, so this repository has no ACL or import that pins the old format.
3. Removals and deprecations: one removal in v2.14.3, JSONP callback support on the monitoring endpoints. dev/nats-server.conf exposes http_port: 8222 but nothing in this repository calls a monitoring endpoint with a JSONP callback.

Two behavior changes are worth knowing about, and neither blocks this change. Under a filesystem I/O error, a JetStream stream now freezes and reports unhealthy instead of continuing, and it needs a server restart to recover. And on a downgrade back to 2.12, a feature_flags block must be removed first. This repository writes no feature_flags block, so a rollback to v2.12.14 stays clean.

Client compatibility

The Rust event plane uses async-nats 0.49.1 (Cargo.toml:101, and the same version in Cargo.lock). The test suite also uses nats-py==2.12.0 (container/deps/requirements.test.txt:49).

I ran both servers side by side on macOS ARM64, both started from the repository's own dev/nats-server.conf, and ran the same probe against each. The old pin is the control:

### v2.12.14 (base pin, control)
server_version=2.12.14 max_payload=15728640 proto=1 headers=true jetstream=true
core_payload_ok=true
kv_ok=true rev=1
kv_cas_ok=true
kv_watch_ok=true
objstore_ok=true
js_consumer_ok=true
service_ok=true

### v2.14.7 (this PR)
server_version=2.14.7 max_payload=15728640 proto=1 headers=true jetstream=true
core_payload_ok=true
kv_ok=true rev=1
kv_cas_ok=true
kv_watch_ok=true
objstore_ok=true
js_consumer_ok=true
service_ok=true

The probe covers what lib/runtime actually uses: core publish and subscribe, request and reply, the JetStream KV store with a compare-and-set update and a watch, the JetStream object store, a durable pull consumer, and the async-nats service API. The nats-py client gave the same result on both servers for KV and object store.

Both servers parse dev/nats-server.conf with no warning and no unknown-key error. The keys in that file are max_payload, jetstream, http_port and trace, and all four are still accepted. max_payload still reports as 15728640 to the client on both.

I also ran the exact flag set that tests/conftest.py:869 uses against the new binary, which is nats-server --trace -p <port> -js --store_dir <dir>. It starts clean.

The default path

A deployment that changes no configuration gets the same behavior. The evidence is the identical probe output above, the identical max_payload reported over the wire, and the fact that the one format change in the range is opt-in.

The install path

I unpacked both .deb files and compared the layout, because two templates copy the binary from two different paths:

v2.12.14: ./usr/bin/nats-server  ./usr/local/bin/nats-server
v2.14.7:  ./usr/bin/nats-server  ./usr/local/bin/nats-server

Both paths still exist, so container/templates/planner.Dockerfile:57, which copies from /usr/local/bin, and the four runtime templates, which copy from /usr/bin, both keep working. The dpkg Package name is unchanged. The upstream LICENSE at tag v2.14.7 is still Apache-2.0, so the license: Apache-2.0 line in container/compliance/native_packages.yaml stays correct.

Other places this repository pins nats

I searched the whole tree. Nothing else needed to move with this change:

1. deploy/helm/charts/platform/values.yaml:514 pins the Helm chart server image at 2.10.21-alpine.
2. dev/docker-compose.yml:13 pins nats:2.11.4.
3. lib/backend-common/examples/mocker/docker-compose.yml:35 pins nats:2.11.4.
4. recipes/kimi-k2.5/tokenspeed/agg/nvidia/deploy.yaml:108 pins nats:2.12.4, and the README and Dockerfile comments name the same tag.

All four already differed from the v2.12.14 image pin before this pull request, so the divergence is not introduced here and I am not raising it as a finding. Each of these is a separate standalone server, so no two of them ever join one cluster. container/context.yaml remains the single source for the version that dynamo_base.Dockerfile installs, and container/compliance/native_packages.yaml carries the same string for attribution only. Both moved together in this diff.

The baseline_sbom entries in container/context.yaml do not cover this. They record base-image contents, and nats-server is installed by this repository on top of the base image, so no baseline needs re-capture. The Compliance audit job passes on this head for every runtime image.

The two bot comments

Both premises are wrong, and I replied on each thread with the measurement.

1. v2.14.7 is a published stable release. It is the value of releases/latest, it has prerelease=false, and both .deb assets return HTTP 200.
2. The commit does carry Signed-off-by. Both DCO checks report SUCCESS.

Boundaries

I did not build a container image. My server runs used the darwin-arm64 build of the same upstream tag, not the .deb that the image installs, so my client and configuration results carry that architecture caveat. CI closes that gap: the multi-arch builds, the image tests on amd64 and arm64, and the compliance audits all pass on this head, and those jobs install and run the actual .deb.

I did not exercise leafnodes, MQTT, WebSocket, clustering or auth callouts, because this repository configures none of them.