Network Requirements for Pyvorin
Every endpoint pyvorin-native 1.0.9 contacts, when each fires, offline grace windows, air-gap implications, TLS, and the env overrides that redirect traffic.
Published Aug 18, 2026
A machine running pyvorin-native 1.0.9 needs outbound HTTPS to exactly one host — api.pyvorin.com on port 443 — and only for licence and telemetry traffic. Compilation, execution, caching and fallback all work without any network at all. This page lists every endpoint the package can contact, when each fires, what happens when the network is absent, and the firewall policy that follows, all verified against the installed build by string sweep and runtime interception.
If you are scoping egress for a hardened host, the short version is: allow api.pyvorin.com:443 outbound, deny everything else, done. The rest of this page is the justification and the edge cases.
The complete endpoint list
Every URL present in the installed 1.0.9 binaries was enumerated two ways — a string sweep of all compiled modules, and a runtime capture that intercepted the HTTP layer during activation, compilation and gating. They agree on the full list:
| Endpoint | When called | Payload | Timeout |
|---|---|---|---|
POST https://api.pyvorin.com/api/v1/licenses/check | pyvorin activate; periodic revalidation from the hard licence gate (pyvorin check and in-process gate calls) | {"license_key", "device_fingerprint"} — no source | 30 s on activation; 10 s on revalidation |
POST https://api.pyvorin.com/v1/usage/events/bulk | Telemetry flush: 50 events, 300 s, or process exit | Envelope {v, session, privacy, abuse_score, events:[{t,e,p,s}]} — event metadata only | 5 s, fire-and-forget |
POST https://api.pyvorin.com/api/auth/token | Only pyvorin login in the product CLI | Account credentials | Standard |
POST https://api.pyvorin.com/api/auth/revoke | Only pyvorin logout in the product CLI | Token | Standard |
Three facts that simplify firewall work. There is no update-check call anywhere in the package — nothing phones home to ask about newer versions — so there is no fourth host to allow and no surprise traffic to explain. The auth endpoints fire only if someone runs login or logout in the product CLI; an application that never uses those commands never generates that traffic. And the licence and telemetry traffic goes to api.pyvorin.com only: the license.pyvorin.com and telemetry.pyvorin.com hosts that exist on the infrastructure are legacy vhosts that the 1.0.9 native client never contacts, so rules scoped to the two subdomains alone would silently break nothing today while documenting a wrong assumption for the next audit.
TLS and certificate handling
All four endpoints are HTTPS. The client uses Python's standard urllib.request stack, which performs certificate verification through the platform's trust store — there is no bundled certificate, no verify=False shortcut and no option to disable verification. That choice has an operational consequence worth planning for: in environments that intercept TLS with a corporate proxy CA, the proxy's root must be present in the Python trust store used by the running interpreter, or the licence check will fail with a certificate verification error that looks, at first glance, like a licensing problem. Diagnose from the error text, not the symptom.
Plain-HTTP redirection is possible for inspection because the two environment overrides accept any URL, including http://localhost:8080. That is a debugging and verification feature — the runtime capture that produced the payload table above used exactly that mechanism — not a supported production configuration. Sending licence keys or telemetry over unauthenticated HTTP on a real network hands both to anyone on the path.
Offline behaviour and grace periods
The licence gate is designed for intermittently connected machines. The semantics, verified by runtime probe, are asymmetric in a sensible direction. If the locally stored licence validates offline — signature, fingerprint binding, expiry and anti-rollback watermark all check out — the gate passes even when the online revalidation fails or the network is absent; the failure returns silently rather than blocking work. If the local licence fails offline validation, the gate requires the online check to succeed, and raises LicenseError carrying both reasons when it cannot.
After a lease expires, an entitlement-cache grace window keeps the product running while connectivity is restored:
| Tier | Offline grace after lease expiry |
|---|---|
| demo, trial | 24 hours (86,400 s) |
| basic, professional | 72 hours (259,200 s) |
| enterprise | 90 days (7,776,000 s) |
Enterprise deployments can additionally hold a server-issued offline permit — a signed object carrying an explicit offline-hours budget — which extends operation on isolated networks by arrangement rather than by default. Anti-rollback protection (a monotonic watermark with five minutes of clock tolerance) and entitlement-hours accounting with anti-replay nonce accompany all of this, so grace cannot be obtained by rewinding the clock or replaying an older lease.
Telemetry offline behaves as designed: flush attempts fail silently, events in the ring buffer are dropped as the process moves on, and the buffer is per-process memory — nothing queues to disk for later delivery. A machine without network access simply sends nothing. This is worth stating because "offline event queue" appears in some third-party notes about other products; no such queue exists in pyvorin-native.
Air-gapped deployments
A fully air-gapped host is a supported shape, with the honest caveats. Compilation, execution and benchmarking are entirely local and work indefinitely without connectivity; python -m pyvorin bench needs no licence for measurement. Licensed operation relies on the offline path: the licence file must be present and valid on that machine — activation itself requires one reachable licence check, so the standard provisioning flow is to activate on a connected machine or during a maintenance window, then let the device-fingerprint binding and signed lease carry the entitlement into isolation. Grace windows cover lease expiry as tabled above, and enterprise offline permits extend that where the isolation is permanent rather than intermittent.
The device fingerprint binds a lease to hostname:username:/etc/machine-id. Rebuilding an air-gapped host, cloning it from an image, or changing its machine-id invalidates the local licence and, without connectivity, the online recovery path is unavailable. Plan re-activation into maintenance windows for exactly that event, and document it in the runbook before it happens at the wrong moment.
The activation and entitlement page covers the lease, the gate and provisioning in the detail these caveats deserve.
Environment overrides and their trust implications
Two environment variables redirect the package's outbound traffic:
| Variable | Redirects | Intended use |
|---|---|---|
PYVORIN_LICENSE_URL | Licence checks (base URL; the client appends /api/v1/licenses/check) | Staging servers, egress proxies, payload inspection |
PYVORIN_TELEMETRY_URL | Telemetry batches (full endpoint URL) | Inspection sinks, policy-mandated logging proxies |
Call these what they are: trust-redirection switches. Any actor who can set them for your process can point the licence key, device fingerprint and telemetry stream at a host they control, and receive whatever your environment sends. The mitigations are operational. Set both variables explicitly in deployment configuration — pinned to the real endpoints where no override is needed — rather than inheriting ambient environment; scrub them from CI runner images, where a poisoned base image would otherwise harvest licence keys from every build; and audit for their presence alongside other security-relevant environment variables. If your threat model includes malicious local code, recognise that such code has far stronger options than this — but these variables lower the attack to a single assignment, which is why they belong on the checklist.
Firewall allowlist guidance
Pulling the page together into the rules we recommend for a hardened egress policy:
# Egress for pyvorin-native 1.0.9 — the complete list
api.pyvorin.com tcp/443 allow # licence checks, telemetry, product-CLI auth
# Deny-by-default covers everything else:
# - no update or version-check traffic exists to allow
# - license.pyvorin.com and telemetry.pyvorin.com are never called by 1.0.9
# - compilation makes no network calls at any tier
The same single rule serves containerised deployments: one egress entry on 443, no inbound requirements at all — the package listens on nothing. Where policy demands explicit inspection before allowlisting, the debugging route is the licence-URL override pointed at an internal sink: activate once, read the two-field payload, and confirm for your own records what the rule you are about to write actually carries. That exercise is quick, it requires no vendor involvement, and it produces evidence an assessor will accept, which a paragraph in documentation never quite does.
One boundary closes the page. Everything above is scoped to pyvorin-native. The sibling package pyvorin-thin talks to a different compile endpoint because it submits source for server-side compilation; its requirements are its own and are not covered here. Mixed environments should keep the two packages' traffic distinct in both documentation and rules — a firewall that conflates them will be wrong about one of them.
Where to go next
- Activation and entitlement — the licence check, the signed lease, and provisioning for offline and air-gapped machines.
- Telemetry and privacy — what the bulk endpoint receives, down to the field, and how to inspect it.
- Security and source privacy — the privacy-side view of the same outbound surface.
- Pyvorin GDPR considerations — assessing these data flows under data-protection law.
Last reviewed 18 August 2026 against pyvorin-native 1.0.9 installed at /root/pvfinal. The endpoint list was established by a binary string sweep and runtime interception with no real external calls; grace periods and gate semantics are from the installed licensing core and runtime probes. Server-side behaviour (retention, availability targets) is outside what the artefact proves and is not claimed.