Running Omniscope on Google Cloud VM - practical notes

Purpose

This note provides practical guidance for deploying Omniscope on a Linux virtual machine in Google Cloud Platform for an initial internal deployment.

Scope

This document is intended for:

• single-environment deployment on GCP

• internal evaluation / pilot / development use

• Linux VM-based installation

It is not intended to define a full production architecture, HA design, or managed container deployment.

Recommended approach

For an initial deployment, the recommended approach is:

• provision a dedicated Linux VM in the target GCP region

• install Omniscope on that VM using the standard Linux installation process

• secure access appropriately

• validate functional and compliance requirements

• expand to a broader architecture later if required

Region

Deploy in the agreed region:

• e.g. Google Cloud europe-west2-b

VM guidance

Recommended starting point for an initial deployment:

• OS: Ubuntu Server LTS, 64-bit x86 (see Linux Installation)

• VM role: dedicated VM for Omniscope only

• Minimum practical starting size: 2 CPU cores, 12 GB RAM, 250 GB SSD

• GCP example machine type: system requirements cite n1-highmem-2 as an example on Google Cloud (see Omniscope system requirements)

• Disk: use SSD persistent disk; increase sizing if workflows or large cached/report datasets are expected

Notes:

• Omniscope uses available memory and can spill to disk, so fast SSD/NVMe-backed storage is strongly preferred (see Disk Space and Performance)

• For larger ETL or report workloads, disk requirements can grow significantly; 250 GB is a reasonable starting point, not a hard maximum.

Network and access

Recommended baseline:

• restrict inbound access to required management and application ports only

• limit access by source IP where possible

• prefer private networking and controlled access paths

• expose the application only through the approved access path

• use HTTPS for all browser access

Typical ports:

• 22 for SSH administration

• 8080 for HTTP if used temporarily during setup

• 8443 for HTTPS if using Omniscope’s default HTTPS port

• 80 / 443 only if you explicitly configure Omniscope or a reverse proxy to use standard web ports.

If the VM is internet-facing, assign a stable public IP or put it behind a stable DNS name. If the deployment is internal-only, prefer private IP access and private DNS.

DNS / TLS

Recommended baseline:

• assign a stable hostname

• configure TLS certificates for secure browser access

• redirect HTTP to HTTPS once HTTPS is in place

Omniscope supports HTTPS directly, including use of a trusted keystore certificate (see Security: Web Server SSL configuration)  On Linux, Let’s Encrypt can be set up using the bundled SSL console script if the VM has a valid DNS name and internet reachability (see Setup HTTPS using Let's Encrypt on Linux.)

For initial deployment, either of these approaches is reasonable:

• use Omniscope’s built-in HTTPS

• place Omniscope behind a reverse proxy / load balancer and keep Omniscope access settings aligned with the externally presented URL

Also configure the external base URL in Omniscope (Admin section) so the generated Report links are correct.

Installation approach

Install Omniscope using the standard Linux installation method, as per our guide here.

Practical points:.

• use a dedicated Linux service account

• install under that user’s home directory, typically:

  • ~/visokio-omniscope

• run the systemd service as that same user 

Omniscope on Linux normally runs as an unprivileged user. If you want direct binding to ports 80/443, additional Linux configuration is required; otherwise, staying on 8080/8443 or using a reverse proxy is simpler.

Activation

Omniscope can be activated using:

• online activation, where outbound connectivity is permitted

• manual / offline-style activation workflow, where direct access to the activation server is blocked by firewall or cybersecurity policy.

If using online activation from Linux command line, outbound internet access is required.

Storage / backup

Recommended baseline:

• use persistent SSD storage

• ensure regular snapshot / backup procedures are in place

• preserve the VM disk where possible, because activation state is stored on disk 

• confirm how logs, configuration, and project assets will be retained and restored

Useful storage locations / concepts:

• install folder: typically ~/visokio-omniscope 

• sharing / projects folder: typically /home/<user>/omniscope-server/files (see more Projects folder / sharing folder configuration )

• workflow temp / data engine temp: configurable in Admin > Disk Manager; keep them on storage with sufficient free capacity and preferably separate locations where appropriate (see more about Disk Space and Performance)

Local SSD-backed storage on the same VM is preferred over network-mounted storage for performance and reliability 

Scaling later

If the deployment later expands, additional design considerations may include:

• separate sandbox and production environments

• failover or multi-node setup

• shared configuration / project storage

• load balancing

• monitoring and alerting

These should be assessed separately once the initial deployment is validated.

Before security testing

Before formal security or penetration testing is carried out, the intended configuration should be reviewed to reduce avoidable issues caused by incomplete setup.