Running Pyvorin Natively on Your Own Hardware

Pyvorin Native compiles your Python to machine code on your own hardware, inside your own process, and it is worth being blunt about why this page exists at all: there is no other mode. An earlier version of this documentation described local native compilation as an optional flag — something you switched on to save remote compile credits — which inverts reality. Local compilation is not a feature of the product; it is the product. This page states what actually runs where in pyvorin-native 1.0.9, what the handful of network calls do, and what all of that means for an air-gapped machine. Every claim was verified against the installed build and its source on 13 September 2026.

What runs on your hardware

Everything in the compile path. The compiler lowers Python to LLVM IR through llvmlite and links against runtime libraries shipped inside the wheel. We searched the compiler, router and code-generation modules for any network capability — urllib, urlopen, requests — and found none, and a full sweep of every installed binary for server URLs found only the licence and telemetry endpoints, never a compile endpoint. The package's own docstring describes it plainly: an in-process Python module compiler, without HTTP overhead.

The wheel itself is complete. All 5,098 files in the distribution — mostly Cython-compiled shared objects — ship in the install; there is no protected-component downloader anywhere in the package, and no delivery URL exists in any installed binary. If you can import pyvorin, you can compile, full stop. No activation-dependent component ever arrives later.

Concretely, on a machine with the package installed, this runs entirely offline:

python -m pyvorin compile my_script.py
python -m pyvorin bench my_script.py --function main --runs 5

Your source is read from disk, hashed, compiled, executed and cached without a single packet leaving the machine. The compile artefact cache lives at <site-packages>/.pyvorin_cache/disk_compile — inside the install tree, on your disk, keyed by a hash of your source, the function name, the compile options and the toolchain's modification times.

One honesty note, because the marketing claim deserves scoping. The statement "customer source never leaves customer infrastructure" is true of pyvorin-native 1.0.9 — verified above. A sibling package, pyvorin-thin, does submit source to a server-side compile endpoint, and the platform API exposes that endpoint for it. If you are auditing data flows, confirm which package is actually in your environment. The native package keeps your source local; the thin one does not.

What "native" concretely means

It is worth being precise about the word, because it does specific work. When compile reports COMPILED_FULL, your function has been lowered to LLVM intermediate representation, optimised, and emitted as machine code for your exact CPU, then linked against runtime libraries shipped inside the wheel — a builtins library, a list runtime and an array runtime, all present as shared objects in the package directory. Execution of the compiled path needs no Python bytecode interpreter in the loop. CPU-only, too: there is no GPU path in 1.0.9, so the hardware that matters for performance is the processor your process runs on.

None of this is exotic to verify. python -m pyvorin doctor prints the runtime libraries it finds, the C compiler, AVX2 support and available memory in one screen — we ran it during the writing of this page and each line names the file or capability it checked. If you are qualifying a new machine fleet, that one command is the acceptance test: every line that matters should read [PASS] before you rely on the compiler for anything.

The two licences your machine needs

Getting the product running takes two steps: install one package, activate one key. Neither step involves choosing a compilation mode, because there is nothing to choose.

pip install pyvorin-native
pyvorin activate PYV-XXXX-XXXX-XXXX

Activation makes exactly one network call: a POST to https://api.pyvorin.com/api/v1/licenses/check carrying your key and a device fingerprint — a truncated SHA256 of the hostname, your username and the machine ID. No source code, no file names, no environment list. The server replies with a signed lease; the client writes it to ~/.pyvorin/license.json with mode 0600, so only your account can read it. The lease is Ed25519-signed and bound to the fingerprint, which is why copying the file to another host does not activate it there. From then on, the licence gate validates locally first and only revalidates online periodically; an offline-valid licence passes even if an online revalidation cannot complete. Full gate semantics, grace periods and what the licence file contains are on the activation and entitlement page.

What the telemetry call does

The second outbound endpoint is https://api.pyvorin.com/v1/usage/events/bulk, and it is easy to describe precisely because the design is deliberately boring. Telemetry is fire-and-forget with no background thread: events accumulate in an in-process ring buffer capped at 1,000 entries and flush when the buffer reaches 50 events, 300 seconds pass, or the process exits — whichever comes first. The envelope carries a session identifier, a privacy level, a locally computed abuse score and the events themselves: compile, execute and feature_used, the first three sampled at 1%, plus always-on security events such as activation, validation_failed, tamper_detected and revoked. None of it is source code.

Three properties follow from that design. The default privacy level, standard, sends the sampled events above. minimal restricts it to security events; disabled stops it. The catch, stated plainly because it surprises people: the only way to change the level in 1.0.9 is an in-process API call — pyvorin._telemetry.set_privacy("disabled") — or the developer build; there is no environment variable and no config file for it. There is also no update-check call of any kind in the package: no version-check code path exists, so the client will never phone home to ask whether it is current. If your network team wants the complete outbound list for a firewall review, the network requirements page documents all four endpoints and their payloads.

Air-gapped machines

An air-gapped deployment is a normal deployment plus one manual step. Compilation, benchmarking, caching and fallback all work with the network absent — they never used it. Activation needs one successful POST; on a sealed machine, activate on a connected host is not an option because the lease binds to the machine's fingerprint, so the practical route is to bring the machine briefly online for activation, or stand up the licence endpoint internally — the base URL is overridable with the PYVORIN_LICENSE_URL environment variable, which the client honours. Once a valid lease exists locally, the offline gate semantics and the per-tier grace windows (24 hours for demo and trial, 72 hours for basic and professional, 90 days for enterprise after lease expiry) keep compilation working through extended disconnections. Telemetry on an air-gapped machine simply fails silently by design — the flush is fire-and-forget with a five-second timeout, and failures are ignored.

One caveat for your security review, because it is easier to state than to discover. The moment pyvorin is imported — before any activation, on a machine with no licence at all — the package creates ~/.pyvorin_cache/columnar_kernels/ in the home directory. It is a cache, it is local, and it contains nothing sensitive; but if your compliance checklist says "no file-system writes until configured", this one write precedes configuration by design.

Choosing local deliberately

The engineering question worth sitting with is not whether local compilation works — it is whether it is what your workload needs. The trade is arithmetic. Ahead-of-time compilation costs a few hundred milliseconds per function (we measured roughly 230–290 ms for small functions on our machine) and pays back on every subsequent call; a batch job that calls a hot function ten thousand times amortises that cost into noise, while a one-shot script that runs once pays it in full. Local compilation also means your performance is your hardware's performance: the same function compiles to different machine code on different CPUs, and our own benchmark suite — a geomean of 3.16× across 71 workloads on the test host, with 17 workloads slower than CPython — is a property of one machine, not a promise about yours. Measure on the hardware you ship. When you are ready, the first-compile walkthrough takes you from install to a measured result in ten minutes, and the speed proof page shows how to document that result so it survives an audit.

Where to go next

• Activation and entitlement — the licence file, gate semantics and offline grace, in depth.
• Network requirements — the complete outbound endpoint list for firewall reviews.
• Quick start — install, activate and benchmark in one sitting.
• How to compile your first function — the verified command walkthrough.

Last reviewed 26 March 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal: compile-path network absence, the endpoint list, telemetry transport and privacy levels, the import-time cache write, and the wheel's completeness were all verified directly against the installed artefacts on 13 September 2026. The previous framing of local compilation as an optional mode has been removed.