#v0.6.1

Released: August 8, 2026

Redis improvements across rate limiting, messaging, and the Redis instances the framework provisions. No API changes.

#Email rate limiting uses hashed keys

The email rate limit guard hashes the address before using it as a counter key. Limits match regardless of casing or extra whitespace.

#Rate limit counters always expire

Both rate limit guards write a counter and its expiry in a single operation, so every counter carries an expiry.

#Dead letter queues are size bounded

Dead letter queues use the same maxLen bound as the topic they belong to, so they stay within a predictable size.

#Running several instances of a consumer service is safe

A service that consumes topics can run any number of instances. Each instance works independently, and a slow handler keeps its message until it finishes.

Nothing to configure, and no coordination needed when you upgrade.

#Large messages log a warning

Publishing a message over 256 KB logs a warning with the topic and size. Publishing still succeeds. A future release will reject messages this large, so the warning is there to help you find them first.

Raise the threshold if large messages are expected:

MessagingModule.forRoot({
  consumerGroup: "my-service",
  maxPayloadBytes: 1_048_576,
});

Sending a reference instead, such as an object storage key for subscribers to fetch, is usually the better option.

#Memorystore uses the noeviction policy

Generated GCP infrastructure sets maxmemory-policy to noeviction on the Memorystore instance. Job queues need this: an eviction policy that drops keys under memory pressure can discard queued jobs.

Regenerate and deploy to pick it up:

npx tsdevstack infra:generate --env dev
npx tsdevstack infra:deploy --env dev

Review the plan before deploying to an environment with a Redis instance already running.

#Local Redis has a memory limit

The generated Docker Compose file gives the local Redis a 512 MB limit and the same noeviction policy as the managed instances, so local development behaves the way deployed environments do. It applies the next time your Compose file is generated.

#Action

npm install @tsdevstack/nest-common@^0.6.1
npm install -D @tsdevstack/cli@^0.6.1

Existing ^0.6.0 ranges already resolve to 0.6.1. New projects get both from the templates.

After updating the CLI, regenerate and deploy your infrastructure to apply the Memorystore setting.