Implementing a Robust Software Distribution and Licensing System

Writing a PHP application is half the job if you plan to sell it. You also need a way to deliver it to buyers, let them update it, and make sure each copy is used under the licence they paid for. This guide walks through a practical design for PHP software distribution and licensing in 2026: the licence model, signed licence keys, activation, a licence server, and delivering updates.

1. The parts of the system

A working setup has five parts:

Build them in that order. The model decides what the keys must contain, and the keys decide what the server has to check.

2. Choose a licence model

Write the terms down in a clear licence agreement. The agreement, not the code, is what gives you a legal remedy if someone breaks the terms.

3. Design licence keys you can verify offline

A random key that is only checked against your server works, but every check depends on your server being up. A better design is a signed licence: a small JSON payload (who bought it, which product, how many domains, expiry date) plus a digital signature made with a private key that exists only on your licence server.

The application carries only the public key. It can confirm that a licence is genuine and unchanged, but it cannot create one. Someone reading your code learns nothing that lets them forge a key.

Signing on your licence server, with OpenSSL (available in nearly every PHP build):

<?php
// Run once: create a key pair and keep private.pem off every public server.
// $key = openssl_pkey_new(['private_key_type' => OPENSSL_KEYTYPE_EC, 'curve_name' => 'prime256v1']);
// openssl_pkey_export_to_file($key, 'private.pem');
// file_put_contents('public.pem', openssl_pkey_get_details($key)['key']);

$licence = json_encode([
    'id'      => 'LIC-10492',
    'product' => 'invoice-pro',
    'email'   => '[email protected]',
    'domains' => 1,
    'updates_until' => '2027-09-23',
]);
openssl_sign($licence, $signature, file_get_contents('/secure/private.pem'), OPENSSL_ALGO_SHA256);
$key = base64_encode($licence) . '.' . base64_encode($signature);

Verifying inside the application:

<?php
function licence_is_genuine(string $key, string $publicPem): ?array {
    [$payload, $sig] = array_map('base64_decode', explode('.', $key, 2) + [1 => '']);
    if (openssl_verify($payload, $sig, $publicPem, OPENSSL_ALGO_SHA256) !== 1) {
        return null; // forged or altered
    }
    return json_decode($payload, true);
}

The same pattern works with Ed25519 signatures through PHP's sodium functions, but the sodium extension is not included in every host's PHP build, so OpenSSL is the safer default for software that customers install themselves.

4. Activation and ongoing checks

A genuine key can still be shared. Activation limits that.

5. Build the licence server

The licence server is a small web application with a database. At minimum it needs:

• Tables for customers, licences (product, limits, expiry, status) and activations (licence, domain, first and last seen).
• An issue step triggered by your payment system when an order is paid.
• API endpoints to activate, validate and deactivate, each returning a signed response.
• Rate limiting on the endpoints, so nobody can guess keys by brute force.
• An admin view to revoke a refunded or abused licence and see where each key is active.

Keep the private signing key out of the web root and out of version control. If you would rather not build this, hosted licensing services exist; compare their pricing and data location before you commit.

6. Distribute releases and updates

• Short-lived download links. After payment, and from the customer's account page, generate a download link that expires after a short time and is tied to a valid licence.
• Versioned releases. Publish each version as a numbered zip with a changelog, and keep older versions available for customers on older PHP versions.
• Checksums. Publish a SHA-256 checksum for each release, so buyers can confirm the file arrived intact.
• An update check. Let the application ask your server for the latest version its licence entitles it to, and download it through the same licensed link.
• Composer, for developer buyers. A private Composer repository, self-hosted with Satis or run as a hosted service, lets developers install your package with their licence key as the credential.

7. Protect the licence check itself

A licence check written in plain PHP can simply be deleted. Encode the files that contain it, and the core logic around it, so that removing the check is not a one-line edit. See Securing self-hosted PHP applications with obfuscation and encoding tools for the current tools and their limits.

8. Running this on Domain India

The licence server. A small PHP and MySQL licence API runs comfortably on shared hosting. If you build it in Node.js, the App Platform detects Node.js apps automatically and includes a PostgreSQL database; other languages need a Dockerfile. For full control, a self-managed VPS gives you root access.

Customer installs on shared hosting. If your buyers may run your application on shared hosting, test the activation call there. Shared servers disable some PHP network functions: on our cPanel servers fsockopen, stream_socket_client and curl_multi_exec are disabled, and on most DirectAdmin sites curl_exec is disabled too. Offline signature checks with a grace period keep your application working even where the call home fails. On our cPanel servers' PHP 8.3 build the sodium extension is not installed (measured 23 September 2026), which is why the example above uses OpenSSL. See PHP disabled functions on shared hosting.

Prices on the cards are live and exclude 18% GST.

Ready to launch your software? Host your licence server on the App Platform, cPanel hosting or a VPS, and read about protecting your PHP code before you ship.