DEV Community: PermitCore

Open Core in a Public Repo: Gate Paid Features With License Keys, Not Secrecy

PermitCore — Wed, 11 Nov 2026 09:34:42 +0000

Your repository is public. Anyone can read the paid modules, fork them, and build them. So what actually separates the Community edition from the paid one?

In open core and Fair Source projects the answer is not code secrecy. It is the license key: a signed entitlement that tells one self-hosted installation which paid features it is allowed to use. This post walks through how to design that boundary so it stays fair to operators and practical for you.

Open core vs Fair Source in one paragraph

Classic open core keeps the core under an open source license and puts commercial modules in a separate directory (often ee/) with their own terms. Fair Source goes a step further: the commercial code is readable, but the license limits certain uses of current versions and converts to a permissive license later. Keygen moved to FCL, and Directus announced an FCL-derived license for v12 together with registration keys for paid users.

Quick comparison (high level, not legal advice, always read the exact terms you ship):

Model	What it does
Separate `ee/` terms	Core and commercial modules carry different licenses; the repo makes the boundary obvious
FSL	Limits competing use; becomes Apache 2.0 or MIT after two years
FCL	Limits competing use, protects license-key functionality, future license per chosen variant
ELv2	Restricts offering as a managed service, bypassing key functionality, removing notices

The key is the line, and that is fine

A self-hosted operator controls the binary. They can patch it. Accept that, and design for the honest majority:

Sign the proof. A modified config file should never be able to grant access in the unmodified product.
Check where the paid operation runs, on the server side, not only in the UI.
No mandatory telemetry, no remote kill switch. Operators of self-hosted software care a lot about this.
Explain state clearly. If a feature is unavailable, say why and how to restore it. Never lock people out of their own data.

Model features as entitlements, not editions

Use stable entitlement identifiers instead of hard-coding "is this Pro?":

Community: read and edit data (no key needed)
Pro: adds exports
Enterprise: adds sso

Each paid operation checks its own entitlement. If the proof is invalid or scoped to another product, the paid operation is denied and Community keeps working.

using PermitCore;

static async Task<(bool Exports, bool Sso)> CheckFeatures(
    PermitCoreClient client, Guid productId)
{
    var key = Environment.GetEnvironmentVariable("PERMITCORE_LICENSE_KEY");
    if (string.IsNullOrWhiteSpace(key)) return (false, false);
    var result = await client.ValidateAsync(key, expectedProductId: productId);
    return (result.IsValid && result.HasFeature("exports"),
            result.IsValid && result.HasFeature("sso"));
}

Air-gapped and flaky-network installs

Self-hosted often means "no internet". Two patterns cover most cases:

Air-gapped: ship a signed token file, ship trusted public keys through your release channel, and validate offline (signature, deadline, device, expected product).
Normally connected: configure an offline grace period so signed cached proof keeps working through a network outage.

static bool AcceptOffline(PermitCoreClient client, string deviceId, Guid productId)
{
    var path = Environment.GetEnvironmentVariable("PERMITCORE_OFFLINE_FILE");
    if (string.IsNullOrWhiteSpace(path) || !File.Exists(path)) return false;
    return client.ActivateOffline(File.ReadAllText(path).Trim(), deviceId, productId).IsValid;
}

Let customers keep what they paid for

If your terms promise a perpetual fallback, keep that decision separate from license validation: compare the chosen build's release date with a trusted maintenance end date.

static bool CanUseRelease(LicenseResult entitlement, DateTime releasedAtUtc)
    => entitlement.IsValid
       && (entitlement.MaintenanceExpiresAt is not DateTime end || releasedAtUtc <= end);

Docker, Kubernetes and CI

Never bake the key into an image layer.

Docker: docker run --env PERMITCORE_LICENSE_KEY ... (inherits from the exported variable)
Kubernetes: env.valueFrom.secretKeyRef on the workload
CI: map the protected secret to the same variable for integration tests
Offline installs: mount the token file read-only and point PERMITCORE_OFFLINE_FILE at it

Keep keys and token files out of build logs and public CI output.

Wrapping up

The examples use the PermitCore .NET SDK, which handles key issuing, entitlements and online/offline validation. The full guide, with links to the offline, grace-period and key-rotation deep dives, is on our blog: Open Core and Fair Source: gating paid features with license keys.

If you ship open core or Fair Source: where do you draw the line between Community and paid, and do you check entitlements in the UI, the server, or both? 🙂

Selling Your Game Outside Steam: Keys, Downloads and a Direct Sale That Delivers Itself

PermitCore — Mon, 09 Nov 2026 09:36:38 +0000

Originally published on the PermitCore blog.

Selling your game directly, next to or instead of a big store, starts with one question: what exactly does the buyer get after paying? A Steam activation code, an itch.io download link, a DRM-free build and a build that checks its own license are four different things. They come from different systems and need different delivery and support. Naming the right one on your sales page is the first step to a smooth direct sale.

1. Pick the kind of access you sell

Steam keys. A Steam key activates the game inside Steam. You request keys through Steamworks, and selling them on your own site still gives the buyer a Steam entitlement. Read the current Steam Key rules and guidelines before you plan bundles, backer rewards or discounts.

itch.io download keys. An itch.io download key is a private URL to your project's files on itch.io. It is a great fit when itch.io hosts your builds and you want to hand out access to backers or press.

A DRM-free build. You sell a download and trust the buyer. Here the important parts are clear usage terms, a reliable download page and an easy way to get updates.

Your own licensed build. Your game checks an entitlement you issued: the right product, a valid key, and the device policy you chose. This is the option that gives you full control over editions, trials, device limits and offline play, and it is the one the rest of this post focuses on.

Selling more than one kind? That works well as long as each listing says clearly which one it delivers.

2. Write the promise next to the price

Before the buyer pays, tell them:

supported operating systems and the edition they are buying
where the download comes from, and whether an account or launcher is needed
how many devices they can activate
how the game behaves offline
which updates are included

Keep the same wording on the checkout page, in the game UI, on the support page and in your refund policy. If the build depends on platform features (cloud saves, achievements, workshop content, multiplayer identity), test the direct build on its own before launch so the listing matches what players get.

3. Use editions for demos, backers and the full game

With your own license you can model editions as features on one product: for example full_campaign or level_editor. The game checks the feature before unlocking that content.

Demo: playable without a key; the full game unlocks after a valid license check.
Trial: a time-limited license with a clear end date and an obvious upgrade button.
Backers / early access: say which builds and which updates are included instead of promising a vague "lifetime key".

More on this: feature-based licensing and free-trial licenses.

4. Design offline play deliberately

Players expect a single-player game to run on a train. A good pattern:

Activate once online and bind the license to a stable device identity.
Store a signed offline token and verify it locally against a public key that ships with your game.
Check the product, the device and the token's expiry, not only the signature.
Refresh the token in the background whenever the player is online.

Then test the real situations on every platform you ship: clean install, restart, suspend and resume, lost connection, and an expired token. The offline licensing docs walk through the setup.

5. Connect payment and delivery into one flow

The smoothest direct sale is one where the payment itself triggers delivery:

The buyer pays through your payment provider (for example your own Stripe, Paddle or Lemon Squeezy account).
A verified payment webhook, not the success page, confirms the purchase.
The license is issued for the right product and features.
The buyer receives an email with the key and the download link, and can find both again in a customer account.

Renewals, cancellations and refunds should run through the same flow, so the license always matches the payment state. If you are deciding between a merchant of record and your own Stripe account, this comparison covers VAT and fees.

6. Example: a Unity game sold from your own store

Here is how this looks with PermitCore, which connects licensing to a branded Store on your own payment account with 0% sales commission:

Create the product and choose the edition, validity and device policy.
Add the Unity SDK and validate the expected product before the protected content runs; activate the device where registration is needed.
Create the Store listing, describe the build clearly and add the download URL of your release host.
Connect your payment account, matching prices and signed webhooks.
Run a sandbox purchase and check the whole chain: payment, correct product and features, delivery email and the download.
In the game, test the valid, expired, revoked and wrong-product outcomes, plus your device and offline rules.

The Store docs and the customer portal docs cover setup and self-service.

7. Make support boring

Tell buyers where to find their purchase, key and download, how to move to a new PC and whom to contact if an email does not arrive. Self-service device deactivation and re-download from a customer account remove most support email. Pair a fair device limit with that self-service and honest buyers stay happy while casual key sharing gets awkward; this guide goes deeper.

Before launch, check this list:

The checkout says which build or platform key is sold.
Download and update hosting work on their own.
Payment, license issuance and the delivery email have each been tested.
The game handles wrong product, device limit, expiry and no network without unlocking paid content.
Device transfer, offline time, refunds and support match what the page promises.

If you sell (or plan to sell) a game outside the big stores: which part took the most work for you, payments, delivery or keeping keys from being shared?

Sell software through your own Paddle or Lemon Squeezy account—with licensing connected

PermitCore — Sat, 07 Nov 2026 19:31:56 +0000

You want to sell your app, not spend every release maintaining a second product made of checkout pages, tax settings, invoice links and license-delivery scripts.

A merchant of record can take on the payment, tax and receipt side of eligible software sales under your agreement with it. But a successful checkout still needs to become something your customer can actually use: the right license, for the right product, in an account they can return to.

PermitCore Store now connects those steps with Stripe, Paddle and Lemon Squeezy. Choose one payment provider for your branded Store, connect your own account, and link verified payments to automatic software license delivery.

Choose your payment relationship. Keep your own brand.

Your payment account should fit how you sell.

If you want to use Paddle or Lemon Squeezy as merchant of record, you can connect your own provider account to PermitCore Store. The selected provider handles checkout, tax and its receipts under your merchant-of-record agreement. PermitCore handles the licensing and fulfillment side.

Stripe remains supported for your Store. If you sell directly through your own Stripe account, you remain responsible for your applicable tax obligations; the Store setup guide explains the available tax configuration.

The important distinction is ownership of the relationship: this is your provider account for your customers' purchases, not the account used to pay for your own PermitCore subscription.

PermitCore takes 0% sales commission. Your selected provider's fees, payout terms and account requirements still apply.

A storefront that looks like your software belongs there

The Store is more than a payment link.

Use your logo, colors and product imagery. Organize products into collections, add a featured spotlight, and build product pages with descriptions, feature lists and price choices. Offer one-time purchases or recurring products according to your sales model.

The same product and license settings connect the storefront to what your app enforces: features, device limits and access rules.

That gives the sale a continuous path:

Create the product and the license settings your customer should receive.
Implement licensing in your app through the REST API or an official SDK.
Sell through your branded Store and selected payment account.
Deliver access after payment is verified, with purchase history available in the customer's account.

Connect payment to access—not just a success page

A browser landing on a thank-you page is useful feedback. It is not the authority for issuing a paid license.

PermitCore verifies provider payment notifications and payment evidence before fulfillment. A completed purchase creates the appropriate order and license; the customer receives an email linking to their account rather than a license key exposed in the message.

For recurring products, paid renewals extend the existing key. Failed payments follow the Store's configured payment-grace policy. Cancellation and refunds follow their respective access rules, while customers retain their purchase history and provider documents.

That connection matters after the first sale as much as during checkout. You should not need a separate manual process to reconcile a renewed subscription with a customer's software access.

Paddle and Lemon Squeezy: same goal, different setup

With Paddle, the Store can create or update the connected provider catalog from your Store products and prices. Review the resulting mappings and provider tax categories as part of setup.

With Lemon Squeezy, create products and variants in its dashboard, then connect the matching variants in PermitCore. A multi-product cart uses an aggregate provider line while PermitCore preserves the individual purchase shares. Different recurring intervals use separate checkouts.

Both routes connect your provider account to the same branded storefront and licensing workflow. The Store setup guide walks through account configuration, product mappings, payment notifications and going live.

Less glue between selling and shipping

For an indie developer, reducing tax and invoicing administration is only part of the benefit. The other part is keeping the sale connected to the software you ship.

Your Store presents the product. Your selected provider handles the payment relationship. PermitCore delivers and manages the license.

Explore PermitCore Store, or follow the setup guide to connect your account.

Which part of selling software takes more of your time today: tax and invoices, storefront setup, or keeping paid access synchronized?

License Checks at App Startup: Open the Window First, Verify in the Background

PermitCore — Sat, 07 Nov 2026 09:41:08 +0000

Originally published on the PermitCore blog.

A license check at startup has two jobs: get the app on screen quickly, and decide which features the customer can use. Those jobs do not have to happen in the same moment. Render the first window from local proof, then confirm the entitlement with the server in the background and update the UI when the answer arrives.

1. Open the window and verify local proof

Show the main shell right away and keep license settings and the user's own files reachable. If your licensing policy allows offline use, verify the cached signed token against your trusted public key, and check that it belongs to the expected device and product. Check its expiry every time it is used.

No token, or a token that fails verification: keep paid features restricted until the server confirms access.
A revocation the app has already seen: persist it, so restarting with an old token on disk cannot bring access back.

In PermitCore, the offline flow accepts a server-issued signed token through ActivateOffline / activate_offline and checks it locally with ValidateOffline / validate_offline. Use the same trusted public key, device and product context at both steps. The offline licensing setup walks through the configuration.

2. Run the online check after the window renders

Run one validation per license at a time, with a short timeout. Retry transient failures with a small random delay, and respect the server's retry window when you are rate limited. Validation goes through the validate endpoint; device activation is its own step.

C#:

static async Task<LicenseResult> CheckAfterLaunchAsync(
    PermitCoreClient client, string key, Guid productId,
    CancellationToken windowClosing)
{
    using var timeout = CancellationTokenSource.CreateLinkedTokenSource(windowClosing);
    timeout.CancelAfter(TimeSpan.FromSeconds(2));
    return await client.ValidateAsync(key, expectedProductId: productId,
        ct: timeout.Token);
}

Python:

import asyncio

async def check_after_launch(client, key, product_id):
    return await asyncio.to_thread(
        client.validate, key, expected_product_id=product_id
    )

Construct the Python client with timeout=2. If your desktop toolkit has its own worker mechanism instead of asyncio, run the call there and hand the result back to the UI thread. Either way, ignore results that arrive for a window that has closed or a key that has been replaced.

3. Treat valid, denied and unknown as three different outcomes

Verified online: apply the entitlement for that product. When the cached signed token gets close to expiry, fetch a freshly issued one from your trusted issuer.
Explicit denial (revoked, expired, wrong product): persist the decision for that key, device and product, invalidate the offline authorization, and keep the recovery screen available.
Unknown (timeout, network failure, HTTP 503): the entitlement is unresolved. Keep exactly the access backed by current, verified local proof and its existing expiry. Authentication or response-format errors are something to diagnose; they should never create or extend offline access.

The API error reference lists which responses are authoritative denials. Show a quiet status line during outages and a specific recovery action for denials. If paid access expires while offline, keep the user's documents safe and let them reconnect or enter another key.

4. Test the transitions and measure first paint

In an integration fixture:

Delay the validation response past the timeout.
Return HTTP 503.
Return an authoritative revocation.

The first two must keep an unexpired offline grant working and keep an expired or missing grant restricted. The revocation must stop paid access and still apply after a restart with the old token on disk. Repeat with a wrong product, a changed device, a corrupted token and a rolled-back clock; treat unexpected clock changes as a reason to verify online.

Measure two numbers separately: time to the first interactive window, and time to the online entitlement. Compare p95 cold starts under normal latency, offline, and with a slow backend. Network time should never show up in the first number.

For longer interruptions, see what happens if a license server goes down, and for wording recovery screens, the license error messages guide.

How does your app handle startup today: does it wait for the license server, or open first and check in the background?

Moving to a New Licensing Provider Without Replacing Customer Keys

PermitCore — Thu, 05 Nov 2026 09:32:28 +0000

Originally published on the PermitCore blog.

Moving to a new licensing provider does not have to mean sending every customer a new key. The key string can stay the same. What changes is the plan around it: how the application talks to the new system, how entitlement data is mapped, and how verification is trusted from the first release that points at the new endpoint.

Start with a sample you own and a rollback plan. Treat key lookup, device registrations, offline proofs, payments and customer identity as separate pieces, and move each one on purpose.

Keep the key when the lookup can be reproduced

The PermitCore CSV import wizard works from your existing key strings. It hashes each key in the browser, and the server then applies its own HMAC lookup protection, so the plaintext never needs to be stored for lookup to work. If you prefer to script it, the API importer accepts the documented SHA-256 input.

Keep the exact original value and its encoding. Case, whitespace and separators matter, because the server hashes the plaintext bytes you supply instead of inventing a new key format. Before you roll out a client update, check a few real old keys against a migrated record that you own.

If your source system stored keys in a form you cannot read back, such as a vendor-specific salted hash or an encrypted blob, work out which verifiable lookup material you actually hold. Server-side migration is the right place for that step. Keep any privileged import credential on the server and out of customer software.

Map products and policy before importing

Use Licenses → Import, choose the source preset that matches your export, and map the columns explicitly. Match each row to the correct PermitCore product, then check expiry, trial state, features, device cap, node-locking and customer association one by one rather than assuming every source field means the same thing.

The API takes up to 500 rows per batch and reports a per-row outcome: Created, Duplicate or ValidationFailed. Rows commit independently, so a large import can be done in stages, and you can keep the results to reconcile any duplicate or failed rows before you retry them.

Version limits use dotted-numeric versions, and dates deserve a deliberate conversion, including what timezone they mean. The import reference lists the current column mapping and API fields. Anything outside that mapping can be applied afterwards through the normal administration workflow.

Plan device activations on purpose

InitialActivations seeds the used count for a key, anywhere from zero up to its activation limit. Pick that number together with your re-enrollment policy: an installation that registers against the new system enrolls as a fresh device, so test three cases before the real cutover: a partly occupied key, an existing installation, and a genuinely new device.

Floating licenses start fresh in the new system, with a new checkout and a returned deadline for each seat. The capacity guide and the floating lifecycle docs walk through that flow.

Choose how keys are recovered later

The import wizard offers optional passphrase encryption. If you turn it on, you keep ciphertext that an authorised person can reveal later with that passphrase. Lookup and validation work either way. Keep your authorised source export somewhere safe if you want a recovery path for the original keys.

Licenses issued by the PermitCore Store have their own server-managed delivery and recovery path. The exit and recovery plan shows which artifacts matter for which situation.

Ship the client update deliberately

Importing data prepares the new system; your next application release is what points users at it. Ship a version that calls the new endpoint and checks the new product scope. If your app already keeps the customer's key in its settings, reuse that stored value so people are not asked to retype it. Implement and test that storage step, since it lives in your app.

For offline use, plan new signed proofs from the new system. The official SDKs verify them against trusted public keys that you configure yourself, so include that configuration in the same release, and keep private signing and Admin keys out of the client. Signing and trust rollout covers how to stage a change of trusted keys.

Run an owned pilot where you can watch old and new decisions side by side. Write down the cutover and rollback conditions, avoid running both systems for the same customer by accident, and check what an older client does once the original endpoint is retired.

Keep payments on their own track

License import is about entitlements. Card tokens, mandates, provider subscriptions and store order history are a payment-provider topic, so handle them as a separate, approved process with that provider and coordinate access dates so nobody is charged twice. If you use the PermitCore Store, changing the vendor's selected provider applies to new checkouts, and existing purchases keep the provider they were bought with. The payment lifecycle guide explains how fulfillment follows each purchase.

Pre-cutover checklist

Reconcile row counts, duplicates, failures and product mapping between the source and the import.
Test existing key strings, wrong-product rejection, expiry and your device re-enrollment policy.
Test the app update, the retained key setting, the new trust configuration and offline recovery.
Keep billing changes, customer communication and rollback under separate control.

Have you moved a licensing system before? Which step took the most care: the key lookup, the client rollout, or payments?

Charging for an MCP Server: Check the License Before the Paid Tool Runs

PermitCore — Tue, 03 Nov 2026 09:36:08 +0000

Originally published on the PermitCore blog.

If you ship an MCP server people actually use, sooner or later someone asks "is there a paid version?". The pattern is simple: decide which operations are paid, tie the customer to an entitlement, and check that entitlement before the protected work runs. A local license key suits a distributed tool; a hosted service also needs its own user authentication.

This guide covers local Node.js and Python servers, plus the boundaries of a hosted design. PermitCore supplies the license check and the entitlement data; you bring your MCP server library and transport. The code below is a licensing-policy helper that you call from your own tool handler, not a complete MCP server.

Choose where the paid value runs

Local server with online checks. Ship the program and check a customer key when a paid operation begins. Keep the free tools usable even if the license service is unreachable.
Local server with signed offline proof. Verify a previously issued proof against trusted keys and its actual constraints. Revocation visibility while offline is bounded by reconnect time and token expiry.
Hosted server. Authenticate the caller, map their account to its entitlement and authorise each protected operation. You also keep control of remote computation, storage and API costs.

A customer controls a local installation and can modify its code, so a local gate supports your commercial policy rather than guaranteeing anything. Put especially valuable shared data or costly computation behind an authenticated service.

Keep the key out of the conversation

MCP_LICENSE_KEY here is just a convention of this guide, not an MCP-standard field. Supply it to your own local process through private configuration or a trusted launcher. Don't ask the model to paste it into a prompt or pass it as a tool argument: those paths can end up in conversation history and traces. Your PermitCore administrative API key never belongs in the customer program.

Cursor supports environment interpolation in mcp.json, so the secret can stay in your environment:

{
  "mcpServers": {
    "my-local-server": {
      "type": "stdio",
      "command": "node",
      "args": ["/absolute/path/to/your/server.mjs"],
      "env": {
        "MCP_LICENSE_KEY": "${env:MCP_LICENSE_KEY}",
        "MCP_PRODUCT_ID": "YOUR_PRODUCT_GUID"
      }
    }
  }
}

Replace the product GUID and point args at your real server entry point. Keep real keys out of a committed project config. For Claude Desktop, use Settings → Developer → Edit Config and the official local-server guide; don't assume Cursor's interpolation syntax works in another client.

Check the paid operation before any side effect

Keep installation, discovery and genuinely free tools available without a key. A tool description saying "Pro" is only a UI hint: enforce the entitlement inside the execution handler, before exporting files, calling a billable service or changing data. Hiding a tool in the client is not access control.

For the examples, create a product in PermitCore, use its GUID as MCP_PRODUCT_ID, and add a pro_export feature to the licenses that should unlock your export tool. A valid key for a different product must not grant access, so the helpers compare the product id as well as the feature.

Node.js

import { PermitCoreClient } from '@permitcore/permitcore';

export async function checkProLicense() {
  const key = process.env.MCP_LICENSE_KEY?.trim();
  const productId = process.env.MCP_PRODUCT_ID?.trim();
  if (!key || !productId) {
    return { allowed: false, message: 'Configure MCP_LICENSE_KEY and MCP_PRODUCT_ID privately.' };
  }
  try {
    const client = new PermitCoreClient({
      baseUrl: process.env.MCP_API_URL || 'https://api.permitcore.dev',
      enableOfflineCache: false, timeoutMs: 5000, maxRetries: 0,
    });
    const result = await client.validate(key, '1.0.0', productId);
    if (result.isValid !== true || result.productId?.toLowerCase() !== productId.toLowerCase()) {
      return { allowed: false, message: 'Pro access could not be confirmed. Check the key, product and service.' };
    }
    if (!PermitCoreClient.hasFeature(result, 'pro_export')) {
      return { allowed: false, message: 'This license does not include Pro export.' };
    }
    return { allowed: true, message: null };
  } catch {
    return { allowed: false, message: 'Pro access could not be confirmed. Check the configuration and service.' };
  }
}

Python

import os
from permitcore import PermitCoreClient

def check_pro_license():
    key = os.environ.get('MCP_LICENSE_KEY', '').strip()
    product_id = os.environ.get('MCP_PRODUCT_ID', '').strip()
    if not key or not product_id:
        return {'allowed': False, 'message': 'Configure MCP_LICENSE_KEY and MCP_PRODUCT_ID privately.'}
    try:
        client = PermitCoreClient(
            os.environ.get('MCP_API_URL') or 'https://api.permitcore.dev',
            enable_offline_cache=False, timeout=5, max_retries=0,
        )
        result = client.validate(key, version='1.0.0', expected_product_id=product_id)
        if result.is_valid is not True or (result.product_id or '').lower() != product_id.lower():
            return {'allowed': False, 'message': 'Pro access could not be confirmed. Check the key, product and service.'}
        if not result.has_feature('pro_export'):
            return {'allowed': False, 'message': 'This license does not include Pro export.'}
        return {'allowed': True, 'message': None}
    except Exception:
        return {'allowed': False, 'message': 'Pro access could not be confirmed. Check the configuration and service.'}

Call the helper from the protected handler and stop before doing the work when allowed is false. Free handlers never call it. These online-only helpers disable offline caching and retries and use a five-second timeout per attempt. The Python SDK call is synchronous, so an async server should run it on a worker thread. MCP_API_URL is trusted process configuration (self-hosting or a local test fixture); never derive it from a tool argument or model output.

Return a useful refusal

The MCP tools specification separates tool execution failures from malformed protocol requests. For a denied business operation, return a tool error (isError: true) with a short, safe explanation, using the result type your MCP library expects.

Say what to do next: configure the key outside the conversation, check that it belongs to this product, or get a license that includes the feature. A temporary verification failure shouldn't tell a paying customer their key is definitely invalid, and the message must never contain the key or account details.

One stdio detail: stdout carries protocol messages, so a licensing banner printed there can break the connection. Keep diagnostics on stderr and redact secrets there too.

Design offline use as its own policy

A local server may need to work on a train or an isolated workstation. Use the signed offline path from the offline licensing docs: a successful online check can provide a signed grace-cache token when configured. Verifying a saved unsigned JSON response, or caching a true forever, is not safe. Test expiry, tampering and key rotation separately.

Seats and usage

One key copied into several client configs doesn't define a team-seat policy. Pick node-locked or floating controls for what you sell, and don't activate on every tool call: activation is separate from validation. If you charge by usage, define the billable unit (messages, tokens, successful exports are all different) and use metering explicitly.

Hosted access needs authentication too

For an HTTP-based server, follow the MCP authorization specification. Authentication says who is calling; your commercial policy says what their account may use, so map the authenticated account to its entitlement instead of sharing one global key. Don't treat a model-supplied email or license string as proof of identity.

Sell it and test the whole path

A PermitCore Store can use your own Stripe or Paddle account and deliver a key after verified payment, with 0% PermitCore sales commission (provider fees apply). Configure the product, features and seat policy, then test a purchase together with the protected tool.

Before release, run through the real client and transport: free tools with no key; Pro with the right feature; a key for another product; an expired or revoked key; a service failure; and confirm no side effect happens after a denial and that license material never reaches protocol output, logs or the model.

Full original with all the links: permitcore.dev/blog/monetize-mcp-server. Docs: permitcore.dev/docs/getting-started.

If you're building MCP servers, how are you planning to charge for them: a license key in the client config, a hosted account, or something else? I'd love to hear what's working. 🙂

Perpetual License vs Subscription License: Which Should You Sell?

PermitCore — Sun, 01 Nov 2026 09:27:06 +0000

Originally published on the PermitCore blog.

Perpetual and subscription aren't really about the license technology at all. A license key doesn't care whether it's "supposed to" last forever. The real difference is a business model decision: does the customer own access forever after one payment, or do they keep paying to keep access? Most licensing platforms, including ours, can issue either from the exact same product.

How purchase type determines access

For a one-time purchase in PermitCore Store, LicenseExpiryDays sets the number of days of access; leaving it blank creates a perpetual key. Monthly and annual purchases follow Stripe's paid billing period instead: each paid invoice extends the same key. Failed renewals use the configured payment grace window, 14 days by default, and access expires when it ends.

A product can offer one-time, monthly, and annual options side by side; the selected purchase type determines which expiry rule applies. Activations, node locking, and feature flags remain independent controls.

Perpetual: what you're actually trading

A perpetual license (one payment, access forever) is simple to explain to a customer and creates no ongoing billing relationship to maintain: no dunning emails, no cancellation flow, no "why was I charged again" support tickets.

The tradeoff is revenue shape. Each sale is a one-time event, so growth depends entirely on new customers or paid upgrades, not a compounding base of renewals.

It also creates a real, ongoing support obligation most vendors underestimate. A customer who paid once five years ago may still expect their software to run, even as the OS and platform change underneath them. Perpetual access does not itself promise endless feature upgrades or commercial support. Applicable security-support duties need separate assessment; they are not erased by an expired upgrade contract. Our CRA support and licensing guide goes deeper. In short: state the purchased execution rights, the upgrade policy and the security-support period separately.

Subscription: what you're actually trading

A subscription (recurring charge, access requires staying current) creates a predictable, compounding revenue base and a natural way to fund ongoing development. The customer relationship doesn't end at the sale.

The tradeoff is operational surface:

Failed payments need handling (grace window, then expiry).
Cancellations need a clean flow.
Every renewal is a moment a customer can decide to leave, so churn becomes a metric you actively manage.

Selling both isn't unusual

A common pattern: subscription as the default (lower upfront price, steady revenue) with a perpetual option at a higher price point for customers who specifically want to avoid recurring billing. Enterprise procurement teams in particular often prefer a one-time purchase over an operating subscription for budgeting reasons that have nothing to do with your product.

Since both are just a price plus an expiry setting on the same product, offering both isn't extra engineering work, just a second price point.

What doesn't change either way

Node-locking, floating seats, feature gating, and offline support are all independent of whether the license is perpetual or subscription. The perpetual-vs-subscription decision is purely about the business model; how the license actually behaves on a customer's machine is a separate, orthogonal choice.

Which model are you selling right now, and what made you pick it? I'd love to hear how other indie devs decided. 🙂

How to Implement Feature-Based Licensing

PermitCore — Fri, 30 Oct 2026 09:33:17 +0000

Originally published on the PermitCore blog.

"Is this license valid?" is often the wrong question. The more useful one is usually "what does this specific license unlock?" A Pro customer and a Team customer might both hold a genuinely valid key, but your app needs to know which of them gets the export button, SSO, or the API integration. That's feature-based licensing, and it's a field on the license key itself, not a separate system.

Where features live

Every LicenseKey has a FeaturesJson field: a plain JSON array of feature-flag strings, e.g. ["export","api","sso"]. You set this when you create a key (or define it once on a License Template so every key generated from that template inherits the same list), and it's returned in full on every validate()/activate() call, no separate endpoint required.

Reading it in your app

The response's features field is a plain string array. PermitCore's .NET SDK adds one convenience method on top of it:

/// Returns true if this feature flag is in the license's feature list.
public bool HasFeature(string feature) =>
    Features?.Contains(feature, StringComparer.OrdinalIgnoreCase) ?? false;

In your own code, that's a one-line gate:

var result = await client.ValidateAsync(licenseKey);

if (result.HasFeature("export"))
    exportButton.Visible = true;

if (result.HasFeature("sso"))
    EnableSsoLogin();

The check is case-insensitive on purpose: a casing difference between how a feature was set on the key and how you check it in code is exactly the kind of bug that only shows up for one customer, weeks later.

Two ways to assign features

Per-key. Set FeaturesJson directly when creating or editing an individual license. Useful for a one-off custom deal or an enterprise customer with a negotiated feature set that doesn't match any of your standard tiers.

Via a License Template. Define a template once (e.g. "Pro Template" with ["export","api"], "Team Template" with ["export","api","sso","seats"]) and every key generated from it, whether created manually, through the Store, or via the Stripe checkout flow, inherits that feature list automatically. This is the right approach if you're selling more than one tier: define the tiers as templates once, and every future key just picks one.

Where this fits versus other licensing controls

Feature flags answer "what can this customer do," which is a different question from what node-locked vs. floating answers ("how many devices or seats can use it") or what an expiry date answers ("for how long"). Most real products combine all three: a Pro-tier key might be node-locked to 2 devices, expire in 12 months, and unlock a specific feature set, all on the same license.

How do you split features between tiers in your own product: flags on the license, or separate builds? 🙂

How to Prevent License Key Sharing (Three Layers That Work Together)

PermitCore — Wed, 28 Oct 2026 09:31:54 +0000

Originally published on the PermitCore blog.

A license key on its own is just a string. Nothing stops someone from pasting a valid one into a forum thread or a Discord server unless the system that checks the key actually does something about it. Here are three complementary techniques we use in PermitCore. Each one covers a different sharing pattern, and together they make casual key-sharing genuinely inconvenient.

1. Node-locking: tie a key to a device

Every license has a Max Activations limit: how many distinct devices it can be active on at once. With node-locking on, the first activate() call binds the key to a hardware fingerprint (a hash derived from stable machine identifiers, nothing personally identifying). Reactivating on the same device doesn't use a new seat, but a genuinely different machine does, and once the limit is reached the next machine is rejected.

That's the first line of defense: sharing a key with a friend costs one of your own seats the moment they use it, and once the limit is hit, both of you find out immediately. The device activation guide covers how the fingerprinting works.

2. Floating licenses: shared seats, not shared copies

For team products where node-locking doesn't fit, for example a license that should float to whoever on the team is using the app right now, floating (concurrent) licenses work better. A fixed number of sessions are checked out and released as people start and stop the app. When every seat is taken, the next activation waits until someone checks theirs back in.

Simultaneous use stays bounded by what was paid for; it's just counted per concurrent session instead of per permanent device.

3. Abuse detection: the pattern seat limits can't see

A key with a generous seat count (say a 50-seat team license) can still be posted publicly and used by far more than 50 people over time, as long as no more than 50 are active at once. Every individual request looks legitimate.

So we watch for that pattern directly: per license key, how many distinct caller IPs hit validate() / activate() within a rolling one-hour window.

private const int RequestSuspiciousThreshold   = 200;  // requests/hour
private const int RequestBlockThreshold        = 2000; // requests/hour
private const int IpFanoutSuspiciousMultiplier = 5;    // × MaxActivations
private const int IpFanoutSuspiciousFloor      = 20;   // distinct IPs/hour, minimum
private const int IpFanoutBlockMultiplier      = 20;   // × MaxActivations
private const int IpFanoutBlockFloor           = 100;  // distinct IPs/hour, minimum

The threshold scales with the license's own seat count. A 1-seat license reaching 20 distinct IPs in an hour is already abnormal, while a 500-seat license needs proportionally more before it's flagged. There are two tiers:

Suspicious: the request is still served, so a real customer is never blocked over a false positive, but an audit entry is written and a license.abuse_suspected webhook fires (at most once per key per hour) so you can decide what to do.
Block: well past the suspicious threshold, the request is rejected outright before any database work, which protects your infrastructure from a key that's clearly being hammered from everywhere.

Why layering matters

Node-locking and floating limits bound how much simultaneous use one key can support. Abuse detection catches the slower leak, where a key spreads more widely than its seat count alone would reveal. Combined with revocation, you can shut a leaked key down the moment the webhook tells you about it, without touching paying customers.

How do you handle leaked keys in your own products today: hard limits, monitoring, or just revoking when someone reports it? 🙂

Node-Locked vs. Floating Licenses: Which One Do You Need?

PermitCore — Mon, 26 Oct 2026 09:39:52 +0000

Originally published on the PermitCore blog.

Both options sit right next to each other on a typical Create License form, and it's not always obvious which one fits your product. The short version: node-locked ties a key to specific machines; floating ties a key to a pool of concurrent seats that any machine can borrow from. Here's when each one actually makes sense.

Node-Locked: One Key, Specific Machines

A node-locked license binds to a device's hardware fingerprint the first time it's activated, and stays bound until it's explicitly deactivated. MaxActivations is a hard ceiling on how many distinct devices can ever hold that key at once.

This is the right default for most desktop software: a customer buys one seat, installs it on their one work laptop, and that's that. It's simple to reason about, simple to support, and matches how most customers already think about "a license."

Floating: A Shared Pool of Seats

A floating license doesn't permanently tie itself to any machine. Instead, your app checks out a seat when it starts, and checks in (releases it) when it closes, or after a heartbeat timeout if it crashes without checking in cleanly. MaxActivations here means "how many machines can be actively using the software right now," not "how many machines have ever run it."

A 10-seat floating license lets any number of employees install the software, but only 10 can have it open at the same time.

This is the right fit for office software used by a team that's never all logged in simultaneously: CAD tools, analytics dashboards, anything where you'd rather sell "10 concurrent users" than "10 named installs."

// On app start
var session = await client.CheckoutFloatingSeatAsync(key);
if (!session.IsValid)
{
    // result.ErrorCode == "SeatsExhausted" means every seat is in use right now
    ShowNoSeatsAvailable();
    return;
}

// Periodically, while the app is running
await client.HeartbeatAsync(session.SessionId);

// On clean app shutdown
await client.CheckinFloatingSeatAsync(session.SessionId);

Side by Side

	Node-Locked	Floating
Ties to	a specific device	a seat pool, any device
"Seats" means	total installs ever	concurrent active users
Needs	activate/deactivate	checkout/heartbeat/checkin
Best for	1 user, 1 machine	shared office tools

What Happens If a Floating Session Never Checks In?

If a customer's machine crashes, loses power, or their app process is killed rather than closed cleanly, the seat isn't lost forever: a missed heartbeat past the configured timeout automatically frees the seat back into the pool for the next machine that needs it.

What's Next

Both models assume you're selling directly through your own app. The other distribution path is a built-in license store, for teams who want a real checkout page and automatic key delivery without building any of that themselves: Setting Up a License Store.

Which model do you use for your own desktop app, and did you ever have to switch? 🙂

How to Build a License Key System

PermitCore — Fri, 23 Oct 2026 08:28:35 +0000

Whether you build one yourself or use a service, every license key system is answering the same three questions: what does a key look like, how do you check one without leaking what a valid one looks like, and how do you stop a valid key from working everywhere at once. Here's the real architecture, independent of any particular vendor.

Designing the key format

A license key is a string a human might need to type, read over the phone, or paste from an email — that constrains the design more than it first seems. A sensible format groups characters for readability (PERMIT-XXXX-XXXX-XXXX-XXXX rather than one long block), and a good charset avoids characters that are easy to confuse when hand-typed or read aloud — no 0/O, no 1/I/l. A real example: ABCDEFGHJKLMNPQRSTUVWXYZ23456789 — deliberately missing the ambiguous characters, 32 symbols so each character carries 5 bits of entropy, and a 20-character key (the four XXXX groups) gives 100 bits — comfortably beyond brute-force range.

Never store the plaintext key server-side

This is the part naive implementations get wrong most often: storing the key as plaintext (or as a reversible encryption of it) means a stolen database dump hands an attacker every valid key directly. The correct approach is a one-way transform — hash the key, and look it up by hash, not by the key itself. A plain hash isn't quite enough either: a fast hash function (SHA-256 alone) lets an attacker with a stolen dump brute-force short/predictable keys offline at billions of guesses per second. The fix is a keyed hash — HMAC with a secret that lives only on your server, never in the database — so even a full database theft is useless without also stealing the separate secret.

The lookup path

// Customer sends the plaintext key in a POST body (never a URL — keeps it out of
// access logs, browser history, and CDN caches)
var hash = HMAC_SHA256(serverSecret, SHA256(plaintextKey));

// Look up by the keyed hash, never by the plaintext key itself
var license = db.LicenseKeys.FirstOrDefault(l => l.KeyHash == hash);

This gives you the property that matters most: your server can validate a key it has never seen the plaintext form of stored anywhere, and a database breach alone — without the separate HMAC secret — is not enough to forge or verify keys.

Activation limits need a real lock, not just a count check

A naive "read the count, check it's under the limit, then increment" has a race window: two devices activating a nearly-full license within milliseconds of each other can both read the same under-limit count and both succeed, overselling a seat. The fix is an atomic conditional update (UPDATE ... SET count = count + 1 WHERE count < max, checking the database's own row affected count) or a database-level lock scoped to that one license — tested against genuinely concurrent requests, not just sequential ones, since the race only shows up under real concurrency.

What tends to get skipped, and shouldn't

A system that only handles the happy path is missing: per-key failed-lookup rate limiting (so a script can't enumerate keys by brute force), abuse detection for a valid key shared across too many distinct callers (a different problem than a rate limit catches — see how PermitCore detects this), and an offline story if your app needs to keep working without a network call (see device fingerprinting and offline validation). None of these are exotic — they're just easy to underestimate until a real customer hits the gap.

If building all of this yourself sounds like more than you want to maintain long-term, that's the actual tradeoff a licensing API like PermitCore is solving — see our honest build vs. buy breakdown for the fuller picture either way.

Originally published on the PermitCore blog. How do you handle license keys in your own apps? I'd love to hear what's worked for you.

PermitCore Store 2.0: a branded software storefront built into licensing

PermitCore — Mon, 12 Oct 2026 15:50:23 +0000

A licensing API solves key creation and validation. It does not automatically give a software vendor a polished way to present products, run promotions, take payment, deliver licenses, and support customers after checkout.

That is why we rebuilt the PermitCore Store.

Store 2.0 is a responsive, vendor-branded software storefront connected directly to the same products, prices, entitlements, orders, subscriptions, and licenses managed in PermitCore.

Merchandising without building another application

Vendors can now create a storefront with:

hero campaigns and featured releases
curated product collections
category and workflow tiles
horizontal product shelves
custom colors, backgrounds, images, spacing, and labels
search and responsive desktop/mobile navigation

Every section can be configured from the Shop Designer instead of being hard-coded into a separate storefront project.

Trials, bundles, and scheduled discounts

Store 2.0 supports one-time and subscription products, free trials, bundles, scheduled promotions, percentage or fixed-value discounts, and campaign labels.

For discounted offers, vendors can also show the lowest applied price from the previous 30 days. This gives EU-facing stores the information needed for transparent discount presentation while keeping the display configurable for stores operating elsewhere.

Checkout and licensing stay connected

A buyer can discover a product, add it to the cart, pay through the vendor's connected Stripe account, and receive the correct license automatically.

The complete workflow is:

Create a product and define its license rules.
Implement validation through the REST API or one of eight official SDKs.
Merchandise the product in a branded Store 2.0 storefront.
Accept payment through the vendor's own Stripe account.
Generate and deliver the correct license automatically.

PermitCore takes 0% commission on software sales. The vendor keeps the Stripe relationship while PermitCore connects checkout to customers, orders, invoices, subscriptions, entitlements, and license delivery.

Built for desktop and mobile

The storefront, product pages, cart, checkout flow, and customer account are responsive. Storefront content is cached for fast delivery, while checkout, account, and license operations remain protected by the platform's authorization, rate-limiting, and tenant-isolation controls.

Try the presentation store

We turned Nexova into a complete demo storefront so the entire flow can be explored with realistic products, imagery, bundles, trials, and discounts.

How are you currently connecting product discovery, checkout, and license delivery?