Inlay — licensing, activation and update delivery for HISE plugins
-
Hi everyone,
I'm Alexey, I’d like to introduce Inlay — a licensing platform built specifically for HISE-based audio plugins.
Site: https://inlay.cloud
Demo video: https://youtu.be/g6DFO9NFAmE
The goal is to give HISE developers an advanced licensing approach that is still easy to enable in a HISE project, without having to build a custom licensing stack or go deeper into C++ / JUCE-side work just to get proper activation and license control.
What Inlay is about
Inlay is built around the idea of user-bound licenses.
That is different not only from shareable serials or download-only protection, but also from strictly device-bound approaches that may break the customer experience when the user upgrades or replaces a machine.
The idea here is that access belongs to the real user, while still allowing use on multiple personal devices within reasonable limits, so the license can follow the customer without enabling uncontrolled spread.
With Inlay, a plugin can be activated through a user account, used across multiple personal devices within defined limits, and continue working offline using cryptographic access tokens that expire after some time and are valid only on the activated device. At the same time, it still needs to reconnect to the license server in the background from time to time, so revoked access can actually be revoked, update notifications can still be delivered, and subscription-based access can be enforced properly.
At the moment, Inlay is HISE-first, but support for other frameworks is also in the plans.
Main features
1. User-based activation
Instead of typing serial numbers directly inside the plugin, the activation flow is browser-based.
The user signs in through the browser, and the plugin receives access associated with that user account — as long as the email matches the one used for the purchase or the license redemption flow. This makes the flow cleaner for legitimate users and shifts licensing away from simple code sharing.
2. User-bound licensing with controlled multi-device use
The main model is not “one machine = one license forever”.
A user can use the plugin on multiple devices, but within a defined limit that helps prevent uncontrolled spreading. So the system is meant to be flexible for normal use, while still giving the developer meaningful control.
3. Offline-capable access with background revalidation
After activation, the plugin can continue working offline using local cryptographic access tokens.
But this is not a forever-offline model. The plugin still reconnects in the background periodically, which is important for several reasons: revoked licenses should not remain active indefinitely, users should still be able to receive update notifications, and the same mechanism also makes subscription-based monetisation practical.
4. Runtime plugin locking / unlocking
The HISE module can keep the plugin locked until valid access is present, then unlock it after activation.
So the protection is part of the runtime access model, not just something happening at download time.
5. Device management during activation
If the device limit is reached, the user can remove an old device during activation instead of having to go through manual support.
The removed device is then blocked for that user/plugin pair for some period, which helps prevent uncontrolled re-use while still keeping the flow self-service.
6. Automated license issuing
Inlay supports automated license creation after purchase through multiple payment and sales flows, and that number is growing.
The point is that license issuing should happen automatically, without developers having to glue together a custom fulfillment system.
7. One-time key redemption that becomes a user license
Inlay also supports license key redemption.
But the important part is that redeeming a one-time key is not the end state. It creates a license bound to the user’s email, so after that the user can continue signing in with that email on future activations or on other allowed devices.
8. Update notifications inside the plugin
Inlay can notify users inside the plugin when a newer version is available and provide an update link.
So it is not only about licensing, but also about keeping licensed users connected to current versions in a lightweight way.
9. Web console for developers
There is a web console for managing products, licenses, webhooks, limits, update metadata, and some product usage insights.
The idea is to keep the whole workflow practical for HISE developers and small plugin teams, rather than turning it into a large back-office system.
Why I built it
I built Inlay because I wanted HISE developers to have access to a more advanced licensing model without having to build everything themselves.
A lot of existing approaches are either too basic, too rigid, or require a lot of custom engineering around activation, delivery, and device handling.
The goal with Inlay was to make a stronger licensing approach feel easy to enable in a HISE project, without pushing developers into a large custom backend effort or deeper C++ / JUCE work just to ship a protected product.
Who it may be useful for
Inlay may be relevant if you are building HISE products and want:
-
user-based activation
-
controlled multi-device access
-
offline-capable licensing with periodic revalidation
-
self-service device management
-
automated license issuing
-
in-plugin update notifications
-
less custom licensing/backend work
Current focus
Right now the product is focused on HISE and that is the main priority.
That said, the broader direction is not limited to HISE forever — support for other frameworks is also planned.
Feedback welcome
I’m sharing this here because HISE developers are exactly the people I’m building this for.
If you are working on HISE products, I’d really like to hear whether this approach feels useful, what kinds of licensing flows matter most to you, and what would make adoption easier in a real project.
Site: https://inlay.cloud
-
-
@alexey_inlay Good stuff brother!
-
@trillbilly hey, thanks — really appreciate it.
-
@alexey_inlay congrats! Which server is this system using in the background? AWS elastic?
-
@alexey_inlay I'd like to know a bit about who is behind the service?
-
@David-Healey Sure — at the moment I’m the main developer behind it, with a few assistants helping me on different parts.
I’m a software developer by background, and the original idea actually came from a friend of mine who is musician builds instruments with HISE. Through that, I got interested in the licensing side of things and started building Inlay around those problems.
So it didn’t start as a generic SaaS idea — it came specifically from the HISE/plugin world and the practical issues around licensing, activation, device management, and update delivery.
Right now it’s still an independent product, and I’m the main person behind it.
-
@resonant thanks! The system is running in GCP right now.
