> For the complete documentation index, see [llms.txt](https://docs.licensespring.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.licensespring.com/floating-server/faq.md).

# FAQ

<details>

<summary>What Does “Max Activations” Field Mean in Terms of Floating Licenses?</summary>

When you install floating licenses on the Floating server, Max activations field determines on how many servers you are able to install that same license on.

</details>

<details>

<summary>How Do I Control Which Device Is Allowed to Connect to the Floating Server?</summary>

Floating server is designed to be deployed in a secure internal network (e.g. with VPN). Therefore, each user should be a trusted user. If you still want to authenticate users, you can setup an authentication proxy for Floating server.

</details>

<details>

<summary>When Configuring Licenses for Floating Server, Why Do I Need to Enter Both Product and License Key?</summary>

Floating server can be configured with multiple licenses at the same time. Setting the product allows us to determine to which product that license corresponds to.

</details>

<details>

<summary>Configured Floating Server With One License. How Do I Add a Different License for the Same Product?</summary>

In **Floating Server Version 1** of our platform, it is not possible to add multiple licenses for the same product. To change a license, you must first remove the existing license before adding a new one. However, in **Floating Server Version 2**, you can add multiple licenses for the same product, allowing greater flexibility in managing your deployments.

</details>

<details>

<summary>Floating Server Requires API and Shared Keys. Is It Safe to Share Them With My Customers?</summary>

Those keys only give you access to the License API, and not to the Management API. License API is a very limited subset of LicenseSpring API, so it is safe to share those keys.

</details>

<details>

<summary>Can the on-prem server run headless (command-line only, no UI)?</summary>

Yes, the on-prem server can be run headless. After deployment using any of the available options, you can communicate with the server through command-line scripts. These scripts can be generated using our tool at LicenseSpring API Documentation. Every server functionality can be executed with corresponding command-line arguments.

</details>

<details>

<summary>How does the on-prem license server node-lock to the system?</summary>

When a license is activated through the on-prem server, the server uses the machine identifier of the operating system to generate a unique hardware ID, binding the license to that specific system. In Docker setups, the machine ID is derived from the host machine’s ID, and the license is tied to this hardware ID for future operations.

</details>

<details>

<summary>Is there a better implementation for node-locking in Docker setups on systems without internet access?</summary>

Yes, node-locking in Docker containers can be effectively implemented if the Docker volumes remain secure and unmodified. Our recommendation is to secure the Redis instance’s Docker volume, as it plays a key role in the node-locking mechanism.

For systems without internet access, we provide offline or air-gapped licenses, which do not require internet connectivity. Alternatively, Physical Hardware Keys (dongles) can be used to enforce node-locking, requiring their presence for license validation.

</details>

<details>

<summary>Can VM detection handle WSL detection from inside a WSL Linux instance?</summary>

No, currently, our floating server does not support detection of WSL (Windows Subsystem for Linux) instances.

</details>

<details>

<summary>How is the hardware ID determined by default?</summary>

The hardware ID is generated using the machine identifier from the underlying operating system or host machine. This unique ID is used to bind licenses to the system where the floating server is running.

</details>

<details>

<summary>How can I prevent server cloning when using the executable in air-gapped or virtualized deployments?</summary>

To protect against server cloning, the hardware ID is used to tie the server to a specific machine. LicenseSpring also supports Yubikey 5 hardware-based security for additional protection. If your environment doesn't allow external hardware (such as in fully virtualized systems), it's recommended to use expiration dates on licenses as an alternative safeguard. LicenseSpring is exploring software-only server cloning prevention protocols that may be available in the future.

</details>

<details>

<summary>Is the floating license server's database (Badger-DB) running as a separate process in the executable method?</summary>

No, the Badger-DB database is integrated directly into the floating server executable (floating-server.exe). There is no separate process to manage. The database runs within the executable, making it easier to monitor and control without extra overhead.

</details>

<details>

<summary><strong>How can I check if my license is still valid?</strong></summary>

Retrieve the license validity status through the SDK or License API by checking the `is_expired` field. See [License Check](/license-api/license-check.md).

</details>

<details>

<summary>Does LicenseSpring support role-based licensing (e.g., different permissions for standard users and admin users)?</summary>

LicenseSpring does not provide a dedicated **“role” field** within a license. However, role-based access can be implemented using existing licensing concepts.

Typically, this is achieved by creating **different license policies for the same product** (for example, a *Standard* policy and an *Admin* policy) and configuring your application to enable permissions based on the policy associated with the license. Policies can also include different **feature sets**, allowing you to define which functionality is available for each license type.

In practice, the “role” is represented by the **license policy and/or enabled features**, while your application enforces the corresponding permissions.

For more details:

* License policies: <https://docs.licensespring.com/product-configuration/license-policies>
* Features: <https://docs.licensespring.com/license-entitlements/features>

</details>

<details>

<summary>What happens to active floating sessions if the seat count is reduced below current usage?</summary>

Reducing the number of floating seats below the current number of active sessions does not immediately evict the excess sessions. Existing sessions remain active until they either expire based on the **Floating Timeout** value, or until the next license check (or feature check for floating features) is performed. At that point, sessions that exceed the new seat count will no longer be renewed.

</details>

<details>

<summary>What happens to active floating sessions when a license is disabled?</summary>

Active floating sessions are not terminated immediately when a license is disabled. Existing sessions continue to run until the next heartbeat is sent  at that point the server returns a disabled status and the session is ended.

This means your application can handle the transition gracefully by listening for the disabled status on the next heartbeat response and messaging the user accordingly, rather than experiencing an abrupt termination.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.licensespring.com/floating-server/faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
