DEV3 Technologies home

DEV3 Keyquay – Software Licence Server with Signed Keys, Activation Seats, Offline Tokens & Update Channels (Next.js)

Self-hosted licence server on Next.js 16 and MongoDB: signed licence keys, activation seats per machine or domain, offline Ed25519 tokens, update channels with signed downloads and a customer portal. Setup wizard and demo data included. No mobile apps.
by DEV3 TechnologiesVerified Author(0) 0 sales 0 viewsUpdated 11 Nov 2026

Video tour. Pick a section below to browse 96 screenshots in 8 sections.

App & phone tours

Tap play to watch each app. Nothing downloads until you do.

  • Mobile web1:09

Keyquay is a licence server that you host yourself, built by DEV3 Technologies on Next.js 16, React 19, TypeScript, Tailwind 4 and MongoDB. It is for people who sell software: PHP scripts, WordPress plugins and themes, desktop and command-line tools, mobile apps. Each vendor gets a workspace. In it they define products and policies, issue licence keys by hand, API or store webhook, let customers activate machines or domains against seat limits, verify online or offline, and ship releases through update channels. You, the operator, sell plans to vendor workspaces and watch the platform from an operator panel. The demo shows fictional vendors such as a WordPress plugin shop, a PHP script seller and a command-line tool studio.

No live demo: 96 grouped screenshots and two video tours show the marketing site, products and policies, licences, releases, store integrations, the customer portal and the operator panel. Install it with the demo data to try every role on your own server. This product is a web application with a REST API: there are no mobile apps.

For vendors

  • Products and policies: perpetual, subscription, trial and floating-seat policies with seats, activation scope (machine, domain or user), a dev allowance for staging and local hosts, offline token days, grace days, entitlements and update rights.
  • Signed keys: keys carry a product prefix, 80 random bits and a checksum. Only a peppered hash and the last five characters are stored; the key is shown once.
  • Activations that hold up: parallel requests for the last seat produce exactly one winner, the same site activating twice changes nothing, and customers can release seats in the portal.
  • Offline signed tokens: compact Ed25519 tokens bound to product and fingerprint. Rotate signing keys without breaking installed clients.
  • Releases: upload a zip, it is hashed and signed, publish it to stable, beta or nightly, yank it if needed. Downloads are signed ten-minute links that re-check entitlement and never serve a yanked release.
  • Store webhooks: signed, idempotent events for orders, renewals, cancellations and refunds with a SKU mapping, an event log and a retry for failed events. A simulated store lets you try the whole flow.
  • SDK snippets generated per product for PHP, WordPress, JavaScript, Python and Dart, tested against tokens this server produces.
  • Reports: a Seat Board, validations by result, versions in the field, renewals and refunds, with a CSV export.

For customers and operators

  • A customer portal with magic-link sign-in: masked licences, seat release, downloads, a renewal link and vendor branding.
  • Roles (owner, admin, support, developer, viewer), members, audit log, scoped API keys and signed outbound webhooks.
  • An operator panel with workspace meters, abuse overview, the email outbox (licence keys redacted) and audit.
  • Plans, simulated checkout, invoices, an installer wizard, demo data and a keyquay:check command that reconciles seats, signatures and usage.

What you get

The complete Next.js source with the shared DEV3 core vendored, scripts for scheduled jobs, Documentation/index.html (install, cron, floating seats, tokens, API, security), START-HERE.txt and LICENSE.txt. Support is included for 6 months.

Good to know

  • Licence checks are only as strong as the client. Keyquay ships signed tokens and SDK snippets, not obfuscation or DRM, and never runs code on customer machines. Offline tokens are Ed25519-signed: keep the private keys safe (they are sealed in a vault; back up KEYQUAY_VAULT_KEY) and rotate when needed.
  • Checkout is a webhook-driven hook, with a simulated store in the demo. It is not a storefront or payment processor.
  • MongoDB 6 or newer and one Node process. There is no separate worker, but scheduled jobs need cron: the lease sweep every minute is required if you sell floating-seat policies. Optional cron entries handle expiry, usage rollups and renewal emails.
  • APP_SECRET is mandatory outside demo mode and must never change after keys are issued. Floating-seat clients use heartbeat, not validate-with-fingerprint.
  • Email goes to the outbox until you configure SMTP. Operator billing is simulated by default; run your own sandbox payments first.
  • Rate limits are kept per server process. Release files must be zip archives within MAX_UPLOAD_MB and the plan's storage cap.
  • Name: Keyquay is a working name checked by a web search only, not a trademark clearance.
  • No hosted demo. All vendors, customers and people in the screenshots are fictional.

Quality checks

Keyquay 1.0.0 passed the seven checks of the DEV3 Next.js suite on the final code: type-checking and linting (0 errors), 456 app tests and 49 core tests (including parallel seat races on a real database), a production build of 81 routes with 202.6 KB of gzipped first-load JavaScript and CSS on the home page, seeding of the empty and demo datasets, a headless-browser pass over 60 routes and 19 happy paths (including parallel activations for the last seat, duplicate store webhooks and parallel checkouts over HTTP), an install test from the packaged zip and a secret scan. Lighthouse on the home page, mobile: performance 94, accessibility 97.

#license-server#software-licensing#license-keys#activation#offline-tokens#update-channels#saas#customer-portal#webhooks#nextjs#mongodb#ed25519

How it's built

Architecture, stack, key decisions and the quality gates DEV3 Keyquay passed before release.

The engineering behind Keyquay: hashed keys with a checksum, Ed25519 tokens and releases, last-seat races without transactions, idempotent store webhooks and signed downloads, with the known limits written down.

The problem it solves

A licence server sits between a vendor and every customer machine. It has to be hard to guess, fair to honest customers and impossible to trick into over-granting. Two installs racing for the last seat must end with exactly one winner. A store that retries a webhook twenty times must issue one licence. A token created for one site must not validate on another, and a withdrawn release must never be served, even from an old link.

Architecture and approach

Keyquay is a Next.js 16 application on MongoDB with a shared DEV3 core for auth, billing and tenancy. Workspaces are tenants: a Mongoose plugin scopes every query by an immutable workspace id and fails closed, cross-tenant code lives only in the platform folder and scripts, and a unit test greps for violations.

Keys that cannot be read back

A key is a product prefix, 80 random bits in Crockford base32 and a checksum. It is stored as a peppered SHA-256 hash with its last five characters, so neither support nor the operator can read it. A bad checksum and an unknown key answer the same error, so the API is not an oracle.

Seats without transactions

MongoDB runs standalone here, so seat counting uses a conditional update with a predicate on the licence counter and a unique partial index on the activation. Parallel duplicates of one fingerprint compensate the counter; a test fires twenty parallel activations at two seats and expects exactly two winners, then repeats it over HTTP against a running server.

Signatures everywhere

Each product has an Ed25519 key pair sealed in a vault with AES-256-GCM. Offline tokens carry the product, a fingerprint hash and an expiry, with no algorithm header to confuse. Releases are signed over product, version and digest. Rotation keeps old public keys published until the tokens they signed have expired.

Webhooks and downloads

Inbound store events are verified with an HMAC and a time window, stored by event id so replays do nothing, and held as pending when a refund arrives before its order. Download links are signed, bound to the licence key, last ten minutes and re-check entitlement when used.

Quality gates and results

456 app tests and 49 core tests pass, plus an HTTP race suite and a reconciliation command that checks seat counters, duplicate fingerprints, release signatures and usage rollups after the demo seed of 46,000 licences. Known limits: checks are only as strong as the client, checkout is webhook-driven, and rate limits are per process.

Tech stack

Area Technologies
App Next.js 16, React 19, TypeScript, Tailwind 4
Data MongoDB, Mongoose 9
Security Ed25519, AES-256-GCM vault, HMAC-SHA256, Pinned outbound fetch

Inside the build

Questions: Honest answers on DRM, checkout, running it and the vault key. Questions — Honest answers on DRM, checkout, running it and the vault key.

Hero: Ship keys, not worries: an activation log that fills line by line beside the Seat Board. Hero — Ship keys, not worries: an activation log that fills line by line beside the Seat Board.

Guides & articles

Practical guides and engineering write-ups for DEV3 Keyquay.

Software licence server: 7 things to check before you pick one

Last updated
Software licence server: 7 things to check before you pick one: DEV3 Keyquay

Licence servers are easy to demo and hard to trust. The questions that matter come after the first key works. Here are seven things to check before you pick a self-hosted server, with DEV3 Keyquay as the worked example.

The Keyquay home page with an activation log beside the Seat Board

1. How are keys stored?

A server that can show you a customer's key later can leak it. Keyquay stores a peppered hash and the last five characters, shows the key once and issues a replacement when a customer loses it.

A licence with its masked key, seats and timeline

2. What happens when two installs race for the last seat?

Exactly one should win, and the same site activating twice should change nothing. Ask how the server counts seats without a database transaction.

A licence at its seat limit

3. Can clients verify offline?

Look for signed tokens bound to the product and the machine or domain, with key rotation that does not break installed copies.

Per-product signing keys with a rotate button

4. How do updates reach customers?

Channels, signatures and short-lived, entitlement-checked downloads matter more than a download button. A yanked release must stay yanked.

Releases and channels with digests and signatures

5. How do store orders become licences?

Signed webhooks that are idempotent, tolerate out-of-order events and can be retried.

The simulated store and the event log

6. Can customers help themselves?

A portal where they release a seat, download updates and find the renewal link saves support time.

The customer portal with masked licences

Video tour of Keyquay

7. Who keeps it running?

One Node process and MongoDB, plus cron for the jobs. The minute-by-minute lease sweep is required for floating seats.

Limits to weigh

Checks are only as strong as the client: this is signed licensing, not DRM. Checkout is webhook-driven, not a storefront, and rate limits are per process. Check those against your needs.

Frequently asked questions

The complete source code (version 1.0.0) as a download from your account, with the setup and usage guides shown on this page. You can modify the code to suit your product.

Questions about this product (0)

Answers from the DEV3 team and the community.

Ask a question

No questions yet.

Wondering about setup, licensing or customisation? Ask, and the DEV3 team will help.

Open the product board

More from this author

View all

Related in Enterprise SaaS Starters

View all