The direct JAR download is not yet available — the Docker
image is the supported channel today; the JAR download
arrives in a future release (it will be announced in the release notes). This
page documents the JAR run mode ahead of that, and its
multi-instance semantics apply to Docker
deployments too.
The bind-address boundary
To serve a trusted network, override the bind and put a reverse proxy (TLS termination, network allow-listing) in front:Running multiple instances
Each Alginte instance is fully self-contained: its deployed streams live in its own memory, so instances are unaware of each other. Run as many as you like against the same cluster — each UI manages exactly what that instance runs, and you coordinate by deploying to each instance yourself. Deploying the same topology (sameapplication.id) on several instances scales it the standard Kafka Streams way: the
instances join one consumer group and split the partitions between them.
Recovery doesn’t need a standby instance. Stream processing state and progress live
on the Kafka cluster itself (changelog topics, committed offsets) — deployments are
ephemeral, so a restarted instance comes up with no deployed
streams: re-import and re-deploy your topologies (export them while designing —
that’s your durable copy) and processing resumes exactly where it left off.
Configuration
Everything configurable viaapplication.properties can be set on the command line
(--property=value) or through environment variables (Spring relaxed binding). See
Configuration for the properties that matter, and mount an
external file with --spring.config.additional-location= if you prefer a file over
flags.