When we started designing the Opsot agent, the first architectural decision we locked in was: no inbound ports, ever. This post explains the reasoning, the tradeoffs, and how we built around it.
The Traditional Model and Its Problems
Prometheus's Node Exporter exposes metrics on port 9100 by default. To scrape those metrics, the Prometheus server must reach the agent over the network — your firewall must allow inbound connections on 9100. For teams with dedicated network infrastructure this is manageable, but for individual developers and small teams it creates real complexity:
- Managing inbound firewall rules across many servers
- Dealing with dynamic IPs on the monitoring server
- Expanding the attack surface of every monitored machine
- Getting firewall rules approved by security teams
The Outbound-Only Architecture
Our agent works in reverse. Instead of waiting to be scraped, it pushes telemetry to our platform over an authenticated WebSocket connection it establishes itself — outbound. Your server only needs to reach api.opsot.com:443, which every production server already allows. No new firewall rules. No open ports. No attack surface expansion.
The Tradeoffs
Outbound-only requires the agent to maintain a persistent connection. If it disconnects, you lose telemetry until reconnection. We address this with automatic exponential backoff, durable in-memory metric buffering (up to 5 minutes), and platform-side gap-filling. In practice, interruptions are seamless to end users.
The Security Win
Every inbound port you close is an attack vector you eliminate. With Opsot, your server's network exposure is identical with the agent installed as without it. Security teams approve Opsot in minutes because there is genuinely nothing to object to.