Connecting to a Kafka Cluster

Connect Kafma with your cluster's bootstrap servers and authentication, then optionally add a Schema Registry. Connection settings stay on your device and are used only to reach the endpoints you configure.

Configure a connection

Open New Cluster from Welcome or the Clusters page. Complete General, then add the optional Schema Registry and Advanced settings if needed.

Bootstrap servers

Enter one or more brokers as host:port. You can paste a comma-, semicolon-, or whitespace-separated list; Kafma removes duplicates and highlights invalid entries. One reachable broker is enough, but adding several improves bootstrap availability. Use brackets for IPv6, such as [::1]:9092.

Environment and read-only

Choose an environment to identify the cluster throughout Kafma. Selecting Production enables Read-Only automatically; turn it off only when you intend to write. Read-Only blocks Kafka and Schema Registry writes made through Kafma.

Credentials

Kafma stores credentials locally through Electron safeStorage; the connection configuration stores references instead of plaintext. Available protection depends on your operating system and desktop environment.

{{env:KAFKA_PASSWORD}}

To avoid storing a secret, enter an environment-variable reference in any secret field. Kafma resolves it when connecting and does not store its value.

Advanced settings

Keep Kafka Version on Auto Detect unless compatibility requires an explicit version. Use Configuration for additional Kafka client properties.

Authentication

Choose the method required by your broker:

SASL

Use TLS is on by default. Turn it off only when the broker requires SASL_PLAINTEXT.

Match the mechanism configured for your credentials; the two SCRAM variants are not interchangeable.

PLAIN and SCRAM use a username and password. OAUTHBEARER accepts either Client Credentials, which Kafma exchanges and refreshes automatically, or a Static Token.

With TLS enabled, leave CA Cert blank to use the system trust store, or provide a PEM certificate for a private CA.

SSL

Use SSL for TLS or mTLS. Broker certificate verification is on by default; leave CA Cert blank to use the system trust store, or provide a private CA. For mTLS, provide a matching Client Key and Client Cert as PEM. Private keys must be unencrypted; Kafma accepts PKCS#8, RSA, and EC PEM keys.

AWS IAM

Set AWS Region to the cluster's region, then choose a credential source:

• Default credential chain — uses the AWS SDK credential chain; optionally specify a profile.
• Manual — enter an access key ID and secret access key, plus a session token for temporary credentials.

Add an Assume role ARN if Kafma should assume a role before signing requests.

Map client.properties settings

If the cluster already works from the CLI, map its client.properties settings to Kafma:

Java .jks files must be converted to PEM before use:

# Client key and certificate, out of the keystore
keytool -importkeystore -srckeystore kafka.client.keystore.jks \
  -destkeystore client.p12 -deststoretype PKCS12
openssl pkcs12 -in client.p12 -nokeys -out client-cert.pem
openssl pkcs12 -in client.p12 -nodes -nocerts -out client-key.pem

# CA certificate, out of the truststore
keytool -exportcert -rfc -alias caroot \
  -keystore kafka.client.truststore.jks -file ca-cert.pem

-nodes produces the unencrypted private key Kafma requires. For a private CA, provide CA Cert instead of disabling certificate verification. Turning off Verify Broker Cert disables both hostname and certificate-chain validation.

Confluent Cloud and AWS MSK

Both shortcuts open New Cluster with Production and Read-Only enabled. Review the prefilled settings, and turn off Read-Only only if you intend to write.

Confluent Cloud

The preset selects SASL/PLAIN over TLS and opens Schema Registry with Basic Auth.

1. Bootstrap Servers — copy the Kafka endpoint from Confluent Cloud.
2. Username and Password — enter the cluster API key and secret.
3. Schema Registry — optionally enter its URL and its own API key and secret.

Kafka and Schema Registry use separate credentials; a cluster API key cannot authenticate with Schema Registry.

AWS MSK

The preset selects AWS IAM with the default credential chain.

Copy the IAM bootstrap servers from View client information in the MSK console, then set AWS Region to the cluster's region. Use the IAM endpoint, not the TLS-only endpoint.

Keep the default credential chain if the AWS CLI or SSO already works on this machine; otherwise enter credentials manually. The AWS identity needs MSK data-plane permissions for the clusters, topics, and consumer groups you use, plus write access if you intend to produce.

Schema Registry

Add an optional Schema Registry to browse subjects and decode or validate schema-based messages. Its settings are stored with the cluster connection.

Standard supports registries that implement the Confluent API, including Confluent, Redpanda, and Apicurio. AWS Glue is currently marked Coming soon.

Use the registry root URL for Confluent and Redpanda. For Apicurio, include the Confluent-compatible API path exposed by your version, for example:

https://apicurio.example.com/apis/ccompat/v7

Authentication supports None, Basic Auth, Bearer Token, and SSL. SSL requires an https:// URL and accepts a CA certificate plus an optional client key and certificate.

Use the card's Test button to verify Schema Registry separately from Kafka.

When a connection first becomes Production and writable without a registry, Save offers Configure SR or Save without SR. Without a registry, Kafma cannot validate produced messages against a schema before sending them.

After connecting, see Subjects and versions.

Test, then save

Use Test Connection to validate the form and reach the cluster. It becomes available when all required fields are valid, and a successful test shows the number of reachable brokers.

Testing is optional. Save stores the connection and opens its Console, where Kafma connects to the cluster.

Troubleshooting

Start with the error shown by Test Connection:

When every bootstrap server is unreachable, Kafma tests each one and summarizes the result.

Manage connections

Select the current cluster at the top of the sidebar to open Clusters. From there, use a connection's menu to Edit, Pin to top, or Delete. A cluster must be disconnected before you can edit it.

Existing secrets remain unchanged unless you replace them. Configuration changes appear in Activity Logs with secret values redacted. Deleting a connection also removes its stored secrets.

Kafma Free supports one active cluster. If Pro access ends, the most recently selected cluster remains available while the others stay saved and locked. See Licensing and activation.

Next steps

• Use the Console
• Browse Schema Registry subjects
• Review licensing and activation