1. Help & Support
  2. Hyperglance Admin

Deployment Architecture Overview

Hyperglance is deployed as an Instance/VM image with 2 volumes attached via the AWS or Azure Marketplaces. One for the Operating System and one for user/customer data. All customer data is stored in the data volume. There are also options to deploy Hyperglance onto your own VM or Kubernetes. 

The system comprises multiple docker containers; HTTPD, Wildfly and PostgreSQL. In the VM deployments these are governed by a Docker Compose file located at: /etc/docker-compose.yml

This architecture makes it easy to move from one tier to another in the AWS or Azure Marketplace (see instructions for AWS and for Azure) and to deploy on your own Instance/VM or into Kubernetes.

It also makes upgrading to newer versions very easy.

Hyperglance architecture v2.0-1

File Locations:

Here are the locations of all the important system files for Hyperglance. These are all locations on the host VM and can also be found by examining the contents of the docker-compose.yml file:

Docker Compose file:


Main configuration file:


SAML configuration:


SSL certificate:


Saved Rules:


SMTP config:


Database (storing account credentials, tag-views, collection configuration and API registrations):





Useful Commands

These commands may come in useful from time to time as you are managing or scripting your Hyperglance deployment environment:

Pull latest containers from repo:

sudo docker-compose -f /etc/docker-compose.yml pull

Update Hyperglance with new containers:

sudo docker-compose -f /etc/docker-compose.yml up -d

Display running containers:

sudo docker ps

Restart a docker container by name (e.g. wildfly):

sudo docker restart wildfly

Stop a docker container by name (e.g. wildfly):

sudo docker stop wildfly

Start a docker container by name (e.g. wildfly):

sudo docker start wildfly

List docker images:

sudo docker image ls

Remove a docker image:

sudo docker image rm 8f79a9884195


Hyperglance only needs Read Only access to your AWS, Azure and/or Kubernetes API. It doesn't connect to any of your internal or external resources. 

All communications between the APIs we connect to (AWS, Azure & Kubernetes) and all Hyperglance clients are over HTTPS, port 443 and use the latest encryption. 

Since Hyperglance runs inside Instances/VMs you control encryption at rest. This is an option you can set at any time.

It supports custom SSL certificates via the HTTPD proxy that comes as part of the deployment.

Hyperglance comes with a built in Role Based Access Control system and SAML is built in by default.

Local user passwords are securely hashed and salted (PBKDF2WithHmacSHA256).