Skip to main content
Submit deploys the topology into your Alginte instance and starts it immediately. On the Community edition the confirmation says so explicitly:
Stream ‘your-app-id’ started (ephemeral — Community deployments do not survive a restart).

​
The Streams page

Streams lists every deployed stream with its state. Click one to open its detail page — the URL is stable and shareable, keyed by the application.id (e.g. /streamDetails/wordCount).

​
The detail page

Five tabs:
  • Info — configuration and state, plus the lifecycle actions.
  • Stream Flow — the topology as you designed it, on a read-only canvas.
  • Topology - Ascii / Topology - Mermaid — the built Kafka Streams topology (the Topology#describe() view), as text or a diagram: useful to see the processor graph, internal topics, and state stores the runtime actually created.
  • Metrics — runtime metrics for the stream.

​
Lifecycle actions

On the Info tab:
Deleting a deployment removes it from Alginte only. Nothing on the Kafka cluster is deleted — source and sink topics, changelog topics, and committed offsets all remain, so redeploying the same design under the same application.id resumes where processing left off.

​
Restarts and the edition behaviour

Where deployments live differs by edition:
  • Community — deployments are ephemeral: a restarted Alginte instance comes up with no deployed streams. Your recovery path is the design JSON — Download it while building, then Upload and Submit again after a restart. Processing continues from the cluster-side committed offsets and state; nothing is lost but the redeploy click.
  • Professional (not yet available — join the release list) — deployments are durable: persisted next to your cluster and automatically restored, in their last state, when the instance starts.

​
Scaling out

Deploying the same design (same application.id) on several self-contained Alginte instances scales it the standard Kafka Streams way — the instances join one consumer group and split the partitions. Each instance manages its own deployment; see Running multiple instances.