> For the complete documentation index, see [llms.txt](https://docs.appmixer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.appmixer.com/changelog/version-6/6/6.4/6.4.9.md).

# 6.4.9

2026-08-14

## Features

* **Configurable MongoDB connection pool with idle-connection reaping** — `DB_POOL_SIZE` once again sets only the **maximum** pool size, restoring the semantics that were in place before the MongoDB 7 driver migration (which had mapped the single value to both the minimum and the maximum, permanently pinning every Mongo-connecting process to exactly 5 open connections while also capping it at 5 concurrent operations). Three new options replace it:

  * `DB_MAX_POOL_SIZE` — maximum pooled connections. No default; takes precedence over `DB_POOL_SIZE` when set.
  * `DB_MIN_POOL_SIZE` — minimum warm connections, default `1`.
  * `DB_MAX_IDLE_TIME_MS` — default `120000`; pooled connections above the minimum that sit idle for longer than this are closed. The driver default of `0` (never close) is why pools never shrank before.

  `DB_POOL_SIZE` is deprecated but still honoured as a backward-compatible alias, with its default raised from `5` to `10`. With all defaults, a process now keeps 1 warm connection, can burst to 10, and shrinks back within roughly 2 minutes. Set `DB_MIN_POOL_SIZE` higher for deployments where reconnect latency matters. This matters most in multitenant deployments against a shared DocumentDB, where the pinned pool wasted a large number of permanently idle connections.
* **`node_modules` is now reinstalled only on a Node.js major version change** — The reinstall exists for native addons, whose ABI changes only across major Node.js releases, but the previous check compared the full version string. Every patch or minor image bump therefore triggered a cluster-wide `npm install` plus a GridFS re-upload of every plugin's and component's `node_modules`, and mixed-version clusters during a rolling deploy could ping-pong reinstalls. Only the major version segment is compared now; stored metadata keeps the full version, so no migration is needed.
* **Node.js upgraded to 24.19.0** — Base images across the engine, auth-hub, quota, frontend and Backoffice move from 24.6.0 to 24.19.0, and `engines.node` is raised to `>=24.19.0`. Beyond being the latest 24.x LTS, this fixes outbound TLS failures (`UNABLE_TO_GET_ISSUER_CERT_LOCALLY`) to endpoints whose certificate chains to Let's Encrypt's ISRG Root YR, which is absent from 24.6.0's compiled-in root CA store.

## Bug Fixes

* **Fixed slow webhook retry lookups under load** — The `{ url: 1 }` index on the `webhookRetries` collection could serve the webhook circuit-breaker's half-open probe filter but not its `due` sort, forcing an in-memory sort over every retry recorded for that URL. It is replaced by a compound `{ url: 1, due: 1 }` index, which serves both and — being a prefix superset — still covers every existing `url`-only query. The obsolete index is dropped automatically on startup, so no manual migration is required.
* **API warning alerts are no longer shown to non-admin users** — Neither the **API Version Mismatch** nor the **API Validation Failure** toast is raised for non-admins, who cannot act on a deployment concern. Both still reach the browser console and the SDK's `api.on('warning')` event for every consumer.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.appmixer.com/changelog/version-6/6/6.4/6.4.9.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.