Skip to content
Edka infrastructure automation platform Edka infrastructure automation platform Edka
SYS.DOCS // DOCS

Messaging

Messaging gives each cluster an in-cluster NATS + JetStream runtime that you enable once and then use to model application accounts, durable streams, and consumers. It runs in-cluster, exposes managed client credentials per account, and surfaces live runtime health and JetStream throughput.

Open the Messaging workspace

Section titled “Open the Messaging workspace”

Open a cluster, then go to Cluster Services → Messaging.

The workspace is organized into top-level tabs. Most tabs require the NATS runtime to be enabled first.

TabPurpose
OverviewOnboarding steps, runtime status with provisioning progress, connection details, and a usage summary.
AccountsMulti-tenant application accounts, each with its own client credentials and isolation boundary.
StreamsDurable JetStream streams: subjects, retention, and storage policy.
ConsumersPer-worker consumers: delivery mode, ack policy, and replay behavior on a stream.
SettingsEnable, manage, or disable the shared NATS runtime (replicas, storage, WebSocket, bootstrap credential).
InsightsLive runtime health and JetStream throughput metrics, backed by VictoriaMetrics.
LogsRuntime pod logs for the shared messaging plane.

Onboarding flow

Section titled “Onboarding flow”

Messaging follows a three-step path, shown as a step rail on Overview until each step is done:

  1. NATS runtime — provision NATS + JetStream for this cluster.
  2. First stream — subjects, retention, and storage policy live on streams.
  3. First consumer — delivery mode, ack policy, and replay behavior per worker.

A stream can only be created once the runtime is ready, and a consumer can only be created once at least one stream is ready.

1. Enable the NATS runtime

Section titled “1. Enable the NATS runtime”

The runtime is a per-cluster shared NATS + JetStream plane. You enable it once from Settings (or from the Enable NATS action on Overview).

  1. Open Cluster Services → Messaging → Settings.
  2. Set the Configuration:
    • Storage class — persistent volume class for JetStream state. Immutable after provisioning.
    • JetStream storage (Gi) — requested durable storage for stream data.
    • Replica count — 1, 3, or 5. Use 3 or 5 for quorum-based availability, or 1 for a lighter single-node setup.
  3. Under Bootstrap Application Credential, set or generate the Client password for the implicit default application account and client credential.
  4. Under Browser Connectivity, optionally enable the WebSocket listener for browser and edge clients. Leave it off for server-only workloads.
  5. Submit Enable NATS.

Provisioning runs asynchronously. The runtime status moves through in-progress states (pending, waiting_for_prerequisites, provisioning, updating, deleting) and settles on ready or failed. While it runs, a lifecycle card shows the phase, a progress bar, and the percent complete; a failed reconcile exposes the last error and a Retry reconcile action.

After provisioning, the storage class is immutable. JetStream storage, replica count, and WebSocket support stay editable from Settings.

2. Create the first stream

Section titled “2. Create the first stream”
  1. Open Streams and create a stream.
  2. Under Identity, choose the owning Account, set a Stream name, and list comma-separated Subjects (wildcards * and > are allowed; the form previews and validates them). Optionally link an app and add a description.
  3. Under Retention And Storage, choose:
    • Retention — limits, interest, or workqueue.
    • Storage — file or memory.
    • Replicas — cluster default, or 1/3/5.
    • Optional limits: Max age (hours), Max messages, Max bytes (MB), and Discard policy (old or new).
  4. Expand Advanced options for max message size, duplicate (dedupe) window, compression (none/s2), allow direct get, deny message delete, and deny purge.

3. Create the first consumer

Section titled “3. Create the first consumer”
  1. Open Consumers and create a consumer.
  2. Under Target, pick a ready Stream, set a durable Consumer name, optionally link an app, and use Filter subjects to restrict which stream subjects this consumer receives (leave empty to receive all).
  3. Under Delivery And Replay, set:
    • Ack policy — explicit, all, or none.
    • Ack wait (seconds), Max deliver, and optional Max ack pending.
    • Deliver policy — where in the stream the consumer starts (all, new, last, last_per_subject, by_start_sequence, by_start_time).
    • Replay policy — instant or original.
  4. Choose the Delivery mode, pull or push. Push consumers add a Deliver subject; pull consumers expose Max waiting, Max batch, and Max expires in Advanced options alongside backoff, idle cleanup, and headers-only delivery.

Accounts

Section titled “Accounts”

Application accounts are the multi tenant boundary inside the runtime. Each account has its own client credentials and isolation boundary, and streams and consumers are scoped to the account that owns them. NATS seeds a default application account automatically when the runtime is enabled.

From the Accounts tab you can filter accounts and open one to manage it. Each account form covers:

  • Identity — account name (immutable after creation), display name, and description.
  • Limits — optional Max streams, Max consumers, and Max storage (Gi) ceilings.
  • Default Client Credential — the managed client username and credential status, plus a Rotate client password field.

Connection details

Section titled “Connection details”

When the runtime is ready, a Connection card appears on Overview and on the selected account. Pick an Application account to see its managed Client credential, then use the tabs:

  • Parameters — host, port, username, password, and the WebSocket URL when enabled.
  • Client URL — a full nats:// connection string with credentials.
  • Examples — ready-to-copy NATS CLI, Node.js, and (when WebSocket is on) browser snippets.

Connect from workloads running inside the cluster using a managed client credential. Passwords and credentialed URLs are masked until you reveal them.

Insights

Section titled “Insights”

The Insights tab shows live runtime health and JetStream throughput once the runtime is ready and VictoriaMetrics has scraped the exporter. Cluster metrics include CPU, memory, total and max connections, connection usage, subscriptions, ingress/egress message rate and bandwidth, streams/consumers, stored messages and bytes, JetStream storage usage, slow consumers, and JetStream API request and error rates. An All instances section breaks the same metrics down per pod. A compact CPU, memory, connections, ingress/egress, slow consumers, and pod count summary also appears on Overview.

Logs

Section titled “Logs”

The Logs tab streams runtime pod logs for the shared messaging plane. Select the Tail lines, Container, and Pod, toggle Previous to read logs from a restarted container, and follow live output. You can refresh, copy, or download the current log buffer.

Access and safety

Section titled “Access and safety”
  • Viewing the messaging plane requires cluster read access.
  • Enabling, updating, disabling the runtime, and creating, editing, or deleting accounts, streams, and consumers require cluster write access.
  • Archived clusters block all mutating messaging actions.
  • Disabling NATS tears down every account, stream, consumer, and managed credential on the cluster, and cannot be undone — the action requires a typed confirmation.
  • Client passwords and credentialed connection URLs are masked in the UI until revealed, and credentials are copied as sensitive values.
Section titled “Related docs”