Skip to main content
A shared Vexlo server collects recordings from multiple application hosts and gives your team one URL for the web UI and HTTP API. Each application host keeps its own SDK queue and relay. The MCP server connects to the shared HTTP API on behalf of its agent client. You operate the shared server. For a local installation, use Install and run. To use either instance in a browser, follow Web UI.

​
Deployment layout

The SDK does not need the shared server URL or its credentials. It writes to the local queue; the relay reads that queue and forwards records. Set the same VEXLO_SPOOL_DIR for the SDK and relay on each host. Do not point applications on separate hosts at a shared queue directory.

​
Prepare the server host

Complete Build the binary first. You also need:
  • A persistent directory writable by the server process for its database and captured values.
  • A DNS name reachable by the application hosts and readers.
  • A TLS certificate and private key for that name, trusted by your clients and relay hosts.
  • Network access to the server listener from those hosts.
Choose the storage location and configure the listener. Replace the paths below with absolute paths on the server host; the certificate and key must already exist.
The UI and API share one listener. Supplying a certificate enables TLS. Without TLS, a non-loopback listener is refused unless the transport check is explicitly bypassed. Keep TLS enabled for this deployment.

​
Issue credentials

Run token administration on the server host with the same VEXLO_DATA_DIR. For a team named platform, create separate delivery and read credentials:
Give the ingest credential to the relays and read credentials to readers. A token’s team scope controls access to the records; a deployment environment label does not replace team scope. For separately revocable relay credentials or restrictions on service and environment, issue additional tokens using Authentication.

​
Check and start the server

Check the configuration with an estimate of the incoming trace rate. The example below uses 0.1 traces per second; replace that estimate with the rate you expect to record.
Resolve any configuration or capacity failure before starting. The estimate is a planning input, not a traffic limit. Configuration explains the check’s fixed per-trace size estimate and the storage settings it evaluates. Start the server with the same environment:
Retain the selected data directory across restarts. Configure your process supervisor to supply the same paths and TLS settings; this command runs in the foreground.

​
Connect application hosts

Install vexlo on each application host using the same build procedure. Configure that host’s relay with the shared server URL, its ingest token, and the queue directory used by its SDK. For example, after securely placing the ingest credential in an application-host file:
Replace the URL and paths for your deployment. The token file supports later reloads; the environment variable supplies the startup credential. The file must contain the credential itself, without the token command’s token: label. The SDK and relay processes need access to the selected queue directory. Configure the SDK using Python SDK. The environment label comes from the relay; the service name comes from the SDK. The relay health listener stays local to its host by default, at 127.0.0.1:9101. Check it on that host. A healthy relay does not establish that a request has reached the shared server; verify an actual recording as well.

​
Connect readers and verify delivery

On a reader’s machine, set the shared URL and a read credential:
Open the same base URL in a browser and connect with the read token. No separate UI deployment is required. Configure agent clients with VEXLO_API_URL set to that URL and VEXLO_TOKEN set to a read token; see Connect an agent. Record a request from an application host, then search for it in the shared UI using its service, environment and identifier. Open the recording and confirm that calls and captured values are available. This verifies the full path rather than only connectivity.

​
Operate the shared instance

Keep server storage and each host’s queue under separate capacity monitoring. Server call metadata, full values and function history have different retention rules; host queues also have limits during outages. Review Retention before choosing storage. For a reverse proxy, keep the server’s upstream listener on loopback when the proxy runs on the same host. Forward both UI and API traffic. A TLS-terminating proxy and a loopback HTTP upstream preserve the server’s local transport rule. Header-trust mode is a separate access configuration: it requires the proxy to authenticate readers and inject the configured trust secret and team headers. Ingest requests still require ingest tokens. See Authentication for the trust boundary and Configuration for supported settings.