Request a quote Try for 30 days
server edition

Deploy Spectrum for your team

The Server edition runs in a container and uses your company's PostgreSQL database. These steps cover image preparation, first import, access configuration and updates. The image supports OpenShift requirements, including non-root operation with an arbitrary UID in group 0.

1. Prepare the container image

The name and registry are in the key email and the release's manifest.json file: <rejestr>/viewer-pro-server:<wersja>. If the cluster cannot access the external registry, load the image from the viewer-pro-server-<wersja>.tar file into your internal registry:

podman load -i viewer-pro-server-1.4.2.tar
podman tag viewer-pro-server:1.4.2 default-route-openshift-image-registry.apps.firma.local/viewer-pro/viewer-pro-server:1.4.2
podman push default-route-openshift-image-registry.apps.firma.local/viewer-pro/viewer-pro-server:1.4.2

2. Prepare PostgreSQL

Prepare PostgreSQL 16 with a database created using ICU locale pl-PL, one database and a role allowed to create tables in schema public. Check database parameters in the instructions included with the chosen release.

CREATE ROLE viewer_pro LOGIN PASSWORD '...';
CREATE DATABASE viewer_pro OWNER viewer_pro;

Plan storage for configuration, history and backups. Confirm resource sizing during the pilot. The optional file postgres.yaml is for testing only; prepare production databases according to your organisation's operational standards.

3. Store credentials and the licence key

Create a Secret with the database URL, secret store encryption key and licence key. The file secret.example.yaml is a template; once filled with credentials, keep it outside the repository.

oc new-project viewer-pro
oc create secret generic viewer-pro \
  --from-literal=WC_PG_URL='postgres://viewer_pro:HASLO@pg.firma.local:5432/viewer_pro?sslmode=require' \
  --from-literal=WEBCON_SECRET_KEY="$(openssl rand -base64 32)" \
  --from-literal=WEBCON_LICENSE='WCR1....'

4. Apply the deployment files

The package viewer-pro-openshift-<wersja>.zip contains deployment.yaml, service.yaml, route.yaml, secret.example.yaml and kustomization.yaml. Set the image URL and route hostname, then run:

cd deploy/openshift
# kustomization.yaml: images[0].newName / newTag; route.yaml: spec.host
oc apply -k .
oc rollout status deploy/viewer-pro
oc get route viewer-pro -o jsonpath='{.spec.host}{"\n"}'

The standard deployment requires one application replica. Do not increase the replica count without confirming support for that configuration in your chosen edition.

elementvalue
container port8080 (variable PORT; OpenShift may assign another)
readiness / livenessGET /healthz → 200 with software version
usernon-root, arbitrary UID in group 0 (chgrp 0, chmod g=u on writable directories)
resourcesrequests 250m / 512Mi, limits 1 CPU / 2Gi — starting values; adjust for configuration size and load
routeTLS edge or reencrypt; the application supports X-Forwarded-* and sets security headers (CSP with nonce, HSTS)
loggingJSON logs to stdout; sign-in attempt rate limiting

5. Docker / Podman without an orchestrator

docker run -d --name viewer-pro \
  -p 8080:8080 \
  -e WC_PG_URL='postgres://viewer_pro:HASLO@pg.firma.local:5432/viewer_pro' \
  -e WEBCON_SECRET_KEY="$(openssl rand -base64 32)" \
  -e WEBCON_LICENSE='WCR1....' \
  --restart unless-stopped \
  <rejestr>/viewer-pro-server:1.4.2

curl -s http://localhost:8080/healthz

Place a TLS-enabled reverse proxy, such as nginx, Traefik or Caddy, in front of the container. It handles the encrypted HTTPS connection.

6. Configure team access

  1. With an empty database, open the application and create the first administrator account using your own login and a strong password. Do this before sharing the application URL with other users. No account or password is automatically generated in the log.
  2. Roles and grants: create roles (e.g. “Analysts”, “Deployment team”), assign read scopes (all environments / workspace / environment / application), and add accounts to roles. An account without a role sees an empty list after sign-in; “Effective access” shows what each person can see.
  3. Sign-in. The edition described here supports local accounts and roles. An edition with SSO integration is also available for organisations using Microsoft Entra ID. Confirm the image and sign-in configuration before deployment; a gateway in front of the application does not replace its permission checks.

7. Load configuration and set a schedule

Packages .bpe can be uploaded in the Importtab. Alternatively, copy files into the container and run import using oc exec:

oc cp ./eksport/DEV viewer-pro-xxxx:/tmp/dev
oc exec deploy/viewer-pro -- viewer-pro ingest import "/tmp/dev/*.bpe" --workspace "Klient A" --env DEV

Configure MS SQL sources in the SQL sourcestab, and scheduling in Workspace. Choose a retrieval interval or time, and check execution in the retrieval log. Unchanged configuration does not require a new snapshot.

Access limits. The company plan specifies the number of active users; the partner plan specifies client workspaces. At the limit, the software prevents adding another account or workspace and displays a message. Existing data remains accessible. Definitions of an active user and client workspace are in the plan table, and plan change rules in the licensing guide.

8. Update the application

pg_dump -Fc viewer_pro > viewer_pro-przed-1.5.0.dump
oc set image deploy/viewer-pro viewer-pro=<rejestr>/viewer-pro-server:1.5.0
oc rollout status deploy/viewer-pro

Back up the database before changing the image. Follow the release instructions. Saved snapshots remain accessible. Returning to an older image requires restoring a pre-update backup. Also check the annual subscription's validity. Non-payment for renewal blocks access after the grace period in the order, even when reverting to an older version.

9. Check required connections

Full list of data leaving the network: security.