For customers who do not want to mange their own servers, the Secure Edge option can offer deployment of the Edge with no software expertise or management overhead.

Machine requirements

1. Any machine capable of running Docker with a container that runs Linux.
2. Platform: 86-64 / amd64 / arm64
3. RAM: 512M (1GB+ recommended)
4. Storage: 200M for the Docker container, plus host space for the OS, image upgrades, logs and offline buffering (see Running on AWS EC2)

Supported Operating Systems

Networking requirements

For how the Edge is placed on the network — routing, multiple NICs, isolated VLANs and DMZ deployments — see Networking.

📘

Note for security teams

Port 443 on eu1.edge.xyte.io uses a custom certificate created and distributed by Xyte, to be used by our Edge — it is not to be accessed via web browsers. Regular SSL check tools will therefore fail it.

🚧

No HTTP proxy support

The connection between the Edge and eu1.edge.xyte.io is not web traffic, so it cannot be routed through an HTTP/HTTPS proxy — proxy environment variables, Docker's proxy settings and PAC files do not apply to it. The Edge host needs a direct outbound route on port 443 to the endpoints below. On a network where internet access is only available through a proxy, ask the network team for a direct egress rule for the Edge host.

📘

Firewall rules: allow by hostname, not IP

Xyte does not publish fixed IP ranges for these endpoints. Their addresses can change when infrastructure is replaced or new endpoints are added, and Docker Hub is served from a CDN with no fixed range. Create the outbound rules by hostname (FQDN), and exclude these destinations from SSL/TLS inspection — re-signing the Edge's certificate breaks the connection.

1. Outgoing connection to:

   1. eu1.edge.xyte.io on port 443
   2. us1.edge.xyte.io on port 443(Future endpoint, must be opened to avoid changes later)
   3. *.docker.io on port 443 (Docker Hub registry & authentication — required to pull/upgrade the Edge container)
   4. *.docker.com on port 443 (Docker Hub image download / CDN)

2. Direct local access to all devices to be monitored (depending on protocol supported by device)

   Protocol	Ports	Comments
   ICMP	echo request / reply	Required for every monitored device, whatever protocol it uses. The Edge uses ICMP for the device status check, and on heartbeat-only models it is the only signal.
   SNMP	161
   HTTP(s)	80, 443
   IPMI	623
   Other	-	Some devices have custom protocols for control.

Usage Limits

The above requirements are suitable for managing 250-500 devices. The exact count is dependent on the device types, as different drivers require different resource utilization. A machine with 2 vCPU / 4 GB RAM can manage up to 1,000 devices (see Running on AWS EC2).

Network usage

The network usage is minimal as drivers perform periodic API calls. Approx 5-20 calls per device, per hour (excluding ping tests) and carry minimal data.

Running on AWS EC2

The Edge runs well on a standard Linux EC2 instance. Recommended setup for an Edge managing up to 1,000 devices:

• Avoid burstable instances (T-family). The Edge polls on fixed intervals around the clock (ping every 10-30 s, driver calls every 5-60 min), a steady baseline load that can drain CPU credits.
• Storage covers the OS, Docker images across upgrades, logs, and the data the Edge buffers locally while it is disconnected from the Xyte cloud.
• Use Linux. Most non-bare-metal EC2 types cannot run WSL2 (see the Windows tab under Supported Operating Systems).

Network placement

See also Networking for routing, multiple NICs and isolated VLANs.

• Reach to the devices. The instance must have routed access to every office network it monitors (Site-to-Site VPN or Direct Connect, optionally through a Transit Gateway), with the device ports listed under Networking requirements allowed end to end.
• Latency. Keep latency from the Edge to its devices low (ideally under 100 ms): run each Edge in the AWS region closest to the offices it serves, and split distant sites across several Edges. Device timeouts are several seconds, so distant sites still work, but ping-based status gets noisier.
• Security group. No inbound rules are needed — all connections are initiated by the Edge. Security groups filter by IP, not hostname: keep the default allow-all egress, or filter the Xyte and Docker hostnames with AWS Network Firewall or an egress proxy, and allow ICMP, SNMP, HTTP(S) and IPMI to the device subnets.