If an Electron app checks its license in renderer code, a customer can inspect the same code that makes the allow-or-block decision. That does not make the app impossible to protect, but it puts an important decision in the easiest process to inspect and modify.
For a paid Electron app, I prefer this boundary:
- validate in the main process;
- keep
contextIsolationenabled; - expose only the minimum license status through a narrow preload/IPC API;
- scope every validation request to the product ID;
- test the packaged build, not only development mode.
The core integration can remain straightforward:
import { app } from 'electron';
import { PermitCoreClient } from '@permitcore/permitcore';
const client = new PermitCoreClient('https://api.permitcore.dev');
const result = await client.validate(
licenseKey,
app.getVersion(),
productId
);
if (!result.isValid) app.quit();
I wrote a complete walkthrough covering installation, activation, product-scoped validation, offline grace, revoked-key testing, and the main-process/renderer boundary.
It also covers the step that licensing tutorials often omit: selling the application. PermitCore includes a branded Store, so the same product can have a checkout that uses your Stripe account, creates the license after payment, and delivers it to the customer. PermitCore takes 0% sales commission.
The intended workflow is create → implement → sell, without maintaining a separate storefront and webhook bridge just to issue keys.
Full walkthrough
How to license and sell an Electron app
If you ship Electron applications, I would be interested to hear how you currently separate licensing logic from renderer code and how you handle offline customers. 🙂🚀
Top comments (0)