Kafka Producer Config Generator
A producer .properties file, with the four
durability settings set together rather than offered separately. No password
field: credentials are referenced from a mounted secret.
producer.properties
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Putting the password in the generated file
This generator deliberately has no password field, because a credential in a config file leaks into version control, process listings and logs.
Instead:Reference a config provider, or supply the credential at runtime.
Using acks=1 for anything that matters
The leader acknowledges before replicating, so a leader failure right after the ack loses the write with no error.
Instead:acks=all with min.insync.replicas=2 on RF 3.
Setting retries high with in-flight requests unbounded
A retried batch can land after a later one, silently reordering records within a partition.
Instead:Enable idempotence, which handles it, or set max.in.flight.requests.per.connection=1.
The four settings that are one decision
A producer config is mostly durability, and durability is not four independent switches even though it looks like four settings.
acks, idempotence, retries and in-flight move together
acks=all without idempotence still duplicates on a retry. Idempotence requires acks=all, a retry count above zero and at most five requests in flight, and the client refuses to start if any of those disagree. Exposing them as four fields is how incoherent configs get generated, so this form asks what matters instead and sets all four. Kafka 3.0 turned idempotence on by default, which changed acks from 1 to all at the same time, so the same file behaves differently on a 2.x client.
delivery.timeout.ms is the real bound on retrying
retries defaults to Integer.MAX_VALUE, so it is not what stops a batch retrying: delivery.timeout.ms is. It caps the total time from send() to success or final failure, and when it expires the retries stop regardless of the count. Raising retries without raising this changes nothing at all, which is one of the most common wasted changes in a Kafka config.
There is no password field, and that is the point
The generated config references a mounted secret through Kafka's own FileConfigProvider rather than containing a credential, and the commands to create that file come with it. A .properties file holding a password is as sensitive as the password, and it ends up in an image layer, a ConfigMap, a Helm values file and a git history, each of which is a copy nobody is tracking. The trap that comes with the reference is checked too: without config.providers set, the reference is not resolved and no error is raised, so the literal ${file:...} string is used as the password.
This page checks its own output
Every change runs the generated file back through the producer config linter on this site, and the result is reported under the output. That is not decoration: it caught two real bugs in this generator during development. The first version emitted no key.serializer or value.serializer, which are required and have no default, so the config would not have started. Choose the throughput-first durability option and the linter reports the silent-loss finding on this page, immediately.
What this cannot see
It does not know your broker version, your topic's min.insync.replicas, or whether your cluster has enough replicas for acks=all to mean what you want. acks=all is only as strong as min.insync.replicas: with that at 1, acks=all waits for one replica and a single disk failure still loses data. It also cannot verify that the secret file exists or that the credentials in it work. For the upgrade question, the config upgrade checker on this site reads the same file against two versions.