UpsNode
Uptime monitoring from 5 global regions simultaneously
Start new thread

UpsNode - Uptime monitoring from 5 global regions simultaneously

by•
Monitor your websites, APIs and servers from 5 global locations simultaneously. Instant alerts via Email, Slack and Discord. Includes HTTP, SSL, DNS, Ping and Domain monitoring with 90-day uptime history.

Add a comment

Replies

Best
Hunter
📌
Hey Product Hunt! 👋 I built UpsNode because I kept getting "your site is up" alerts while users in different countries couldn't actually reach it. Single-location monitors are basically blind to regional outages. So I built a distributed checker across 5 regions. The interesting part: an incident only opens if the majority of agents report down so one flaky node in Frankfurt doesn't wake you up at 3am. Stack: Go + gRPC on the backend, Next.js on the front. Agents connect via mTLS no API tokens, just certificates. Built this solo over the past few months. Would love to hear what you think!
Hunter



How we approached security in UpsNode's server monitoring agent

One of the hardest parts of building a server monitoring product is the trust model: you're asking users to run a binary on their production infrastructure. Here's exactly what we did to make that trustworthy.

Mutual TLS (mTLS) for agent authentication Every agent gets a unique client certificate signed by our internal CA. The central gRPC server only accepts connections from agents presenting a valid cert. This means even if someone intercepts the install token, they can't impersonate a legitimate agent — the certificate fingerprint is verified on both sides.

One-time install tokens The install token is consumed the moment the agent requests its certificate. A replayed token returns nothing. The token is never stored after use.

No inbound ports required The agent initiates an outbound gRPC connection to our server. Users don't open any ports on their firewall. This was a deliberate design choice — the attack surface on the customer's side is zero.

Certificate fingerprint binding When a certificate is issued, its SHA-256 fingerprint is stored alongside the agent record. If an agent presents a cert with a mismatched fingerprint, the connection is rejected immediately with PermissionDenied.

Automatic agent termination on monitor deletion When a user deletes a server monitor, we send a server_terminate gRPC command. If the agent is offline at that moment, the next reconnect attempt is rejected — the deleted fingerprint is no longer in our DB, so the agent receives PermissionDenied and calls os.Exit(0). No orphaned processes.

Auth tokens in HttpOnly cookies only No JWTs in localStorage. The token lives in an HttpOnly, Secure, SameSite cookie. The frontend never touches it — our Next.js proxy reads the cookie server-side and forwards it as a Bearer header.

Status pages are noindexed and robots.txt protected Status pages are intentionally not crawlable — double protection via <meta name="robots" content="noindex,nofollow"> and Disallow in robots.txt.

Rate limiting on all endpoints 120 req/min globally, 10 req/5min on auth routes, enforced via Redis sliding window.

The agent itself only collects CPU, RAM, disk, and network I/O via gopsutil — it reads from /proc and makes no outbound connections other than the gRPC stream to our server. No shell commands, no file access outside /proc and /sys.