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

Demo: https://youtu.be/g6DFO9NFAmE

@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.

Hi everyone,

I’d like to share a new feature that was recently added to Inlay: protection and licensing for HISE expansions.

For anyone who missed the original Inlay introduction post, you can find it here.

That post was mostly focused on host-plugin licensing. This update is about protecting and managing access to expansion content itself.

What this adds

With the new expansion support, HISE expansions can now behave like individually licensed products inside the same host plugin.

An expansion may be physically installed on the user’s machine, but still remain locked until the current user account actually has access to it.

So instead of relying only on download protection or manual serial workflows, the host plugin can verify expansion access dynamically at runtime.

Typical workflow

The general user flow looks like this:

• user installs the host plugin
• user downloads or installs expansions
• the plugin detects installed expansions
• accessible expansions become available immediately
• locked expansions appear as installed but locked
• clicking Unlock opens the browser flow if needed
• after successful activation or purchase, the expansion becomes available

The idea is to make expansion licensing feel integrated into the product instead of feeling like a separate installer or external protection layer.

Why this is useful

This makes a few workflows much easier for HISE developers:

• free player + paid expansions
• instrument marketplaces
• tiered content access
• subscription-based libraries
• downloadable add-on content
• expansion update delivery to licensed users

Another useful aspect is that expansions can be distributed publicly without relying entirely on hidden download links or download managers.

The expansion may already be installed locally, but the plugin still controls whether the current user is actually allowed to use it.

It also allows expansions to stay connected to the same user-based licensing model as the host plugin itself.

Works together with HISE expansion protection

This system is designed to work alongside HISE’s own expansion formats and encrypted expansion support, not replace them.

So you can still use HISE’s protected expansion packaging while adding runtime entitlement checks and user-based access control on top.

User experience goals

One of the main goals was improving UX around protected content.

The expansion flow supports things like:

• browser-based activation instead of entering serials inside the plugin
• self-service unlocking
• multi-device user licensing
• offline-capable access with periodic refresh
• instant unlock after purchase or entitlement change
• installed-but-locked visibility instead of hiding content completely

The aim is to keep the experience flexible for legitimate users while still giving developers meaningful control over access.

Current status

I’m continuing to improve the SDK and integration flow, but the overall direction is now stable enough to share publicly.

If you are building HISE products with expansions, I’d really like to hear what kinds of expansion licensing workflows matter most to you.

Site: https://inlay.cloud
Email: info@inlay.cloud

@resonant thanks! The system is running in GCP right now.