Containers and Virtual Machines

Containers and virtual machines can make device fingerprinting unreliable, so fingerprint-based node-locked licensing is a poor fit for apps deployed in them. Cryptlex recommends two approaches instead: floating licenses, or node-locked licenses with crypto binding. Both need an internet connection in the hosted setup; for offline environments, use floating licenses served by an on-premise LexFloatServer.

Why device fingerprinting fails

Containers

When an app runs inside a container, whether Docker, Kubernetes, or another runtime, it has very little access to the host hardware details, so it is difficult to generate a quality device fingerprint. If you use fingerprint-based node-locked licenses, your customers can use the same license key across different container instances running on the same or different devices.

Virtual machines

Virtual machines expose virtualized hardware, and a VM can be cloned, which can result in multiple machines with the same device fingerprint. LexActivator detects virtual machines, and the allow VM activations property lets you block activations inside VMs entirely if you prefer.

Node-locked licenses with crypto binding

For containers and VMs with internet access, the recommended approach is to keep using node-locked licenses and enable crypto binding, by setting the cryptoBindingEnabled property on the license template or the individual license. With crypto binding, the activation is bound cryptographically instead of relying on the device fingerprint, which reliably prevents a license key from being shared across container instances or cloned VMs, as long as an internet connection is available. Crypto binding is supported on Windows and Linux.

For containers, persist the activation data across container restarts by mounting a volume and pointing LexActivator's SetDataDirectory() function at it.

Without a mounted volume, every new container starts with no activation data, so it activates again and consumes another activation from the license. A deployment that recreates containers regularly will exhaust its allowed activations, which is the most common way container licensing goes wrong.

Floating licenses

Floating licenses are also a good option for containers and VMs, since seats are leased and freed dynamically instead of being tied to a device fingerprint:

Hosted floating: for deployments with internet access, use the hosted-floating license type, with Cryptlex's servers acting as the license server. Set the leasing strategy to per-instance to consume a license activation for every running instance of your app, irrespective of whether the device fingerprint is the same or different.
On-premise floating: for containers or VMs running in air-gapped, secured, or otherwise protected networks with no internet access, use the on-premise-floating license type with LexFloatServer running inside their network.

Floating licenses are the better choice when instances are short-lived or created automatically, such as Kubernetes pods or autoscaled workloads. A leased seat returns to the pool on its own, so ephemeral instances do not accumulate activations the way crypto binding does.

For help handling offline licensing inside containers or virtual machines, reach out to our support channel.

Timed Trials Overview

Last updated: 8/5/2026