Qntrl Bridge is lightweight, but resource usage scales with the number and type of tasks (API, DB, SSH, PowerShell, AD, file operations).

Typical sizing recommendations:

Disk space includes:

• Bridge binaries

• Bundled PostgreSQL database

• Logs and operational data

Network Requirements   

General Network Connectivity   

The Bridge host must have:

Outbound connectivity to Qntrl

The Bridge host requires outbound access to the following Qntrl endpoints on port 443 over WSS/HTTPS (TCP):

For regions other than the US data centre, domains may vary. Refer to the Allowed IP Addresses help page for region-specific details.

Firewall Note: Ensure outbound HTTPS (port 443) from the Bridge to Qntrl endpoints is allowed and not intercepted in a way that breaks WebSocket connections.

Internal Network Connectivity

The Bridge host must also have inbound and outbound access within your LAN to reach internal systems:

• REST / SOAP APIs

• Databases

• Linux or Unix servers via SSH

• Windows servers via PowerShell / WinRM

• Active Directory / LDAP

• SFTP servers

• File shares (SMB)

Recommended LAN bandwidth:

• 100 Mbps recommended

• Lower bandwidth may reduce throughput for high task volumes.

Firewall Note:
Ensure outbound HTTPS traffic on port 443 is not intercepted in a way that breaks WebSocket communication.

IP  Whitelisting   

Ports and Protocols   

Inbound to Bridge Host

Outbound from  Bridge Host

To Qntrl 

Outbound to Internal Systems   

Direction: Outbound

Software Dependencies   

Qntrl Bridge includes a bundled Java runtime and bundled PostgreSQL database — no external runtime installation is required in most cases.

On the Bridge Host

Java Runtime

Property	Value
Bundled JRE Version	11.0.17
Default JVM Heap Size	512 MB
Configuration File	BRIDGE_DIR/conf/wrapper-bridge.conf

No separate Java installation required

Permissions and Accounts   

Bridge Service Account   

Bridge runs as a system service or daemon.

Windows   

• Use a dedicated local or domain service account (recommended)

• Required privileges: Log on as a service, read/write access to BRIDGE_DIR

• Avoid using domain administrator accounts — follow the least-privilege principle

Linux   

• A non-root user is required to run the Bridge service

• Required privileges: read/write access to BRIDGE_DIR

• sudo may be required only during installation or specific administrative operations, not for regular runtime

 

Security and Compliance   

Connectivity   to Qntrl 

• Connection Type: Outbound TLS-secured WebSocket

• Protocols: WSS, HTTPS

• Port: 443

• TLS Version: TLS 1.3 or later

 

Certificates   

• Qntrl endpoints:

• Use certificates issued by a trusted public CA

• Qntrl Bridge validates Qntrl certificates using the host OS trust store

• Bridge Web UI (optional HTTPS):

• For the Bridge Web UI, you may configure a customer-provided certificate (internal or public CA).

• Minimum key length: 2048-bit RSA or equivalent (e.g., ECDSA)

 

Logging and Auditing   

Bridge Logs

• Location: BRIDGE_DIR/logs

• Retention: 5 most recent log files. Older files are removed.

• Rotation: Size-based, max 5 MB per file

Task Logs

• Location: BRIDGE_DIR/logs/SERVICE_DIR

• Retention: 5 recent log files are retained; older files are removed.

• Rotation: Size-based, max 5 MB per file

Total log disk usage depends on the number of services, tasks, and log verbosity configured.

Browser Requirements (Bridge Web UI)   

Supported browsers:

• Google Chrome – latest two versions

• Microsoft Edge (Chromium) – latest two versions

• Mozilla Firefox – latest version and ESR

Not supported:

• Internet Explorer

• Legacy Edge (non-Chromium)

Minimum screen resolution:

• 1280 × 720

High Availability and Scalability   

Multiple Bridges

You can deploy more than one Qntrl Bridge per environment for:

• Different network segments (e.g., DMZ vs. internal)

• Different environments (e.g., Production vs. Non-Production)

• Functional segregation (e.g., DB-heavy vs. file-heavy tasks)

Each Bridge instance:

• Maintains its own WebSocket connection

• Has its own PostgreSQL instance

Load Handling

For high workloads:

• Scale horizontally by adding additional Bridge instances.

• Qntrl automatically distributes tasks across connected Bridges.

Failover

If one Bridge instance becomes unavailable:

• Tasks can be automatically rerouted to other Bridge instances configured within Qntrl.

• Refer to the Qntrl Bridge Clustering / Failover Guide for configuration details.
  

Backup and Recovery   

Data to Back Up (on the Bridge Host)

Backup Methods   

• File-level backups using your standard backup solution (snapshot-based or agent-based)

• Optional: Native PostgreSQL backups (pg_dump, base backups) if point-in-time recovery is required

Recovery Steps (High Level)   

1. Install or redeploy Qntrl Bridge on a new host (with compatible OS and hardware).

2. Restore:

• PostgreSQL data directory

• Configuration directory (conf)

3. Start the Qntrl Bridge service.

4. Verify:

• Qntrl Bridge reconnects to Qntrl.

• Processed request history and status are visible in:

• Qntrl

• The Bridge Web UI

Deployment Considerations   

Deployment Types   

• Single-server: One Bridge host per environment or network segment (typical)

• Multiple Bridges: For environment segregation(prod vs non-prod), different security zones, or capacity and high availability

Offline / Restricted Environments   

• Bridge requires outbound connectivity to Qntrl over HTTPS/WebSockets (443).
• Fully air-gapped environments are not supported.
• If direct internet access is restricted,configure outbound proxy access to Qntrl endpoints.

Time Synchronization   

Accurate time synchronization is required on:

• The Bridge host

• AD / LDAP servers

• Databases and remote systems

Recommended:

• Use NTP or an equivalent time synchronization mechanism.

• Keep clock skew within ±5 minutes maximum (or stricter, depending on authentication mechanisms such as Kerberos or certificate validation).

Terminology