Deployment

Architecture and deployment options.

Same product, same container, three ways to run it. This page shows how the pieces fit together and what each deployment model looks like in practice.

Post Quantum Leap deployment and integration architecture Users reach the application over HTTPS through Caddy, which terminates TLS and proxies to the Post Quantum Leap container on port 8000; that container stores everything in PostgreSQL 16. Sign-in is federated to Entra ID or any OIDC provider. All three containers run on one container platform: Docker, Podman, Azure Container Instances, or Kubernetes, which is in development. Two optional enterprise integration components sit between the application and your infrastructure: an enterprise proxy server that scans pass through, and the Bifröst remote engine, a container deployed inside an isolated segment such as a DMZ. Bifröst opens one outbound connection to the application and receives its work down it, so no inbound firewall rule is ever needed and the application never dials the engine. The application scans network endpoints for TLS configuration, and a client scanner installed on hosts submits a cryptographic bill of materials back to the API. Bifröst both scans the hosts the application has no route to and relays the cryptographic bill of materials from client scanners running inside that segment, so those hosts need no path out of it either. Entra ID · OIDC single sign-on, auto-provisioning SSO CONTAINER PLATFORM HTTPS :443 Caddy reverse proxy · TLS termination :8000 Post Quantum Leap application and web interface one image PostgreSQL 16 persistent volume Docker · Podman · Azure Container Instances · Kubernetes (in development) ENTERPRISE INTEGRATION Enterprise proxy optional, scans traverse it Bifröst remote engine runs inside the isolated segment scans TLS endpoints outbound only the engine dials in YOUR INFRASTRUCTURE Network endpoints TLS services, any port Client scanner multi-platform, Linux and Windows runs on the host itself Isolated hosts · DMZ no route from the server CBOM submitted to the API scans, and relays the client scanner’s CBOM
Pinch to zoom in on any part of the diagram

Three ways to deploy it

Managed as SaaS

Available on request

We run it for you.

  • Hosted in a Swiss Azure region, so your data stays in Switzerland under Swiss law
  • We handle updates, backups and monitoring
  • Scanners reach your infrastructure over an outbound-only connection

Best when
You want the inventory without operating another service.

Your own cloud

The same container, in your tenant.

  • Azure, AWS, GCP or any container host
  • Docker Compose, or an install script for Azure Container Instances
  • You own the data, the network path and the identity integration, with Entra ID or any OpenID Connect provider

Best when
You already run containers and want the data under your own subscription.

On premises

Self-contained, with no outbound dependency.

  • Runs in your data centre or a segregated network
  • Works air-gapped: endpoints download the scanner from Post Quantum Leap itself, not from the internet
  • No telemetry and no licence call-home; your own trust anchors and CAs

Best when
Regulated, segregated or air-gapped environments.

Kubernetes

In development

Coming soon.

A Helm chart for clustered deployments: horizontal scaling of scan workers, support for managed PostgreSQL, and standard ingress in place of the bundled Caddy.

← Back to the product