How an Offline License Check Actually Works

The recovery runbook says to restore the monitoring stack inside an isolated network. MongoDB comes back. The application starts. Then the licence screen waits for a vendor endpoint the datacentre is not allowed to reach.

That is a bad moment to discover that "self-hosted" still has an external runtime dependency.

A network-backed licence check can be a reasonable commercial design, but its failure mode belongs in the architecture review, not in the recovery window.

Three costs a network-backed licence check can introduce

An outbound dependency. If the activation server is down, or your firewall policy changed, or the vendor was acquired and moved endpoints, your install degrades. You now have a production dependency on a company's uptime, for software running entirely on your own hardware.

Potential usage reporting. A licence request may include an installation identifier, host count, or fingerprint. The exact payload varies by vendor, so inspect the documentation and the traffic rather than assuming either way.

A kill switch. Whatever the contract says, an install that must ask permission can be refused permission.

For an air-gapped site, all three are disqualifying. For everyone else they are an ambient risk you have quietly accepted.

How RootTrace does it instead

A RootTrace licence is a signed token. Specifically it is a JWT signed with ES256, and the public half of the signing key is compiled into the server image.

That is the licence-verification mechanism. Your install verifies the signature locally against a key it already has. The verifier makes no network request.

The consequences are worth spelling out, because they are the actual product:

• No activation server, so there is no endpoint to be down and no endpoint to block.
• No periodic ping, so a licence that verified at boot does not stop verifying because the network changed.
• No usage reporting through licence verification, so that code path sends us no host count, hostnames, or installation identifier.
• Licence verification works air-gapped by default, not as a special mode you request. There is no offline verification variant because there is no online one. RootTrace does ship a separate air-gapped install path, with its own bundle and a profile that blocks image pulls, remote model calls, and the vendor email relay, but that exists for images, models, and update channels. The licence never needed it.

The first product moment needs no permission

Here is the design decision I find most telling, and it is one line of intent in the licence module: an install with no licence at all does not refuse to start. It runs the free tier.

Think about what the alternative looks like. Software that fails closed on a missing licence turns every certificate hiccup, every misplaced config file, every restore-from-backup into an outage. And it makes evaluating the product a negotiation: you cannot try it until somebody sends you something.

Falling back to the free tier removes both problems at once. docker pull, bring the stack up, and you are running. Nothing to request from us, nothing to mint, nothing to paste. When you outgrow it you buy a token and drop it in, and you will outgrow it on retention long before you outgrow it on hosts: the free tier keeps one day.

For an evaluator, that changes the first interaction with RootTrace. The first thing you do is inspect your own running install, not fill out a form and wait for access. For an operator restoring a backup, a missing commercial token reduces entitlements instead of preventing the server from starting.

What this costs us

Honesty requires naming the tradeoff, because there is one and it is not small.

We do not know who is running RootTrace. No call-home means no install count, no version distribution, no way to email the operators of an affected version when we ship a security fix. We find out about our own adoption the way you would: somebody tells us.

Revocation is weak. A signed token with a term is valid until that term ends. We cannot reach into an install and switch it off, which is the point, but it also means the enforcement story is "renewals" rather than "control."

Those are real costs and we chose them deliberately. If you are evaluating self-hosted software, that tradeoff is worth looking for explicitly. A vendor who has retained the ability to switch your install off has told you something about where they think the boundary sits.

How to check any vendor's claim

"Self-hosted" is a word, not a guarantee. Three ways to find out what it means in practice:

1. Block egress and restart. Bring the stack up on a host with no route out. If it starts and stays healthy, the claim holds. If it starts and degrades in an hour, there is a check you were not told about.
2. Watch the connections. ss -tnp or a packet capture on a running install tells you exactly who it talks to. Compare that against the docs.
3. Read the licence flow. Ask whether verification is a signature check or a network call. Those are different architectures and only one survives an air-gap.

You can run all three against RootTrace, and you should. The reason to publish how the mechanism works is so the claim is checkable rather than something you take on trust.

Prove the boundary with egress blocked

The image is public and the free tier needs no vendor account, no licence key, and no contact with us at all. A local RootTrace user is still created during bootstrap:

docker pull public.ecr.aws/byteaffinity/roottrace/server:latest

The pull alone starts nothing. The quickstart is one paste-able block that writes the Compose file and generates your bootstrap token, then docker compose up -d.

Then do the interesting part on a host: block egress and restart the stack. The license result should remain the same because verification is local.