Why We Built the Open Checker Network

Every monitoring service runs probes from cloud regions — AWS us-east-1, GCP europe-west1, and so on. It works, but there’s a fundamental blind spot: your users don’t access your services from cloud data centers.

The problem with cloud-only monitoring

When you monitor from AWS, you’re testing the path between two well-connected data centers. You miss:

• Last-mile issues — ISP problems, regional routing changes, DNS resolver differences
• CDN behavior — edge cache misses that only affect certain geographies
• Corporate network issues — firewall rules, proxy interference, MTU problems

We’ve seen cases where monitoring shows 100% uptime from cloud probes while real users experience 30-second page loads because of a BGP routing change that only affected residential ISPs.

Our approach: bring your own checkers

Oack’s Open Checker Network lets you deploy lightweight checker agents on your own infrastructure. The checker process typically consumes 16–20 MB of RSS memory (depending on workload) and ships as pre-built binaries for Linux, FreeBSD, and macOS — plus Homebrew and Docker for easy installation.

	Linux	FreeBSD	macOS
Binary	amd64 / arm64	amd64 / arm64	Intel / Apple Silicon
Package (deb/rpm)	amd64 / arm64	—	—
Docker	amd64 / arm64	—	via Docker Desktop
Homebrew	✓	—	✓

The checker is written in Go, so adding support for a new platform or distribution method is straightforward — if the Go compiler targets it, we can ship it. Need a FreeBSD package, an Alpine APK, or a build for an architecture not listed above? Let us know.

Run it wherever your users are:

• On-premise servers behind your corporate firewall
• Edge locations close to your customers
• Developer machines for local testing
• Raspberry Pis in branch offices (yes, really)

Each checker registers with the Oack gateway, receives probe assignments, and reports results back. You get monitoring that reflects what your actual users experience.

How it works

docker run -d \
  --name oack-checker \
  -e OACK_GW=https://netcheckers-gw.oack.io \
  -e OACK_TOKEN=your-token \
  ghcr.io/oack-io/checker:latest

That’s it. The checker appears in your dashboard within seconds, and you can assign it to any probe.

Security by design

Deploying an agent inside your network raises an obvious question: who gets to use it, and how is the communication secured?

Launch mode: dedicated vs. shared

Every network tester requires a mandatory launch mode flag:

• Dedicated — the checker is private to your account. Only teams you explicitly approve can assign probe tasks to it. No one else on the platform can discover or use this checker without your permission.
• Shared — the checker joins the public pool alongside Oack’s own infrastructure. Any user on the platform can assign monitors to it, just like any other shared checker. This is the mode to pick if you want to contribute capacity to the community.

You choose the mode at startup, so there is no ambiguity about who has access.

Authentication: OAuth Device Flow (RFC 8628)

The checker is a headless process — it has no browser and no way to show a login page. So how does it authenticate with your Oack account?

We use the OAuth 2.0 Device Authorization Grant, the same protocol your smart TV or CLI tool uses when it asks you to “visit this URL and enter the code.” Here’s what happens when you launch a checker for the first time:

1. The checker requests a device code. It calls the Oack API, which returns a short user code (e.g. ABCD-1234) and a verification URL.
2. You see the code in your terminal. The checker prints something like: “Visit https://app.oack.io/device and enter code ABCD-1234” — or gives you a direct link that already has the code filled in.
3. You open the link in any browser. Sign in with your Google or GitHub account (the same OAuth providers you use for the Oack dashboard). The browser session is completely separate from the checker — it can be on a different machine, your phone, anything.
4. You approve, the checker gets a token. While you’re in the browser, the checker polls the API in the background. The moment you approve, it receives an access token over the existing HTTPS connection and persists it locally. Future restarts reuse the stored token automatically.

This flow is secure by design:

• No secrets baked into the binary or container image. There’s no API key to leak in a Dockerfile, no shared secret to rotate. The token is issued after you authenticate interactively.
• Short-lived codes, long-lived tokens. The user code expires in 15 minutes — if nobody approves it, it becomes useless. The access token the checker receives is long-lived, so you only go through the device flow once per installation.
• Scoped to your identity. The token ties the checker to your Oack account through your existing OAuth provider. Revoking access is as simple as removing the checker from your dashboard — the token is invalidated immediately.
• No credentials on the wire. The checker never sees your Google or GitHub password. OAuth means it only receives a scoped Oack token after the provider confirms your identity.

First launch only. The device flow runs once. After that, the checker stores its token and reconnects silently on restart. If the token is ever revoked or expires, the checker will prompt the device flow again.

Zero inbound firewall rules

Network testers use an outbound-only communication model. The checker opens a standard HTTPS connection to the Oack API and upgrades it to a WebSocket. All probe assignments and result reporting flow over this single outbound connection.

Because the checker initiates the TCP handshake from inside your network, you don’t need to open any inbound firewall rules or expose any ports. There is no listening socket, no publicly reachable endpoint, and no need to punch holes in your perimeter. Drop a checker behind a corporate firewall, a NAT gateway, or a strict egress-only security group — it just works.

What’s next

We’re working on a public checker network — opt-in community checkers that expand coverage to regions we don’t have infrastructure in. If you’re interested in hosting a community checker, reach out.