Scada-LTS is a web SCADA system you build and run yourself

A supervisory system you host yourself

Scada-LTS is an open source, web-based, multi-platform solution for building your own SCADA, supervisory control and data acquisition, system, with the code released under the GPL.

The scope is the whole application, not a library. It is a web application that a plant or a building operator runs on their own infrastructure, and it covers the things a supervisory system covers, which is why the repository has directories for Modbus, for MQTT and for the web application itself.

The implementation is Java on the server with a Vue.js front end, and the deployment target is Tomcat, which is what the Docker image and the Gradle run tasks both use. The multi-platform claim in the description is about the client side, since a browser based supervisory interface works from a desktop on the plant floor and from a phone in an office.

The default branch is develop, the licence is GPL-2.0, and the last push was on 2026-07-24. The recent releases are v2.8.0 from 2025-10-17, v2.7.8.1 from 2025-03-31 and v2.7.8 from 2024-07-10, and the v2.8.0 tag carries a pre-release suffix, which is worth knowing before you plan an upgrade around it.

The project describes itself as following the semantic versioning guidelines to organise changes, which is a promise that the 2.x line will not break your configuration without a major version.

Two build systems, and one of them is on the way out

To build the application on your own environment you can use Gradle or Apache Ant, and the readme immediately tells you which one to pick.

Ant is now marked as deprecated because it will soon be removed from that project.

So the practical advice is Gradle, and the versions are pinned. You have to use Gradle version 6.8.1 or similar with Java version 11, and it should also work on other versions, but you then have to change the targetVersion in the build.gradle file.

The Gradle task table is the useful part, because it shows the shape of the development loop.

gradle buildRun
gradle test
gradle -PskipUi=true buildRun

The war task builds the Scada-LTS war file, run launches a Tomcat instance, runDebug does the same in debug mode, buildRun builds and starts the application, and test launches the backend unit tests. There is a separate task for the front end unit tests, scadalts-ui::testUi, and the skipUi parameter lets you build and start without rebuilding the user interface.

That last one is the most useful flag in the list, and the readme says why. Using the parameter you can reduce the compilation time, for example if you made no change. The front end is a separate sub-project with its own readme in the scadalts-ui directory, and a build that recompiles it every time is a build you will start avoiding.

The Docker path brings up three services

The compose file in the repository is the fastest way to see what a running installation looks like, and it defines three services.

The database is MySQL, on the mysql/mysql-server:8.0.32 image, with the port published and the data directory mounted.

    database:
        container_name: mysql
        image: mysql/mysql-server:8.0.32
        ports:
            - "3306:3306"

The application service is the scadalts/scadalts:latest image, with the JVM heap set through CATALINA_OPTS to two gigabytes for both the maximum and the initial size, the tomcat_log directory mounted for the logs, and a link to the database.

The startup ordering is done with wait-for-it rather than with a health check, and the command waits for the database on port 3306 with a thirty second timeout in strict mode before running catalina.sh. The service exposes 8080 and 8000, with 8080 published to the host.

The third service is MQTT, the hivemq/hivemq4 image, with 8081 and 1883 published, and 1883 being the MQTT port itself. That is the broker for anything that publishes telemetry into the system, and it is the reason the compose file has three services rather than two.

A development variant, docker-compose-dev.yml, exists alongside, and the comments in the compose file explain the intent: use MySQL 8 and the latest local build, and attach the webapps folder as a developer so you can modify the static content from the host system, and attach a shell to stop the Tomcat instance so you can run it in JPDA mode.

The image is Tomcat with a war and some pinned jars

The Dockerfile shows how the container is assembled, and it is worth reading because it explains what the image does and does not contain.

FROM tomcat:9.0.86-jre11
COPY build/libs/Scada-LTS.war /usr/local/tomcat/webapps/

The base is Tomcat 9 on a Java 11 runtime, and the war built by Gradle is dropped into the webapps directory. Then the war is unzipped into a directory of the same name, because the context.xml is copied into the META-INF directory of the exploded application afterwards, which is the Tomcat way of pointing an application at a JNDI datasource.

The explicit COPY lines for the jars are the interesting part. The MySQL connector at 5.1.49, the activation jar, and the jaxb-api, jaxb-core and jaxb-runtime jars at pinned versions are all copied into the Tomcat lib directory by hand.

Those pins are a compatibility decision. On a Java 11 runtime, the JAXB implementation that shipped with the JDK is gone, and the classes are needed for the XML handling that a Java EE era application does. Pinning them in the image means the container runs the same way on every host, whatever the base image happens to have, and the versions are old enough to be deliberate rather than current.

The image also installs unzip for the exploded war, and wait-for-it for the startup ordering, and the maintainer label names rjajko at softq.pl.

The tree shows what a SCADA system touches

The top level listing is the architecture of the application, and a few directories name the protocols and the subsystems.

There is a modbus/ directory, which is the industrial field protocol, and the presence of a dedicated directory tells you that Modbus is a first class integration rather than an add-on. There is a templates/ directory for the report and chart templates, an xml/ directory, and a jmeter/ directory for load testing, which is what you would expect in a system that has to keep polling a plant.

The Java application is in src/, with the web resources in WebContent/ and webapp-resources/, and the test code in test/ with fixtures in test-resources/. The front end is the scadalts-ui/ sub-project with its own README. The Tomcat configuration is in the tomcat/ directory, and the lib/ directory holds the jars, and doc/ holds the documentation including the REST API specification.

There is a backstop/ directory, which is the visual regression testing tool, and that is a signal about how the project guards its user interface. And there is a sonar-project.properties file, so static analysis is configured, plus a gradle.properties file, settings.gradle, a version.sh script for the version, and a Dockerfile, the compose files and a docker/ directory.

The .github/ directory and the SECURITY.md file are the governance layer, and the readme points at dedicated issue templates for a bug report, a feature, a feature request and a report of a security vulnerability, which is a sensible thing to have in a project whose code runs on a plant network.

REST documentation generated from an OpenAPI 3 spec

The documentation story has three parts, and they are in different places.

The project documentation is the GitHub Wiki, and the readme points at a QuickStart Guide there for running or building the application. There is also a users community, and the readme says you can ask questions on StackOverflow or in the GitHub Discussions.

For developers, the readme says a complete code documentation containing all the REST API interfaces is being prepared, with example usage, and that they use the Open API specification in version 3 because it is compatible with most of the modern API tools like Swagger or Postman. The documentation file is in the Scada-LTS/doc directory, in the RESTAPI sub-directory.

So the plan is to describe the API in a machine readable specification and let the tooling render it. For a supervisory system, that matters more than it would for a typical web application, because the API is how a third party integrator or a historian connects to the system, and a hand written document of endpoints goes stale immediately.

The third part is video. The readme suggests the YouTube tutorials to get acquainted with the application, and points at the releases section for the latest features and the version changelogs, and it links the MicroBadger badges for a version badge and a Docker image badge for the development build.

Support, licensing and a borrowed library

Two details in the readme are worth pulling out, because both bear on how you evaluate the project.

The first is support. If you need support for deployment please contact us and find more information on our website. So deployment support is a commercial arrangement rather than something the open source project provides, which is the normal shape for infrastructure software in this space and is worth pricing into a decision.

The second is the SeroUtils library licence. Matthew Lohbihler has granted the project permission to use the SeroUtils.jar library, and the team can use the code without limitation. There is then a fragment with the correspondence between Grzegorz Bylica and Matthew Lohbihler, quoted in the readme.

That is a rare and welcome thing to find in a GPL project. A jar with a non-GPL licence inside a GPL distribution would normally be a problem, and the answer here is a specific permission from the copyright holder, documented in the readme. It also tells you something about the lineage of the code, since the SeroUtils and Scada-LTS names and the correspondence point at the same origin.

The rest of the readme is the ordinary business of an open source project. Bugs and feature ideas go to the issue tracker, with the issue guidelines linked, and a request to write in English and explain the problem clearly, and a reminder to check that the issue has not already been reported.

Editorial conclusion

Adopt Scada-LTS when you need a supervisory system you host and can modify, and you have the Java and Tomcat or Docker infrastructure to run it. Do not adopt it if you need a product with a support contract on the critical path of a plant, because the readme asks you to contact the project for deployment support rather than providing it. Verify first which version you install, since the 2.8 line is a pre-release and the 2.7 line is what most installations will be on, that the build toolchain matches the documented Gradle 6.8.1 and Java 11, and whether you need the MQTT and Modbus pieces at all, since they are separate parts of the tree.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. SCADA-LTS/Scada-LTS on GitHub