A Kafka broker that keeps the log in object storage.

Producers, consumers, and admin clients speak the Kafka wire protocol. The durable log lives in Cloudflare R2, or any S3-compatible bucket. A small set of Rust binaries replicates metadata, and a short write-ahead log, with Raft.

One process

Camus is a single binary. It accepts Kafka TCP, writes record batches as objects, and keeps topics, groups, offsets, and transactions in a Raft group. A deployment does not add a JVM inside the broker, ZooKeeper, KRaft, or a separate database.

The brokers are the same program with different node ids. They agree on metadata through Raft. In the default durability mode they also replicate a short write-ahead log, so a produce can be acknowledged after a disk quorum. The object upload still happens. The write-ahead log is a buffer of seconds, then it is truncated.

What you point a client at

The bootstrap server. Compatibility is pinned to Apache Kafka 4.4.0, commit 1156b2752aaa28eafc0b4c4d387e63356793268d. Where a KIP and that tree disagree, the tree wins. The matrix of implemented APIs, and which client has actually passed each one, is in the compatibility doc.

Three clients have been run against the broker: kafka-clients 4.4.0, librdkafka through confluent-kafka 2.16.1, and franz-go v1.22.0. They produce, fetch, join groups, run transactions, compact a log, and call the admin APIs their libraries expose. A column in the compatibility doc stays unmarked until that client has really passed the call.

Where to go next

• Run one broker with Docker, or from a checkout.
• Give it a bucket before you care about the sealed log.
• Clients lists what those libraries can do, and the differences that will surprise you.
• Durability is the choice between acknowledging on a disk quorum and acknowledging only after the object is stored.