No Internet Required: Air-Gapped Monitoring for Valkey and Redis

Let's face it: most monitoring tools quietly assume the internet is always there.

They pull dashboards from a CDN. They validate a license against some endpoint on startup. They ship a little telemetry "to improve the product." None of it is malicious-it's just how modern SaaS-shaped software gets built, and for most teams it's completely fine.

Then there's the other kind of team: the ones running Valkey and Redis on a network with no route to the outside world, holding the most sensitive data, facing the strictest auditors-and until recently, they couldn't run our product at all.

That changed in BetterDB Monitor 0.28.0. It now runs fully air-gapped: paid tiers, every feature, zero outbound network. This post is about why that matters, how we actually built it, and-because I'd rather you trust us than be impressed by us-where the honest edges are.

What "air-gapped" actually means

Air-gapped isn't the same as "on-prem" or "runs in Docker," even though the words get used interchangeably.

Plenty of tools install on your own servers and still open a connection the moment they boot-a license check here, a version ping there, an analytics beacon you didn't notice. On a normal network you'll never see it. On an air-gapped network, that single outbound request is the difference between "compliant" and "get this off my segment."

Air-gapped means the machine has no path to the internet, by design. Not firewalled. Not behind a proxy. Genuinely disconnected. So the bar isn't "works offline most of the time." The bar is: nothing leaves the box, ever, and the software still runs at full capability. That's a higher bar than it sounds, and it's the one we built to.

The problem hiding inside every "just check the license" call

Here's the part nobody likes to say out loud: the license check is the hard part.

Any tool can render a dashboard without the internet. The trouble is that commercial software needs to know whether you're entitled to the features you're using-and the lazy way to answer that question is to ask a server. GET /am-i-allowed-to-run. Easy to build. Impossible to run air-gapped.

So the real engineering question was never "how do we draw charts offline." It was: how does a completely disconnected machine prove it's allowed to run Pro or Enterprise, without ever asking anyone?

Our answer is cryptography, not connectivity.

How it works: a license you can verify, not a server you have to reach

When you buy a paid license, you download a signed offline license token from your account page-a single .jwt file. You move it onto the air-gapped host however your environment allows: a USB transfer, an internal artifact repo, a Kubernetes secret, a mounted file. However your security team likes to move bytes across the gap.

The monitor verifies that token locally, against public keys baked into the image itself. It's a standard RS256 signature check. If the signature is valid and the token isn't expired, you're entitled. If it's been tampered with by so much as one byte, it's rejected. No trust in anything except math and a public key we shipped you.

Activate it whichever way fits your deployment:

• In the UI: Settings → License → "Air-gapped environment? Activate an offline license"-paste the token or upload the .jwt.
• In config: BETTERDB_OFFLINE_LICENSE for the token string, or BETTERDB_OFFLINE_LICENSE_FILE to point at a mounted secret.

And here's the part that matters most for the auditors: when the monitor is running purely from an offline token-no online license key configured-it flips into air-gapped mode and turns telemetry and phone-home off automatically. Not "off by default, hope you didn't re-enable it." Off, enforced, at the earliest possible point in startup. No usage events. No heartbeat. No update pings. We don't even send startup errors-and we test for zero outbound on every release.

The whole thing ships as a single self-contained Docker image. The frontend is bundled in. No external CDN, no web-font request, no script pulled from a third party at runtime. Pull the image, load it into your internal registry, and everything the product needs is already inside.

The honest edges

I'd rather tell you the trade-offs than have you find them in production. So:

Offline tokens aren't perpetual-even if your license is. For security reasons, an offline token is valid for at most 366 days. A token that never expired would be a token that could never be revoked if it leaked. So even on a perpetual license, you'll re-download a fresh token roughly once a year. The monitor warns you 30 days out and again at 7 days, so it won't sneak up on you-but put a calendar reminder on it anyway. If a token does lapse, the monitor drops to the community tier: it keeps running, it just stops unlocking your paid tier until you drop in a new one.

Offline licenses are floating, not seat-locked. The token carries an instance limit, and we show it to you, but in air-gapped mode we don't hard-enforce it-there's no license server to count against, and we're not going to pretend there is. It's an honor-system number backed by your agreement, not a hard gate. If you need strictly enforced seat caps, talk to us; that's a different conversation, and I'd rather have it honestly.

You'll do a one-time volume chown. The container runs as a non-root user, so if you mount a fresh data volume for license persistence, you'll chown it once so the monitor can write its state. It's one command, it's in the docs, and then you never think about it again-but I'd rather you hear it from me than from an EACCES at 2 AM.

We didn't love adding any of these, but each one is the natural consequence of doing offline licensing correctly. A token has to expire, or it can never be revoked if it leaks. A disconnected box has no license server to enforce seats against. We'd rather name those constraints up front and let you decide how they fit your environment than paper over them and let you find out later.

Who this is actually for

If your Valkey or Redis instances sit on a network with real internet access, none of this changes your day-you get the outage-resilience upgrade for free and carry on.

But if you're running inside:

• a regulated financial environment where every outbound flow is logged, reviewed, and defended,
• a government or defense network with a genuine air gap,
• a healthcare or critical-infrastructure system under HIPAA, PCI-DSS, or the equivalent, or
• any classified, isolated, or high-security segment where SaaS is simply not on the menu-

then you already knew that "just use the cloud version" was never an option. You've been stuck choosing between deep observability and your security posture. You shouldn't have to. Your most sensitive databases deserve better monitoring than your public-facing ones, not worse-and certainly not none.

That's the whole point. The teams with the strictest requirements are usually the teams with the highest stakes. They persist the most sensitive slowlogs, the most audit-relevant ACL trails, the incidents that actually make the news. Locking real observability behind an internet connection they're not allowed to have has always been backwards.

Now they can debug an incident that happened three hours ago on a Valkey cluster that has never once talked to the outside world-with the full product, and nothing leaving the box.

Getting started

Air-gapped support is available in BetterDB Monitor 0.28.0 and later. Pull the image on a connected machine, then load it into your internal registry:

docker pull betterdb/monitor:latest

Download your offline license token from your account page, move it across the gap, and activate it via Settings → License or the BETTERDB_OFFLINE_LICENSE_FILE config. Confirm you're fully offline with GET /license/status-it reports airGapped: true and the token's offlineExpiresAt so you can see exactly what's running.

Full instructions are in the Offline & Air-Gapped Licenses guide. And if your environment has a constraint I haven't thought of, email me directly at kristiyan@betterdb.com-I read those, and the last few features on our roadmap came straight out of conversations exactly like that one.