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
| Feature | Support |
|---|---|
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
maxHistoryto 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