Monitoring devices on the client's internal network via a LAN agent

In brief Cloud monitoring can't reach devices on the client's internal network — NAS units, cameras, local servers, printers. The ePulz.io LAN agent solves this with a pull model: a tiny daemon in your network calls ePulz.io over regular HTTPS, receives a list of IPs to check, pings them locally and sends results back. No port forwarding, no VPN, no open ports from outside.

The problem: the cloud can't see inside

Classic uptime monitoring runs in a data center. It works great for publicly accessible websites — an HTTP request from Frankfurt to your hosting and back. The problem starts the moment you want to monitor something that isn't visible from the outside:

• A NAS with backups (192.168.1.10)
• Internal Grafana / Prometheus / Jira on 10.0.0.50:3000
• IP cameras in the store, IoT gateways, network printers
• A router or switch you want to know about when it goes down
• VPN gateway, RADIUS server, local DNS

Common solutions come with uncomfortable trade-offs:

• Port forwarding — you open a public port on the router, monitoring connects via the public IP. A security horror, often against company policy.
• VPN tunnel between monitoring and the client's network — works, but requires setup on the IT side, static peer configuration and ongoing maintenance.
• Cron on the client's server that pings monitoring — a heartbeat. Works, but only tells you the agent is alive, not whether a specific target on the network is reachable.

The solution: a pull-model agent

The ePulz.io LAN agent reverses the direction of communication. Instead of the server forcing its way into the client's network, a simple daemon in the client's network contacts the server itself. The principle:

1. Every 30 seconds the agent asks: "Which monitors should I check now?"
2. The server returns a list (for example: ping 192.168.1.10 every minute, TCP 192.168.1.50:5432 every 5 minutes).
3. The agent runs the local checks (ICMP ping, TCP connect, HTTP GET).
4. The agent sends results back over the same HTTPS connection.
5. On state change (UP → DOWN or back), ePulz.io triggers the standard notification — email, Telegram or webhook.

All communication goes through outbound HTTPS on port 443. The same port your router has open for the browser. No forwards, no inbound traffic, no VPN.

Three types of LAN checks

Installation: two variants

For a Linux server with root access (Raspberry Pi, mini PC, VM on the network):

sudo bash <(curl -s https://epulz.io/install-agent.sh) plzag_xxx

The script installs the agent to /opt/epulzio-agent and registers it as a systemd service. It starts on its own after reboot.

For Synology / Unraid / k3s / Docker hosts:

docker run -d --name epulzio-agent --restart unless-stopped \
  --network host \
  -e EPULZIO_AGENT_TOKEN=plzag_xxx \
  epulzio/agent

--network host is important — the agent needs access to the host's local network.

What happens when the agent goes silent

This is a commonly forgotten scenario in custom setups: the agent stops working (network, power outage, kernel panic), the monitor stays at "last_status: up" forever and nobody notices. ePulz.io solves this with separate heartbeat logic:

• Every successful agent request updates last_seen.
• A scheduler checks active agents every minute. If last_seen is older than 5 minutes, an email and Telegram message goes out: "LAN agent X is offline".
• When the agent comes back, you get a back-online notification.

Because of this you'll never end up in the "everything looks green because nothing is being measured" state.

Security

• Token-based auth: the agent authenticates via X-Agent-Token: plzag_…. We only store the SHA-256 hash in the DB; you see the plain token once at creation.
• Revoke anytime from the dashboard. After revoke the agent gets HTTP 401 and stops receiving tasks.
• Per-agent rate limit: 120 requests per minute. Protects the server from looped or buggy agents.
• No credentials directly in the script: the token sits in /opt/epulzio-agent/agent.env with permissions 0600.

When you don't need a LAN agent

If you only monitor public websites, APIs and SSL certificates, the classic ePulz.io cloud probes are enough for you. The LAN agent makes sense when:

• You manage multiple clients and want to offer monitoring of their internal systems.
• You have a hybrid architecture (part cloud, part on-prem) and want a single status board for both.
• You need sub-millisecond RTT measurements on the LAN that you can't get over the internet.

Get started

The LAN agent is available on all plans including the trial. Installation takes three minutes:

1. Create an agent in dashboard → LAN agents.
2. Copy the token (shown only once).
3. Run the installer on a machine in the client's network.
4. Add a LAN monitor via "Add new monitor" and select the type lan_ping, lan_tcp or lan_http.

Try it free

7 days of full access including LAN agents. No card. No auto-renewal.

Create account →