> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alginte.com/llms.txt
> Use this file to discover all available pages before exploring further.

# From the playground to your cluster

> Design and prove a Kafka Streams topology in the isolated playground, download it as a file, then upload and deploy it on the Alginte that runs against your cluster. Nothing touches the shared cluster until the last step.

The [playground](/installation/playground) is the product with a bundled broker: the same
image, the same Streams builder, the same deploy gate. That makes it a workbench, not a demo. A
team designs a stream there, proves it against records, and only then puts it on the shared
cluster, through a file. This page walks that path once, end to end, and says what changes at
the border.

<Note>
  Two Alginte instances are involved: the playground's, on `localhost:8888`, and the one you run
  against your cluster ([Quick Start](/installation/quickstart)). Nothing moves between them by
  itself. The design travels as the JSON file you download from one and upload to the other.
</Note>

## 1. Start in the playground

```bash theme={null}
curl -O https://raw.githubusercontent.com/alginte/community/main/playground/docker-compose.yml
docker compose up -d
```

The stack is yours alone: a single-node Kafka, a Schema Registry and Alginte, bound to your
machine, with no volumes. Whatever you deploy here can be thrown away with `docker compose down`.
It comes seeded with topics, real Avro records and a running topology, so the first thing you
see is a canvas with numbers on it ([what is inside](/installation/playground#what’s-inside)).

## 2. Bring your data's shape, not your data

A stream is designed against the shape of its input, and the shape lives in two places: the
topic and the Schema Registry. Recreate both in the playground:

* **The topic**, with the name it will have on the real cluster. Create it on the
  [Topics](/guides/topics) screen; the partition count does not have to match yet.
* **The subject**, when the records are Avro, JSON Schema or Protobuf: register the same schema
  under the same subject name on the [Schema Registry](/guides/schema-registry) screen. The
  builder's completions, the sample preview and the deployed serde all read it from there.
* **A small sample** that looks like the real records, produced from the
  [Messages](/guides/messages) screen against that subject. What it needs is variety, not
  volume: 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. The preview evaluates your
  expressions against one real record at a time.

All three are gone at the next `docker compose down`. To keep them, put the schema and the sample
in the two folders beside the compose file, which are registered and produced at every `up`
([bring your schemas and your data](/installation/playground#bring-your-schemas-and-your-data)).

Keep the names identical to the target's. The design carries topic names and subject names, and
the deploy gate on the target refuses a source topic that does not exist there, by name.

## 3. Design, and prove it as you go

Build the topology on the canvas ([Building a stream](/streams/building)): the source bound to
your topic, the operators, the sink. Every expression you write is evaluated against a record
from the topic while you type, and the shape it produces is carried to the next node, so what
you see at each step is what the deployed operator will do to that record. The gate on Submit
checks the rest, co-partitioning at joins, the serde at every sink, a windowed key that cannot be
written as it is, and names the node and the fix.

Deploy it here. Produce records and watch the sink fill; open the
[State tab](/streams/monitoring#the-state-tab) to see the stores, the threads and the lag. A
stream that runs wrong in the playground is cheap: fix the design and submit again. A stream
that runs right here runs the same Kafka Streams client on the target.

## 4. Download the design

In the wizard header, **Download** writes the whole design to a file: the configuration, every
node with its expressions and serdes, the edges and the canvas layout, stamped with the format
version ([save your work](/streams/building#save-your-work-download-/-upload)). The file is
named after the `application.id`. Put it in your repository: it is the durable artefact, and
the thing a reviewer reads.

What the file does not carry: the records, the topic itself, the subject's schema, and the
stream's state. Those are the cluster's, on both sides of the border.

## 5. Upload on the console that runs against your cluster

On the Alginte instance that is connected to the real cluster, open the Streams builder and
**Upload** the file. The wizard opens with the design loaded and the same validation running.
Before Submit, check three things on Step 1 and the canvas:

1. **`application.id`**: it names the consumer group and prefixes the internal topics on the
   real cluster. If a stream under that id has run there before, Alginte says so before
   deploying and asks whether to continue on its state or start fresh
   ([deploy and operate](/streams/deploy)).
2. **The cluster-bound properties** the file may carry, `bootstrap.servers`, the registry URL,
   the security settings: the upload leaves them out and says which, so the design brings its
   logic and not the cluster it was written on, and this console's own connection applies. Set
   them on Stream Properties only if this stream needs values of its own.
3. **The topics and subjects**, by name, on the real cluster. The gate refuses a missing source
   topic, and a source whose subject is not on this registry, naming the node, so register the
   subject first if the target registry does not have it yet.

Then Submit. The deploy is the same gate and the same client; the difference is the cluster it
joins.

## What is different at the border

* **Rights.** The playground console is a super-user on its own broker. On the real cluster the
  console's principal needs the deploy posture, the rights any Kafka Streams application needs
  ([production](/operate/production#the-security-boundary)).
* **Partitions and parallelism.** The playground's topics have the partition counts you gave
  them, not the real ones, so a join that is co-partitioned here may not be there, and the other
  way round. The gate checks co-partitioning at joins on the target, against the real counts.
* **Volume.** A design proven on a small sample is proven for its logic, not for its throughput.
  Watch the State tab and the per-node numbers on the target for the first hour.
* **Durability.** On the Community edition a deployment is ephemeral on both sides: a restarted
  console comes up with no streams, and the design file is the recovery path
  ([restarts and the edition behaviour](/streams/deploy#restarts-and-the-edition-behaviour)).
  The state on the cluster survives; upload and submit again and processing resumes.