Skip to main content
Available from Alginte 0.12.0. The Docker image stays the recommended channel; the JAR is for machines where a container is not an option. The multi-instance semantics below apply to Docker deployments too.
Alginte also ships as a single fat JAR — the backend and the web UI in one file. It requires a Java 25 runtime.

​
Download

Every release publishes the JAR on the community repo’s GitHub Releases, with a SHA-256 beside it. The latest release is always at the same URL:
macOS ships shasum rather than sha256sum; the check there is shasum -a 256 -c alginte.jar.sha256, and the file’s *alginte.jar marker is understood by both. To pin a version, use its tag instead of latest, for example https://github.com/alginte/community/releases/download/v0.12.0/alginte.jar. The release there marks the binary, not a source state: the community repo holds the playground and the policies, and the release notes live on alginte.com.

​
Run

Then open http://localhost:8888. The JAR checks for a newer release the same way the image does, once a day at most, as an anonymous fetch of a small manifest; set alginte.update-check.url to empty to switch that off (configuration).

​
The bind-address boundary

By default server.address=localhost, so a plain java -jar serves only the local machine. Overriding the bind address is the moment you take ownership of the security boundary — anyone who can reach the port has full control of every connected Kafka cluster unless you enable the login.
To serve a trusted network, override the bind and put a reverse proxy (TLS termination, network allow-listing) in front:
Or via the environment:

​
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 (same application.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 via application.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.