Skippr Docs

Appearance

What Network Access Skippr Needs for Kafka ​

June 2026

Kafka source access depends on reaching the bootstrap brokers and being allowed to consume the topic with the configured consumer group.

Short Answer ​

Skippr needs outbound access to the Kafka bootstrap brokers, permission to read the selected topic, and permission for the configured consumer group to commit offsets. The Kafka docs call out those exact boundaries, along with any security_protocol, sasl_mechanism, sasl_username, and sasl_password settings for secured clusters. The real connectivity test is whether the runner can join the cluster as this consumer and read this topic, not whether some broker hostname answers a ping.

That distinction shows up immediately in managed environments. A runner may be allowed to reach one broker address but not the listener the cluster actually advertises, or it may authenticate to SASL successfully and still fail when it tries to commit offsets for skippr-consumer. If the topic carries Debezium envelopes, there is also a content boundary: the messages need to be the CDC shape you expect, not just any bytes on a reachable topic.

Why Teams Struggle with This ​

Kafka source work is often described as a message-streaming problem, but most early failures are network and ACL failures. The topic name is right, the YAML is right, and the consumer still cannot do anything useful because the access path is incomplete.

  • The runner must reach the bootstrap brokers from the same network where Skippr executes.
  • Topic read access and consumer-group commit access are separate permissions that both matter.
  • SASL settings have to line up across protocol, mechanism, username, and password for secured clusters.
  • For Debezium-style CDC, a reachable topic is not enough if the message envelope is not the shape you expect.

How Skippr Handles It ​

Skippr exposes the Kafka boundary directly instead of abstracting it away. You configure brokers, topic, group_id, auto_offset_reset, and the security fields that actually determine whether the consumer can run, so the first working config looks like a real production consumer rather than a toy demo.

That helps when you need infrastructure help. You can ask for access to a specific broker list, one topic, one consumer group, and the right SASL settings. There is much less ambiguity than in a generic request for Kafka connectivity.

  • Consumes from an explicit topic through explicit bootstrap brokers.
  • Supports stable consumer-group configuration and offset reset policy.
  • Handles secured clusters through the documented SASL and protocol fields.
  • Pairs cleanly with Debezium-style CDC when the topic contract is already established.

What the First Useful Version Looks Like ​

The first useful version is one topic, one consumer group, and one mode choice, usually stream, with earliest or latest chosen on purpose instead of by accident.

If the group cannot join and commit offsets yet, fix that before adding more topics. Kafka problems scale badly when the first boundary is still fuzzy.