Skip to main content

​
Overview

For compatibility, point your reverse proxy at https://api.cyberdesk.io. Cyberdesk still exposes the machine tunnel there and replays it to the WebSocket service internally. Some organizations need to route that traffic through their own domain instead for network whitelisting, compliance, or privacy reasons. Cyberdriver’s --host flag lets you specify a custom endpoint. Combined with a reverse proxy on your end, Cyberdriver tunnel and API traffic can be routed through your domain instead of directly to Cyberdesk.
WebSocket Reverse Tunnel: Cyberdriver establishes a long-lived WebSocket connection that acts as a reverse tunnel—the server pushes commands through this persistent connection. Your proxy must fully support WebSocket connections, including:
  • Handling the HTTP Upgrade handshake
  • Maintaining persistent bidirectional connections
  • Not timing out idle connections (set timeouts to 24+ hours)

​
Quick Setup

1

Set up a reverse proxy

Create a proxy on your domain that forwards to Cyberdesk. See Proxy Options below.
2

Point Cyberdriver to your proxy

Run Cyberdriver with the --host flag:
cyberdriver join --secret YOUR_API_KEY --host https://your-proxy.yourcompany.com
3

Verify the connection

Check that your machine appears online in the Cyberdesk dashboard and run a test automation.

​
Proxy Options

Nginx is well-tested for WebSocket proxying and is the recommended approach: 
server {
    listen 443 ssl;
    server_name automation.yourcompany.com;

    # Your SSL certificates
    ssl_certificate     /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass https://api.cyberdesk.io;
        proxy_ssl_server_name on;
        proxy_set_header Host api.cyberdesk.io;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # WebSocket support (required for Cyberdriver)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # Long timeout for persistent WebSocket tunnel (24 hours)
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
    }
}
Usage: 
cyberdriver join --secret YOUR_API_KEY --host https://automation.yourcompany.com

​
Option 2: Caddy

Caddy handles SSL automatically and supports WebSocket out of the box: 
automation.yourcompany.com {
    reverse_proxy https://api.cyberdesk.io {
        header_up Host api.cyberdesk.io
        transport http {
            tls_server_name api.cyberdesk.io
        }
    }
}
Usage: 
cyberdriver join --secret YOUR_API_KEY --host https://automation.yourcompany.com

​
Option 3: Cloudflare (Proxied DNS)

If your domain is on Cloudflare, you can use Cloudflare’s proxy (orange cloud) with a simple origin server. Cloudflare handles WebSocket proxying automatically when the origin responds with a WebSocket upgrade.
Cloudflare Workers can proxy WebSocket connections, but for long-lived reverse tunnel connections, we recommend using Cloudflare’s standard proxy with an origin server (Nginx/Caddy) rather than a Worker.

​
Verifying the Setup

After configuring your proxy, test that Cyberdriver connects successfully: 
cyberdriver join --secret YOUR_API_KEY --host https://your-proxy.yourcompany.com --foreground
You should see output indicating a successful connection. Check your Cyberdesk dashboard—the machine should appear online. Run a test automation to confirm the full round-trip works (commands flowing from Cyberdesk → your proxy → Cyberdriver, and responses back).

​
Important Notes

HTTPS Required: Cyberdriver requires a secure connection. Ensure your proxy has a valid SSL certificate. Caddy handles this automatically; for Nginx, use Let’s Encrypt or your organization’s certificates.
Network Visibility: With a proxy, Cyberdriver tunnel and API traffic can be routed through your domain instead of directly to Cyberdesk. Keep in mind that Cyberdriver version checks and remote-update downloads still rely on GitHub, so strict egress allowlists may need to permit both your proxy domain and GitHub.

​
Troubleshooting

Your proxy may be timing out idle WebSocket connections. Ensure you have long timeouts configured:
  • Nginx: Set proxy_read_timeout 86400s and proxy_send_timeout 86400s
  • Load balancers: Set idle timeout to maximum (often 4000+ seconds)
Check that your proxy is correctly forwarding the upgrade headers:
  • Nginx: Must have proxy_http_version 1.1, Upgrade, and Connection headers set
  • Caddy: Should work automatically
  • Verify with: curl -I -H "Upgrade: websocket" -H "Connection: Upgrade" https://your-proxy.yourcompany.com
  • Ensure your proxy has a valid SSL certificate for your domain
  • The proxy must also trust api.cyberdesk.io’s certificate when connecting upstream
  • Nginx: proxy_ssl_server_name on is required for SNI
Check that bidirectional traffic is flowing:
  1. Verify no firewall is blocking WebSocket frames
  2. Ensure your proxy isn’t modifying or buffering the WebSocket data
  3. Check proxy logs for errors during message forwarding