Kafka

desktop only The browser sandbox doesn’t allow raw TCP connections, so Kafka — which requires a long-lived TCP session — is available only in the desktop app.

What works

• Produce — pick a topic, set text headers, target an optional partition, and send a key + value as UTF-8 text, validated JSON, or Base64-encoded arbitrary bytes. Base64 is decoded only at the Electron boundary, so invalid UTF-8 bytes are preserved exactly.
• Consume — subscribe to a topic, see messages live with partition / offset / timestamp. Start from latest, earliest, a specific offset, or a timestamp (seeks each partition to its first message at or after the chosen time).
• Topic inspector — per-partition earliest/latest watermarks (and the approximate message count) plus the topic’s broker config.
• Consumer-group inspector — members and state, committed offset per partition, and consumer lag (topic log-end minus the group’s committed offset) — computed on demand for any group, no active subscription needed.
• Reset consumer-group offsets — to earliest, latest, or specific per-partition offsets (the group must be inactive).
• Delete consumer group — for empty/inactive groups.
• Multiple brokers — bootstrap list, broker discovery happens through the cluster.
• SASL — PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 over SASL_PLAINTEXT or SASL_SSL.
• TLS — pick SSL for TLS without SASL (encryption plus optional client-certificate mTLS), or layer it under SASL_SSL; server certificate validation either way.
• Compression — gzip / snappy / lz4 / zstd negotiated automatically.
• Confluent Schema Registry — point a connection at a registry URL (optional Basic auth); produce schema-encoded keys and values by schema ID, and consume with automatic Avro / Protobuf / JSON decode of both. Powered by @kafkajs/confluent-schema-registry.

Broker guard

Every broker address (and Schema Registry URL) runs through a pre-flight SSRF check (electron/main/security/kafka-broker-guard.ts) before the connection opens. Like MQTT — and unlike the HTTP guard — private and loopback addresses are allowed, because Kafka brokers and registries routinely live on LAN / VPC networks. The guard rejects only cloud-metadata endpoints (169.254.169.254 and friends, metadata.google.internal, …) and malformed addresses, so a malicious or misconfigured bootstrap.servers can’t aim traffic at your machine’s metadata endpoint. It’s pre-flight only — it doesn’t mitigate a true DNS-rebind during connect (the residual gap in ADR 0006).

Tips

• Set the client ID (defaults to restura) to make your activity easy to spot in broker logs.
• For schema-encoded payloads, set the connection’s Schema Registry URL, then pick a value and/or key schema ID when producing — the field is parsed as JSON, Confluent-encoded, and decoded again automatically on consume. Schema encoding and raw Base64 are intentionally mutually exclusive for the same field.
• Use JSON mode to validate a JSON document before publishing its UTF-8 text. Use Base64 bytes for arbitrary binary payloads; Restura accepts canonical Base64 only and displays consumed non-UTF-8 fields as Base64 so they can be copied without byte loss.

Related

• Self-hosting — Kafka stays desktop-only even when self-hosting the SPA; the consume/produce path needs Node.
• Capability matrix
• Local test stack — run a real Kafka broker (Redpanda) locally to test against instead of a mock.