Edge and IoT Deployment

Deploying compiled Python to edge and IoT devices means one thing in Pyvorin Native: compile locally, ship the artefact, run offline. Compilation happens in-process on a machine you control; the compiled shared objects travel to the constrained device inside your normal deployment; and at run time the device needs no compiler and, after activation, no network. This page sets out what pyvorin-native 1.0.9 verifiably supports in that pattern, where its limits are, and what the measured IoT workloads actually gained. Claims we could not verify against the installed build are stated as such or left out.

What the native package supports

Start with the platform facts, because they bound everything else. The shipped wheel of pyvorin-native 1.0.9 is a single binary build: CPython 3.12 on Linux x86_64. The package metadata declares CPython 3.11 and 3.12 support, and the codebase contains Windows path handling — but no Windows wheel was found, so treat Windows as unverified. Critically for this page, there is no ARM wheel: compilation on a Raspberry Pi or ARM64 gateway with the native package is not a supported path in 1.0.9. If your fleet is ARM, the native compiler is a build-time tool on an x86_64 machine, not an on-device runtime. For ARM64 gateways specifically, our Pyvorin Edge SDK with its EdgeAgent daemon and compiler bridge is the on-device product — the EdgeAgent documentation covers installation on Raspberry Pi-class hardware, and this page does not duplicate it.

The honest shape of edge deployment with the native package, then: an x86_64 build host does the compiling; the devices do the running.

Compile first, deploy second

The compile-then-deploy pattern works because compiled artefacts are ordinary files in a known location. Compiling on the build host populates <site-packages>/.pyvorin_cache/disk_compile with SHA256-named shared objects indexed by cache_index.json; shipping that directory alongside the package gives the deployed interpreter a warm cache from its first start. There is no separate export step because there is no separate artefact format — the cache is the deployment unit. Pre-compiling during image build, including the CI cache-key scheme, is covered step by step on the warm-up and caching strategies page.

Two constraints to respect. First, the cache key hashes the source, function name, compiler options and toolchain modification times, so artefacts are tied to the exact package build and flags that produced them. Ship the cache with the same package version and the same compiler flags used at build time; mixing versions simply misses, and misses recompile on the device — costly if the device is weak, harmless but slow. Second, keep the application code identical between build host and device. A source edit on either side silently invalidates the entry by design.

On the device, the same safety properties hold as anywhere else. A function the compiler cannot take runs as original CPython through the recorded fallback path, so a partially supported workload on a fanless box degrades to interpreter speed rather than failing. That property matters more at the edge than in the data centre, because nobody SSHs into a sensor gateway at 3 a.m. to read a stack trace. The fallback mechanics are on the unsupported code and fallback page.

What this looks like on an IoT workload

Our benchmark suite includes IoT-shaped sensor processing, run under the current build with memory caps fixed and active. The canonical 2026-09-13 run measured two of them:

The spread between the two rows is the real lesson. Anomaly detection over a window of readings is a tight numeric loop — exactly the ground a native compiler takes. A rolling average over a handful of values is nearly all fixed overhead, and the win is modest. Both results are honest, and neither transfers automatically to your firmware. Edge code skews small, and the suite's own worst cases — micro-workloads where compilation overhead dwarfs the loop — are exactly the shape that edge functions often have. Measure your actual loop before assuming the 45x row; the benchmarking workflow in the quick start takes minutes on a representative host.

Network behaviour on constrained links

Runtime network dependence is minimal and worth enumerating precisely, because bandwidth and intermittent connectivity are defining constraints at the edge:

• Compilation: none. The compile path contains no network code at all — verified by source audit and by a URL-string sweep of every installed binary. No source ever leaves the device or the build host for compilation.
• Licensing: one endpoint, with grace. The only licensing call is a single POST to api.pyvorin.com carrying the key and a device fingerprint — no code, no telemetry payloads. After activation, a stored signed lease validates offline; if the lease lapses, offline grace runs to 24 hours on trial tiers, 72 hours on paid tiers and 90 days on enterprise, extendable with a server-issued offline permit. The mechanics are on the licence management page and the endpoint list on the network requirements page.
• Telemetry: event metadata, throttleable. Telemetry batches event metadata on a 5-second timeout, fails silently, and can be dropped to minimal (security events only) or disabled via the in-process privacy API — relevant on metered links, since it is the only other traffic the package generates:

import pyvorin._telemetry
pyvorin._telemetry.set_privacy("minimal")   # security events only

There is no environment variable for this; the API call is the supported switch.

Activate at provisioning time, while the device still has a reliable link, and the fleet can run dark indefinitely within its grace windows. That is the entire network story.

Provisioning and pre-compilation

The practical pipeline has three stages. On the build host — an x86_64 machine with the same package version and flags the fleet will run — compile the application and verify with python -m pyvorin compile app.py and run --compare, which checks native output against CPython on the same inputs. Compile cost at this stage is modest: on our unremarkable test host, a typical numeric function compiled in 259 milliseconds. Since compilation happens on the build host, the device's CPU never pays it, and a weak device is not a barrier to the pattern. Ship the package, the application and the populated disk_compile directory in the image. On first boot, run pyvorin check to confirm the licence gate, then start the application; every cached function loads its artefact instead of compiling. For devices too constrained to compile even on a bad day — the cache corrupts, a function was edited in the field — the fallback keeps the device correct while you re-provision, which is the correct failure order for hardware you cannot easily reach.

Where ARM64 gateways are the target, stop here and use the edge-native path: the Pyvorin Edge SDK and its EdgeAgent daemon are built for exactly that hardware, compiling hot paths to ARM64 with NEON vectorisation on-device. Refer to the EdgeAgent documentation for installation, configuration and fleet management. This page deliberately makes no claims about that product beyond its existence — its details belong to its own docs.

A worked judgement call

The question is always which devices deserve the native path at all. Our rule, formed from the numbers above: compile the loop that dominates the device's duty cycle, and leave everything else to the interpreter. A gateway aggregating a hundred sensors per second has a real inner loop, and 45x on that loop converts directly into a cheaper CPU or a smaller power budget. A sensor node that wakes, reads one value and sleeps has no loop worth the name — its win, if any, sits near the 1.95x row, and its compile cost is paid at provisioning for almost no runtime gain. Do not compile the fleet. Compile the hotspots. The honest cost model is per-device and per-loop, and anything broader is folklore.

Where to go next

• Network requirements — the complete endpoint list, payloads and timeouts for pyvorin-native 1.0.9.
• How local compilation works — why compilation needs no network and where artefacts live.
• Warm-up and caching strategies — pre-compilation and shipping a warm cache in an image.
• Licence management and billing — activation, device binding and offline grace periods.

Last reviewed 28 April 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal. Platform support statements reflect the shipped wheel and package metadata verified on 13 September 2026; IoT figures are from the canonical 2026-09-13 benchmark run with memory caps active. ARM on-device compilation is not claimed for the native package; the EdgeAgent documentation is referenced by name only.