NATS Config Store

@purista/nats-config-store uses NATS JetStream Key-Value as the config backend. If your services already communicate over NATS, this is the simplest choice — a single infrastructure dependency covers messaging, config, and state.

JetStream required. NATS must be started with JetStream enabled (nats-server -js). Plain NATS (non-JetStream) is not sufficient.

Capabilities

FeatureSupport
Read (getConfig)
Write (setConfig)✅ (opt-in)
Delete (removeConfig)✅ (opt-in)
Persistence across restarts✅ (JetStream)
Watch / real-time propagation✅ (JetStream KV watchers)
Clustering✅ (NATS clustering)

Install

npm install @purista/nats-config-store

Setup

import { NatsConfigStore } from '@purista/nats-config-store'

const configStore = new NatsConfigStore({
  servers: process.env.NATS_URL ?? 'nats://localhost:4222',
  // JetStream KV bucket name (created automatically if it does not exist):
  // bucketName: 'purista-config',
  enableSet: true,
  enableRemove: true,
})

const myService = await myV1Service.getInstance(eventBridge, { configStore })

All NATS JavaScript client connection options are supported — TLS, authentication, cluster seed URLs, and more.

Usage inside a handler

.setCommandFunction(async function (context, payload) {
  const { apiBaseUrl, retryLimit } = await context.configs.getConfig('apiBaseUrl', 'retryLimit')

  await context.configs.setConfig('featureFlags', { newCheckout: true })

  await context.configs.removeConfig('deprecatedKey')
})

Operational tips

  • Use separate KV buckets per environment (purista-config-prod, purista-config-staging) for clean separation
  • JetStream KV supports history — use maxHistory to retain previous values for audit purposes
  • Enable JetStream replication (replicas: 3) in production for HA
  • NATS JetStream watchers allow real-time config propagation to running services — useful for feature flags without restarts