> ## 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.

# Deploy & lifecycle

> What happens after Submit: stream states, the detail page, pausing and stopping, restarts, and edition behaviour.

**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:

| Action                 | What it does                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------- |
| **Pause** / **Resume** | Suspends processing without tearing the stream down; resume picks up where it paused. |
| **Stop** / **Start**   | Stops the Kafka Streams client entirely; start builds and runs it again.              |
| **Delete**             | Undeploys the stream and removes it from the list.                                    |

<Note>
  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.
</Note>

## Restarts and the edition behaviour

Where deployments live differs by [edition](/editions/licensing):

* **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](https://www.alginte.com/#notify))* — 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](/installation/jar#running-multiple-instances).