Skip to content

Downloads

Data Controller releases are published on the releases page of the source repository. Every release carries the same set of assets:

Asset Use
frontend.zip The pre-built web frontend, for deployments that serve the frontend from a web server (SAS 9 full deploy, Viya separated deploy)
sas9.sas SAS 9 full deployment program (stored processes + frontend registration)
demostream_sas9.sas SAS 9 streaming deployment program (demos and evaluations)
viya.sas Viya streaming deployment program (backend + frontend)
viya_noweb.sas Viya separated deployment program (backend only)
viya_noweb.json The Viya backend services as a SASjs Drive JSON deployment bundle
sasjs_server.json.zip SASjs Server deployment bundle (all services, for SASjs Server deployments)
SHA256SUMS SHA-256 checksums for every asset above

Which asset you need depends on the deployment route - see SAS 9 Deployment or SAS Viya Deployment.

Verifying a download

Every asset is covered by the SHA256SUMS file, which the release pipeline generates over the exact files it uploads. To verify a download:

  1. Download the asset (for example frontend.zip) from the releases page.
  2. Download SHA256SUMS from the same release into the same folder.
  3. Run the check:
sha256sum --check SHA256SUMS --ignore-missing

Each asset that matches reports OK. The --ignore-missing flag means you only need the files you actually downloaded - the check skips assets you did not fetch.

On Windows, certutil can compute the hash of a single file for comparison against the value listed in SHA256SUMS:

certutil -hashfile frontend.zip SHA256

What the checksum proves

A matching checksum confirms the asset is byte-for-byte the file the release pipeline uploaded. It catches corrupted and tampered downloads - interrupted transfers, proxies or mirrors that altered the file in transit.

It is not a cryptographic signature. The hashes travel in the same release as the files they cover, so they protect the download path, not the release itself: a compromise of the forge would allow both the asset and its checksum to be altered together. For download integrity - the typical concern when fetching deployment artifacts over the internet - it is the standard check.

Integrity inside SAS

The SAS deployment programs embed the frontend and services as generated SAS code. Once %inc'd, their integrity is established by the check above at download time. They deploy the stored processes or jobs into the SAS Folder you nominate (appLoc) - a metadata location, not physical disk - and the only physical location they write to is the Data Controller location (dcLoc) you configure. The programs can be reviewed in full (or in the source repository) before you run them.