Licence Management and Billing

Pyvorin Native licensing is local-first with a signed, server-issued lease. Once a device is activated, compilation and execution run entirely on that device; the network is needed for activation and periodic revalidation, not for the compile path. This page describes the verified mechanics of pyvorin-native 1.0.9: the three licence commands, what the licence file on disk actually contains, how device binding and revocation behave, what happens offline, and what the plans cost. Everything here was checked against the installed build and the billing database behind it.

An earlier version of this page described a compile-credit model with per-compilation metering and a usage dashboard. That model does not exist. Billing is a plain subscription; there is no per-compile charging anywhere in the product.

The three licence commands

The installed pyvorin binary exposes exactly three licence subcommands:

pyvorin activate PYVR-XXXX-XXXX-XXXX
pyvorin status
pyvorin check

activate accepts the key positionally or via --key. On success it prints a single line — License activated. tier=… expires=… — and writes the local licence store. status prints the local summary as JSON; from a real run on our test host:

{
  "status": "active",
  "tier": null,
  "expires_at": "2027-09-12T17:07:40+00:00",
  "features": [
    "compile",
    "loop_fusion",
    "cache_optimizer"
  ]
}

The tier and features values come from the signed lease held locally, so they reflect whatever the server issued for that key. check runs the hard gate — the same check the runtime applies before it will compile. On a valid licence it prints License gate OK and exits 0; on failure it exits 1. Put pyvorin check at the top of CI jobs that should fail fast when a runner's licence is missing. The developer CLI invoked as python -m pyvorin carries the same facility as license-status (with the British-spelled licence-status alias).

What the licence file actually contains

Activation writes ~/.pyvorin/license.json with file mode 0600. The fields, verified from a file written during activation testing:

Two details matter operationally. First, a legacy path at ~/.nexus/license.json is still honoured if present, so older installs activated under the previous product name keep working. Second, editing the file is pointless twice over: the HMAC flags the edit, and even a perfect forgery is overridden by the signed lease, whose tier and feature claims take precedence over anything in local JSON.

Device binding and the fingerprint

Activation sends a single POST to https://api.pyvorin.com/api/v1/licenses/check with two fields: the licence key and a device fingerprint computed as sha256(hostname:username:/etc/machine-id), truncated to 32 characters. No source code, telemetry payloads or workload data travel in this request. The licence issued in response is bound to that fingerprint, which means a licence file copied to another machine fails verification there.

This drives the main operational rule of licence management: activate per machine, do not copy licence files around. For fleets, bake pyvorin activate into provisioning and let each device earn its own lease. If your infrastructure routes through a proxy or an internal mirror, the PYVORIN_LICENSE_URL environment variable overrides the base URL for the check.

Grace periods when the network disappears

The hard gate is designed for laptops, servers and edge boxes that spend time offline. Its logic, verified by probe: if the locally stored lease validates offline, the gate passes even when the online revalidation fails — it returns silently rather than breaking your build. Only when offline validation itself fails does the gate demand a successful online check, and if that fails too you get a LicenseError naming both reasons.

After a lease actually expires, an entitlement cache provides a further window, by tier:

On top of that window, the server can issue an offline_permit — an explicit allowance with an offline_hours budget — for planned long outages such as shipboard systems or sealed production cells. Anti-rollback protection (a monotonic watermark with five minutes of clock tolerance) stops a device winding its clock back to stretch a window. The full endpoint list and timings are on the network requirements page.

Signed leases, revocation and tamper evidence

The lease is Ed25519-signed by the server and verified in the client against an embedded public key; the client accepts no lease longer than 800 days. Entitlements claimed inside the signed lease override local file edits, which closes the "edit the JSON" attack for good. Revocation works the same way in reverse: when the server no longer reports a key as active, activation refuses to store a new lease, devices whose offline validation has lapsed fail the gate on their next online check, and the client records a revoked telemetry event — part of the always-on security event vocabulary alongside tamper_detected and validation_failed. A device holding a still-valid signed lease keeps working inside its lease and grace windows; there is no remote kill switch that reaches into an offline machine. Frankly, that is the right design, and it is also why keeping leases renewed matters more than chasing perfect connectivity.

Plans and trials

Prices below are read from the billing database that serves the site, in GBP:

Annual billing runs at roughly ten months' price. Enterprise is priced by arrangement — the database carries no number, which means contact sales, not a hidden discount. Two hygiene notes from the same table: a legacy "Professional" plan at £149 exists but is neither active nor visible, so it is not sold, and a handful of placeholder USD rows are seed data that should never surface publicly. If you see either quoted anywhere, distrust the source. Internally, the client recognises the tier classes demo, trial, basic, professional and enterprise, with a default-deny policy for anything not explicitly granted.

Fleet and CI activation

The device-binding model has one straightforward consequence for fleets: every machine earns its own licence file, and the cheapest reliable pattern is to activate during imaging. Bake pyvorin activate <KEY> into the provisioning step, then add pyvorin check to the machine's health checks so licence drift surfaces as a failed check rather than as mysteriously slow code. Treat each CI runner as a device in its own right and activate it once at setup; the lease persists across builds. One environment variable you may see in older material, PYVORIN_SKIP_LICENSE, exists only in development builds that ship a marker file — production wheels exclude it, and on a properly installed 1.0.9 it does nothing. Do not build your pipeline around skipping the gate; build it around a valid licence per runner, which costs one command. For anything beyond a handful of machines, the licence dashboard at app.pyvorin.com/licenses is where issued keys, devices and expiry dates are reviewed.

What billing is not

Worth stating plainly, because the old docs implied otherwise: nothing in pyvorin-native 1.0.9 meters compilation or execution for billing. The complete outbound endpoint list is the licence check, a telemetry batch of event metadata, and — only in the developer CLI — login and logout. There are no compile credits, no usage thresholds, no surprise invoices. The commercial decision is the plan, full stop.

Which brings us to the judgement call. Monthly versus annual is not an accounting question at this price scale; it is an adoption question. While you are still measuring whether Pyvorin pays for itself on your workloads, stay monthly and spend the difference on the benchmarking effort — the quick start gets you a measured answer in minutes. Once a workload is proven native and the licence line has survived two budget reviews, annual is a straight saving. And if you are provisioning a fleet, activate at imaging time and re-run pyvorin check in your health checks: a fleet with silent licence drift is a fleet quietly back on the interpreter. Activation mechanics in depth live on the activation and entitlement page, and the command surface is catalogued in the CLI reference.

Where to go next

• Activation and entitlement — the activation workflow, gate semantics and entitlement cache in full.
• Network requirements — every endpoint, payload class and timeout in pyvorin-native 1.0.9.
• Quick start — install, activate and benchmark your first function.
• CLI reference — the licence commands and everything else the CLI exposes.

Last reviewed 16 April 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal and the billing plans table (verified 13 September 2026). status and check output shown is captured from real runs; plan prices are read from the billing database, not from marketing copy.