Overrides without editing the file
Every value you might want to change is a variable with its default in the compose file, so nothing needs a.env:
/mcp also offers the tools
that validate, deploy and reset stream designs, so an agent can work the builder here the
way a person does (the stream tools). Nothing
here is shared, and docker compose down undoes everything.
The playground binds the UI to
127.0.0.1 only and runs without login — it
serves your machine and nothing else. There are no volumes:
docker compose down is the reset button; up -d reseeds fresh.What’s inside
Kafka Connect and ksqlDB are not part of the playground — their menu areas hide
when unconfigured, which is the honest state.
Bring your schemas and your data
The seeded topics prove the workbench; your own schemas and a sample of your records prove a design. Two folders beside the compose file, created empty on the firstup, are registered and
produced at every docker compose up, so they survive the reset:
One record per line, as the JSON the schema describes;
key|{...} for a keyed record with a
String key, {...} for a null key. Topics are created with three partitions when missing.
A schema that references another subject needs the referenced one registered first; files
register in name order.
For a topic called shipments with JSON Schema values, that is two files:
schemas/examples/ and
records/examples/ as templates; subfolders are skipped, so copy a pair up one level to try it.
A third template, records/examples/shipments-cdc.json.jsonl, is four real Debezium change
events (an insert, a second insert, an update and a delete) as plain JSON with no schema to copy:
it shows the envelope a connector writes without running a database or a connector.
Names the playground already seeds collide with the seed: a different schema under
orders-value is refused as incompatible, and records for orders, payments, customers or
text-lines land on top of the seeded ones. Your real names only collide if they are literally
these.
To copy a subject from your registry, save the schema field of
GET /subjects/<subject>/versions/latest as the file. To take a sample of a topic, consume it
with the registry-aware console consumer of the same format, which prints one JSON record per
line. Or register the schema and generate a sample from it on the Produce form: the right shape
with no personal data, at the cost of realistic values.
Keep a sample here, not a mirror. A small sample proves a design’s logic if it is the right
one: the ordinary record, and the ones that break things, a null where a field is optional, an
empty list, a value on the boundary of your predicate. Production may not be able to give you
those; here each is one more line in the file. Volume, partitioning under load and restore
time are a matter for a real cluster. Anything personal in the sampled records is yours to
redact before it lands in the folder.
From the playground to your cluster
The playground is the product — the same image, just pointed at a bundled broker. A stream you design here travels to the real cluster as the JSON file you download from the builder and upload on the Alginte that runs against your cluster; the walkthrough, and what changes at the border, is From the playground to your cluster. Running Alginte against your own Kafka is the Quick Start.From the blog
- A Kafka Streams topology starts in a sandbox, not on your cluster: why a design is worth proving on a stack of your own that you are free to break, against a sample of your records, before it goes near the cluster.
- Debezium change events in Kafka Streams: flatten, route, and survive the delete: the change-event envelope, worked through with the Debezium template above, and the expressions that flatten it, route it by operation, and keep a delete from failing the stream.