Updates

A server learns about a newer release by itself, once a day. Installing it is always a person’s decision: on a single server through Settings → Server Settings → Server update, on a cluster by hand.

	Single server, started through the update launcher	Single server, started as `inscada.jar`	Cluster
How	The Server update card	By hand once, then move it to the update button	By hand, in the cluster order

How a newer release is announced

The daily check

Once a day (the first time a minute after start) the server asks the public release feed, inscada-releases, whether a newer release than the one running exists. The check itself downloads and installs nothing, and its request says nothing about the version the server runs.

A newer release appears in the sidebar, under the version, as Update available: …, with a link to its release page. Only the installation administrator sees it; nobody else does. The same notice says whether your licence’s maintenance covers the release. A server without internet logs once that the feed cannot be reached and carries on.

Switching it off

The check is on by default. A site that must not reach the internet (air-gapped, OT networks) switches it off, and then no request is made at all. Any one of these does it:

Settings → Server Settings → General → Update check off, and a restart. This is the way on the Windows installer’s service.
INS_UPDATE_ENABLED=false in the service’s environment, or -Dins.update.enabled=false on its command line. Either outranks the page, which then shows the switch as locked.

With the check off, the update card cannot offer a download either; copy the release in by hand (below).

A mirror, a proxy

A mirror. The feed’s address is not on the page. INS_UPDATE_URL in the service’s environment, or ins.update.url in config/application.yml, can point at an internal mirror that answers the same JSON as the feed. The card’s download fetches the release’s files from the same feed, so a mirror that is to offer the download serves app-<rev>.jar and app-<rev>.jar.sig over https, with each file’s size and the jar’s digest, as GitHub does; without them the release is shown but not offered for download.
An HTTP proxy. The check and the download go through a proxy only when the JVM is told to: add -Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port> to the service’s command line (and -Dhttp.nonProxyHosts=<hosts> for addresses that must not go through it). A proxy that asks for a user name and password is not supported; switch the check off there, or use a mirror inside the network. These are JVM options, so Settings → Server Settings cannot set them.

Official releases and nightlies

	Official release	Nightly
Name on the feed	`inSCADA 20261108-11`	`inSCADA nightly … (not for production)`, a pre-release
Files	`app-<rev>.jar`, `app-<rev>.jar.sig`, `inscada-launcher-<rev>.zip`	the jar only
Signed	Yes, from 20261108-11 on	No
Through the update button	Yes	Never: the launcher refuses a jar without a signature, and the card does not offer a pre-release for download

The update launcher applies a jar only when it verifies the release’s signature. A nightly is installed by hand, if at all.

Updating with the button

Settings → Server Settings → Server update updates a single server that starts through the update launcher. Opening the card needs VIEW_SERVER_SETTINGS; downloading, updating and cancelling need UPDATE_SERVER_SETTINGS. Someone without the second permission sees the version, the checks and the progress, but not the buttons.

Where the server cannot update itself, the card says why instead — for example “This server cannot update itself from this page.” It is offered only when all three hold: the product was started by the update launcher, the service manager is proven to start it again (the same check as Restart now), and the server is not a cluster node.

1. Put the release in the update folder

The release has to be in the installation’s update\pending folder (C:\Program Files\inSCADA\update\pending on Windows, /opt/inscada/update/pending on Linux). There are two ways:

Download it. In the releases after 20261108-11, when the daily check has found a newer release and update\pending is empty, the card shows Newer release (version and size) and Download <version>. The download asks for a reason (and, where required, your signature), shows its progress and can be stopped with Cancel the download. It installs nothing: the files arrive in update\pending, and the update is started afterwards from the same card. A download that fails or is cancelled leaves nothing behind: “The download stopped; nothing was placed in the update folder.”
Copy it. From the release page, copy app-<rev>.jar and app-<rev>.jar.sig into update\pending. This is the way on a site without internet. A jar copied without its .sig is refused because it has no signature file beside it; copying the .sig in afterwards is enough.

Only one jar may be in update\pending.

2. Read the checks

The card judges every precondition before anything changes, each with the numbers it judged on. A check that cannot be judged because an earlier one did not hold shows Not checked.

Check	Holds when
Started through the update launcher	The service starts `inscada-launcher.jar`
The service manager starts it again	The service manager (NSSM, systemd) is proven to start the service again after it exits
Not a cluster node	The server is not part of a cluster
One release waiting in the update folder	Exactly one jar in `update\pending`, with a version
The update launcher accepts the release	The launcher’s own verdict: signed by a trusted key, an inSCADA jar, newer than the version running
Maintenance covers the release	The release was built on or before your licence’s maintenance end
No saved setting waiting for a restart	Nothing saved on Settings → Server Settings is still pending
Room for the backup	Free space under `update\backups` ≥ twice the database, twice the larger jar and 1 GB
PostgreSQL backup tools	A `pg_dump` at least the server’s PostgreSQL version is found (the installation’s own `pgsql\bin` first)
No other update under way	No update or download is in progress, and the last update has reported ready

Update launcher’s verdict shows the launcher’s answer in full: Accepted or Refused with its reason, the running version and who signed the release. “The update can start once every check has passed.”

3. Update and restart

Update and restart asks for a reason — the audit trail records it with who asked for the update — and, where the installation requires it, your signature. An installation that wants every update (and every download) signed adds APPLICATION_UPDATE to Operations that require a signature on Settings → Server Settings.

What happens then:

A database backup is taken while SCADA keeps running. The card shows Opening a snapshot of the database for the backup, Taking the database backup (with how much is written), Reading the backup back to check it. Until here Cancel the update stops it and nothing is changed.
The server restarts. “The server is restarting to install …” The update launcher checks the release again and puts it in place of inscada.jar before the product opens; the previous jar goes to update\kept, the backup stays in update\backups.
The new version starts and reports ready. The page reconnects and says “The new version is running. The previous jar and the database backup … are kept on the server.”

The change is recorded: the audit trail has the request (with the reason and any signature) and the outcome, and the event log has the line “This installation was updated from X to Y.”

How long SCADA is down

During the backup, nothing stops: SCADA, device communication and users carry on. SCADA is down from the restart until the new version is up: one service start, plus the new release’s database migrations, which on a large historian can take minutes. The card waits 15 minutes before it says the server has not answered — and that alone is not a failure. Plan the update for a time when a short stop is acceptable.

If it fails

What the card says	What happened	What to do
“The update stopped; nothing was changed.”	The backup failed or was cancelled; SCADA never stopped	Read the reason, correct it (disk, `pg_dump`), try again
“The update launcher refused the update on …, and the previous version kept running.”	At the restart the launcher would not apply the release	The previous version runs; read the reason. A jar refused for what it is (signature, version) is not taken again
”… did not start after the update on …”	The new version did not report ready in three starts. Nothing was rolled back	Decide: correct the cause, or roll back (below)
“The server has not answered for 15 minutes since it restarted for the update.”	Still starting, perhaps running migrations, or not starting	Look at the server’s log; roll back only if it is not coming up

There is no automatic rollback; a person decides.

Rolling back

A rollback returns this server to the previous jar and to the database backup that update took. Its command is shown on the card when an update did not come up (“To return to the previous version, run this on the server as administrator (root on Linux):”), in the server’s log on the UPDATE FAILED line, and in the output of UpdateTool status. On Windows, from an administrator command prompt:

"C:\Program Files\inSCADA\graalvm-jdk-21\bin\java.exe" -cp "C:\Program Files\inSCADA\inscada-launcher.jar" com.inscada.launcher.tool.UpdateTool rollback

It checks everything first, says what it will do and goes on only when you type yes. Nothing is deleted: the database the failed version ran on is renamed and kept.

Moving an existing installation to the update button

An installation made before the update launcher starts inscada.jar directly, and the card cannot update it. Moving it is done once, on Windows, in this order. The setup does not need to be run again.

1. Update the jar by hand first

The update card exists from 20261108-11 on, so the product must be on at least that release before anything else.

Download app-<rev>.jar of the release from the release page.
Stop the inSCADA service.
Replace inscada.jar in C:\Program Files\inSCADA with the new jar, named inscada.jar.
Start the service.

2. Get the launcher

inscada-launcher.jar is inside inscada-launcher-<rev>.zip on the same release page. Take it from the same release as the jar, and unzip it; the zip holds only that file.

3. Put three files in one folder

Copy into one folder on the server — the desktop will do:

inscada-launcher.jar (step 2);
enable-updates.bat and enable-updates.ps1, the two scripts that come with inSCADA Setup.

4. Run `enable-updates.bat` as administrator

Right-click enable-updates.bat → Run as administrator.

It first checks, and refuses with the reason and changes nothing unless: it runs as administrator; the service (inSCADA) exists and is run by NSSM; its command starts inscada.jar from the service’s own folder; inscada-launcher.jar is next to the script; and the service’s own Java can run the launcher. If the service already starts the launcher it says already enabled and changes nothing.

Then it shows what it found and what it will change, and:

saves the service command as it is (config\enable-updates.saved), for /undo;
copies inscada-launcher.jar next to inscada.jar;
creates the update\pending, update\backups, update\kept and update\state folders;
when the service runs under a named account rather than LocalSystem (OPC DA needs one, for DCOM), gives that account only the rights the launcher needs;
changes only the -jar target of the service command, from inscada.jar to inscada-launcher.jar. Everything else in the command stays.

It then asks:

Restart the inSCADA service now, so that it starts through the launcher?

SCADA is unavailable for the restart. Answer y (or e) to restart: it then waits until the product is really up through the launcher — the launcher’s start line, then the product’s own started line — and says so. If the launcher has not started within two minutes, the product within five, or the service stops first, it says so with the service’s status and asks whether to put the previous command back and restart again. Any other answer leaves the service running as it is; it starts through the launcher at its next restart.

It asks for Enter before the window closes. Everything it says also goes to logs\enable-updates.log.

It does not touch inscada.jar, the database, the configuration files or the version: it updates nothing, it only makes the update button possible.

Going back: `/undo`

enable-updates.bat /undo

puts the saved service command back, so the service starts inscada.jar again. It leaves inscada-launcher.jar and the update\ folders (they can hold database backups) and says so. Both /undo and the enabling take /restart (restart without asking) and /norestart (no question, no restart); /service <name> names a service not called inSCADA. Running either twice changes nothing and says so.

After that, the card works, and later releases come through the button.

Linux

On Linux the systemd unit starts the launcher instead of the product, with the same JVM options and arguments — ExecStart=/usr/bin/java … -jar /opt/inscada/inscada-launcher.jar … with Restart=on-failure — and /opt/inscada holds inscada.jar, inscada-launcher.jar and update/{pending,backups,kept,state}, owned by the service user. ExecStart has to run java directly, not a script.

New installations

An installation made with a setup that carries the launcher needs none of the above: the setup puts inscada-launcher.jar next to inscada.jar, creates the update\ folders and makes the service start the launcher. If it could not, the service starts inscada.jar as before and the install log says the update button is not enabled; enable-updates.bat then does it as described above.

Clusters

The update card is not offered on a cluster node: updating a cluster needs the updated standby to wait until the old leader has stopped, which one node’s button cannot arrange. A cluster is updated by hand, one node at a time, but never with two releases running side by side:

Both nodes are on the same release, the cluster is complete and the leader’s replication queue is empty.
Stop the standby, back up its own PostgreSQL, replace its jar. Do not start it.
Stop the leader. The field stops here.
Start the updated node alone. It becomes leader by itself.
See it work: leader, health and connections up. If it does not, stop it and start the old leader unchanged.
Update the old leader the same way (backup, jar) and start it; it joins as the standby on the same release.

Make no configuration change between steps 2 and 3. Going back follows the same order in reverse.

Before you upgrade

Every official release page starts with a Before you upgrade list: the changes in that release that take something away, or change an answer an installation may rely on. Read it for every release between yours and the new one — not only the newest — before you press Update and restart or replace the jar. Each item says who it concerns and what to do; most need nothing.

Server Settings — the update check switch, Restart now, signatures
License — maintenance, which decides which releases may be installed
Backup — the installation backup, beside the one an update takes