Contrixt Bridge

Some systems in your data center are deliberately not reachable from the internet — a Proxmox cluster, a VMware vCenter or a Hyper-V host behind the company firewall. So that Contrixt can still read these environments without you opening a port to the outside, there is the Contrixt Bridge: a small agent you install inside your own network.

When do I need a bridge?

Whenever the API of an on-premises environment is not publicly reachable:

Environment	Bridge needed?
Proxmox VE without a public API	Yes — the bridge reaches https://pve.company.local:8006 from the internal network
VMware vCenter behind the firewall	Yes — the bridge talks to the vCenter REST API internally
Hyper-V (push script)	No — here a PowerShell script sends the data itself
API reachable at a public address	No — choose Direct (the cloud reaches the API)

If the API is reachable from outside anyway, Contrixt connects directly and you do not need a bridge.

How the bridge works

The bridge only ever connects outbound over port 443 (HTTPS) — just like a browser. It regularly asks Contrixt whether there is a task, runs it inside the internal network (e.g. "fetch the VM list from Proxmox") and reports the result back.

No inbound rule

No inbound firewall rule is required. You open no port and publish no internal addresses. The bridge initiates every connection itself.

Setting up a bridge

1. Open Administration → Bridges and create an entry via Create bridge (e.g. "Frankfurt data center").
2. You receive an installation token once. Copy it immediately — for security reasons it is not shown again.
3. Install the agent on a server in the internal network (see below) and finish setup with the token.
4. Shortly after, the status in the bridge list switches to Online.

Installation per operating system

The wizard shows the matching, ready-to-run command with the token already inserted. In general:

Debian / Ubuntu (.deb)

curl -fsSL https://app.contrixt.com/api/bridge/download/deb -o contrixt-bridge.deb
sudo dpkg -i contrixt-bridge.deb
sudo contrixt-bridge setup --url https://<your-tenant>.contrixt.com --key <TOKEN>

RHEL / SUSE (.rpm)

curl -fsSL https://app.contrixt.com/api/bridge/download/rpm -o contrixt-bridge.rpm
sudo rpm -i contrixt-bridge.rpm
sudo contrixt-bridge setup --url https://<your-tenant>.contrixt.com --key <TOKEN>

Generic Linux (tar.gz)

curl -fsSL https://app.contrixt.com/api/bridge/download/tar -o contrixt-bridge.tar.gz
tar -xzf contrixt-bridge.tar.gz && cd contrixt-bridge
sudo ./install.sh
sudo contrixt-bridge setup --url https://<your-tenant>.contrixt.com --key <TOKEN>

Windows Server (MSI)

Invoke-WebRequest https://app.contrixt.com/api/bridge/download/msi -OutFile contrixt-bridge.msi
Start-Process msiexec.exe -ArgumentList '/i contrixt-bridge.msi /quiet' -Wait
& 'C:\Program Files\Contrixt Bridge\contrixt-bridge.exe' setup --url https://<your-tenant>.contrixt.com --key <TOKEN>

The setup command stores the token and then starts the service automatically — as a systemd service on Linux, as a Windows service on Windows (if it is already running, it is restarted with the new configuration). The agent starts again automatically after a server reboot. If the automatic start fails, start the service manually with contrixt-bridge service start.

Status: online / offline

The bridge checks in with Contrixt every few seconds. In the list under Administration → Bridges you see per entry:

• Online — the bridge has checked in within the last minute.
• Offline — no contact for more than a minute (service stopped, server off, network issue).
• Inactive — you paused the bridge manually.

The list also shows how many virtualization connections use each bridge. If a connection routed through a bridge is offline, Contrixt points this out during sync.

Security

The bridge is deliberately minimal and built for transparency:

• Outbound only, port 443 only — no inbound firewall rule, no published internal addresses.
• Token shown once — the key is displayed exactly once and stored only as a hash. Replace lost tokens by deleting and recreating the bridge.
• No shell access — the bridge only performs defined HTTP requests against your virtualization APIs. It is not remote administration and opens no command line into your network.
• Limited scope — every task is validated (allowed protocols, size and time limits) before the bridge runs it.

Switching a connection to the bridge

In each virtualization form (Administration → Integrations → Proxmox / VMware) you find the Access field group:

• Direct (the cloud reaches the API) — the default when the API is publicly reachable.
• via bridge: <name> — routes the requests through the chosen bridge; the (online) / (offline) suffix shows its current status.

More about the connection itself is in Virtualization (VMs).