Self-Hosted vs Cloud Licensing: How to Choose

The first serious licensing decision most vendors get wrong isn’t a feature — it’s where the licensing service runs. I’ve watched a team pick a slick managed licensing cloud, ship for a year, and then lose a large government deal because the customer’s security policy forbade any component that phoned home to a third party. I’ve also watched the opposite: a two-person shop insist on self-hosting “for control,” then spend their weekends patching a licensing server instead of building their product. Both mistakes were avoidable with one honest conversation up front.

This post is that conversation. Self-hosted versus cloud licensing, the trade-offs that actually matter, and how to choose without painting yourself into a corner.

Key takeaway: Cloud licensing trades control for someone else running the hard parts; self-hosting trades operational work for total control and the ability to run disconnected. The best position is being able to choose per customer — which is only possible when both editions are the same product.

What each option actually is

A managed cloud licensing service means the vendor runs the issuing and activation backend. You embed an SDK, point it at their service, and they handle the signing keys, the database, uptime, scaling and upgrades. You operate none of it.

Self-hosted (on-premise) licensing means you run that same issuing service inside your own infrastructure — commonly a container image, a Kubernetes deployment, or a Windows/IIS bundle — alongside a database you control. Licenses are signed and activations counted entirely within your network. Nothing leaves unless you decide it does.

Both do the same job — signed licenses, node-locking, seats, entitlements, revocation (all covered in how to license your software). What differs is who carries the operational and security burden, and where the data lives.

The five trade-offs that decide it

1. Control and upgrades

Self-hosting gives you total control: you decide when to upgrade, when to take maintenance windows, how the service is configured, and exactly how it integrates with the rest of your stack. Nobody deprecates an endpoint from under you. The flip side is that everything is now your responsibility — including the upgrades you keep postponing.

A managed cloud inverts this: the vendor ships improvements and security fixes continuously, and you get them for free, but on their schedule, not yours.

2. Air-gap and disconnected operation

This is often the deciding factor, and it’s worth being precise, because two different things get muddled here.

Serving air-gapped customers does not require self-hosting. A signed offline license file verifies against an embedded public key with zero network calls, so a disconnected end user can be licensed perfectly well from a cloud issuing service — the file was signed once, in advance. I covered exactly this mechanism in offline license validation explained.

Running the issuing service itself disconnected is what requires self-hosting. If your deployment sits inside a classified, isolated, or fully air-gapped network where even you can’t reach an external cloud, the signing service has to live in that network. That’s an operator-side constraint, and only self-hosting satisfies it.

3. Compliance and data residency

Regulated industries — defence, healthcare, finance, public sector — frequently have rules about where data may be stored and processed, and whether third parties may hold it. If licensing data (customer identities, activation records, machine fingerprints) must stay inside a specific jurisdiction or inside your own compliance boundary, self-hosting on your own database makes that a configuration fact rather than a contract you have to negotiate and audit. For many enterprise buyers, “we host it ourselves” is the fastest way through their security review.

4. Uptime and reliability

Here the managed cloud usually wins for a small team. A licensing service is on the critical path — if it’s down when a customer activates, they can’t work — and running a highly available, well-monitored, backed-up service is real engineering. A vendor whose entire business is that service will, on average, run it better than you’ll run a side deployment. Self-hosting means you own uptime, backups, and the 2 a.m. page. That’s fine if you have an ops team; it’s a hidden tax if you don’t.

A good design blunts this on both sides with offline grace: because clients cache a short-lived signed lease, a brief issuing-service outage doesn’t lock users out — the cached lease covers the gap. That makes an occasional blip survivable whichever way you host.

5. Operational burden and cost shape

Cloud licensing is typically a subscription — predictable, no infrastructure to run, cost scales with usage. Self-hosting is usually licensed per server (annual or perpetual) and you supply the compute and the ops time. The sticker price is only half the comparison; the other half is your engineers’ hours. For a small team, offloading the ops burden is frequently the cheaper option once you price in the weekends.

A quick decision guide

Reach for managed cloud when:

• You’re a small team who’d rather ship product than run a licensing service.
• Your customers are fine with online activation (with offline files for the ones who aren’t).
• You want continuous updates and someone else owning uptime and key protection.

Reach for self-hosted when:

• You or your customers have data-residency, on-prem, or air-gapped requirements the cloud can’t satisfy.
• Enterprise security reviews demand that no licensing component leave the customer’s (or your) network.
• You need to control upgrade timing and configuration exactly, and you have the ops capacity to own it.

If you’re weighing this against building the whole thing in-house instead, that’s a different axis — I break down the itemised cost of build-versus-buy in build vs buy: software licensing for .NET.

The trap: two products wearing one name

Here’s the mistake that outlasts all the others. Many vendors’ “self-hosted” and “cloud” offerings are different systems — different code, different license formats, different APIs — stapled to one brand. Choose one and you’ve re-integrated if you ever need the other, and any customer who needs both is a support nightmare.

The position you actually want is one product, two deployment modes. Same codebase, same signed license format, same SDK calls, same embedded public key — the only difference is where the issuing service runs. Then moving a single enterprise customer to self-hosted, or migrating your whole account to the cloud, is an operational switch, not a rewrite. Insist on this when you evaluate. It’s the difference between a decision you can revisit and one you’re stuck with.

How Keyright handles it

Keyright is deliberately built as one product in both modes. The identical build runs on our managed cloud or self-hosted inside your own network — Docker, Kubernetes (Helm), or Windows/IIS, including fully air-gapped — against your own database. Because it’s the same signed license format and the same SDKs for .NET, Node, Python and Java on both sides, your integration doesn’t change when your deployment does: the same Validate() and ActivateAsync() calls, the same embedded public key, work either way. Start a customer on the cloud and move them on-prem later without re-issuing a single license, or run everything self-hosted from day one.

Start on the free managed plan to wire up real licensing today — see the plans — or, if on-prem or air-gapped is a hard requirement, read how self-hosting works and talk to us.