Technical Introduction to Convier
Convier is a webapp served by a Java HTTP server that runs as a single Docker container within your organization’s environment, e.g., as an App Service. No data leaves your network, and Convier does not require to store or copy any data to operate: all data is fetched from your existing databases and services on demand. Data is stored together with saved reports. Reports, if configured, are stored in your existing CRM, or in a database of your choice. Convier also does not require a database server, as configuration is stored locally. Convier runs in your existing Azure tenant/organization or equivalent.
Getting Started
Getting started with Convier consists of three steps:
- Installation (Download and run the Docker container, set up Single Sign-On, and assign access to users)
- Data Connection (Connect data sources, open necessary firewalls, configure authentication)
- Configuration (Connect data sources to a template configuration or start from scratch)
Resources from Convier are ready to assist with all three steps, including training users once the system is up and running.
Installation Patterns
The preferred way to install Convier is as an App Service or Virtual Machine that can be accessed directly from employee laptops and from within the company intranet.
For user authentication, the preferred method is Single Sign-On (SSO) with OIDC, for example, Microsoft 365 / Entra ID. Convier can run with an embedded OIDC provider for user authentication and authorization, but that is not recommended.
Convier has three different release tracks with different update intervals:
convier.azurecr.io/convier:releaseconvier.azurecr.io/convier:stable-stagingconvier.azurecr.io/convier:stable
It is common to create a User Acceptance Testing instance that follows the stable-staging track. stable-staging normally gets updated one week before stable, which gives time to perform testing when necessary.
System Requirements
Convier is designed to run with minimal resources within a Docker container. It consists of a server component and a browser-based web app that is provided to users by the server.
Server
Hardware
The primary requirement is a physical or virtual machine capable of running Docker. A Linux host is preferred but not required. The Docker container will use storage mounted on the hardware, or a provided database, to persist configuration.
Resources
The estimated required resources depend on the intensity of use and the amount of data being processed.
| Concurrent Users | RAM | CPU Cores | Disk Space |
|---|---|---|---|
| 1 - 2 | 4 | 2 | 4 |
| 2 - 10 | 8 | 4 | 8 |
| 11 - 30 | 16 | 8 | 16 |
| 31 - 50 | 20 | 16 | 24 |
Client
Requirements for the hardware/laptop users accessing the Convier web application:
- High screen resolution is recommended (minimum 1920 x 1080)
- A modern internet browser
- At least two CPU cores
- 4GB of RAM
The web browser must allow cookies for Convier to maintain user sessions.
Security Architecture
A high-level overview of the application architecture with required connection points:

Inbound
- The user needs to be able to access the URL of the Convier server running within the organization’s environment, either directly or through a VDI like Citrix.
Outbound
- An OIDC provider like Azure AD for user authentication and authorization (If none are available, we can provide one)
- The Convier private Docker registry to download software updates (currently https://convier.azurecr.io)
- Database connections to relevant data warehouses
- HTTP connections to relevant APIs
- Database connection to store application configuration (if not using embedded)
- Database connection to store audit logging (if not using embedded)
Installation
Installation in Azure (Preferred)
See Running as an App Service in Azure
Manual Installation
Make sure you have docker installed: https://www.docker.com/ and optionally docker-compose plugin.
Log in to Convier Docker registry
docker login convier.azurecr.io
You will be asked for credentials. Get in touch with us if you don’t have these.
Run
docker run -p "0.0.0.0:80:14445" \
-v ./data/app:/opt/convier/data \
-e JDBC_CONNECTION_STRING='jdbc:sqlite:/opt/convier/data/internal.db' \
convier.azurecr.io/convier:stable
With docker-compose.yml
version: '2'
services:
convier:
image: convier.azurecr.io/convier:stable
container_name: convier
restart: always
ports:
- 0.0.0.0:80:14445
volumes:
- ./data/app:/opt/convier/data
environment:
- JDBC_CONNECTION_STRING=jdbc:sqlite:/opt/convier/data/internal.db
Then run:
docker-compose up -d
Check logs:
docker compose logs -f convier
Health check
A health check endpoint is available at /convier/ping without authentication. It returns an empty HTTP 200 response. This endpoint is also the most relevant for readiness/liveness checks in a Kubernetes environment.
High availability / Scaling
The Convier application supports horizontal scaling, but for session management it is required that the load balancer supports session pinning to make sure that requests from a single user are directed to the a single instance.
Upgrade
Upgrades to Convier do require manual migrations. Normal downime during a single instance upgrade is between 30 seconds and 300 seconds.
docker compose pull && docker compose up -d
Audit logging
Backup
As Convier stores no data, only the configuration database needs to be backed up. When running an App Service with a persisted home folder, this backup is by default performed automatically.
Data Privacy
Convier stores no customer data, which limits the privacy challenges. The configuration database may contain customer data used for testing purposes, but this can be avoided, e.g. by testing on synthetic data in a User Acceptance Testing environment. The contents of this configuration is stored with AES256 encryption, where the symmetric key is provided to the application as an environment variable/secret.
Permissions
Within the Convier application, each user is assigned two different roles: One for the application as a whole, and one for each project. The roles are determined by the authentication provider, for example Azure AD.
Instance-level roles:
MANAGEAUDITREAD
One users to instance-level role MANAGE can add external data sources (limited by firewall settings) and also track high-level application usage. By default, only MANAGE role can create new projects.
The AUDIT instance role can query the internal audit log database, if enabled
Project-level roles
OWNMANAGEREAD
The READ role is only able to access data, and make individual configuration changes that can not be shared with others without approval. They can not add external data source connections. The MANAGE project role is able to share configuration changes with others, and is usually reserved for Convier personel and customer subject matter experts. The OWN project role can do the same as the MANAGE project role, but can also assign project roles to others.