Why "just cache the last result" doesn't actually work
The obvious fix is to remember the last successful check in a local file or the registry, and skip the network call next time. It solves the offline problem, but it doesn't check anything — it's a string sitting on disk that any user with a text editor can flip from false to true. It also doesn't expire cleanly (a copied file works forever on a second machine), and it can't tell you when it was actually last validated. You've traded "no offline support" for "offline support that isn't actually a check" — the file is trusted, not verified.
Why hand-rolling real offline verification is harder than caching a flag
Real offline verification means the app must be able to prove a license is valid without asking a server, using only data that could have come from that server and nothing else. That needs a private/public keypair (the server signs, the app only ever holds the public half), a compact signed payload with the license key, the machine ID, and an expiry the app can check against the clock, a way to make tampering detectable — flip one byte and the signature must fail — and a decision on how long a stale-but-signed result stays trusted before the app is forced to phone home again. None of this is exotic cryptography, but wiring it correctly — verifying the signature before you even parse the payload, checking every claim inside it, choosing a sane expiry window — is exactly the kind of thing that's easy to get subtly wrong once and never notice.
Signed leases: the server signs it, the app only ever verifies it
This is what SublimeKeys' offline verification does. Every activate/verify call returns a lease — a small Ed25519-signed token containing the license key, machine ID, product ID, and an expiry, valid for 7 days. Your app caches it locally and checks the signature against a public key that ships inside your own binary — the private key never leaves our server, so there's nothing on the user's disk that can be edited into a valid lease. A tampered lease fails signature verification immediately, before its contents are even parsed. Once the 7-day window lapses, the next check quietly goes online, gets a fresh lease, and the cycle repeats — so a fully offline machine stays verifiably licensed for up to a week at a time, and a revoked license is caught the next time it reconnects.
How to add it — 3 steps with the official SDKs
What this actually buys you
Your app verifies a license in microseconds with zero network calls on a normal day, keeps working correctly through a week of flight mode or a locked-down corporate network, and still catches a revoked or refunded license within 7 days of the machine reconnecting — without you writing a single line of cryptography yourself, hosting a key management system, or inventing your own token format that someone eventually finds a way to edit.
Who actually needs this
Traveling users
Consultants, field engineers, anyone whose laptop spends real time offline between flights and client sites.
Locked-down corporate networks
Machines behind firewalls that block outbound API calls to anything not explicitly whitelisted.
Python desktop tools
pip install sublimekeys — offline verification built into the official SDK.
Electron apps
npm install sublimekeys — same signed-lease verification, zero native dependencies.
Air-gapped / regulated environments
Machines that are never meant to reach the internet at all, only synced occasionally.
About
Patrick Chen — indie developer behind Sublimearts.io. Built offline verification into SublimeKeys after realizing every desktop app selling to traveling or enterprise users hits the same "no internet" wall eventually.
Did you find this helpful?