Python 3.11, 3.12, and 3.13 on Windows x64 and Linux x64. macOS is on the roadmap but not in the current beta.
All major Python control-flow and async patterns are fully supported inside the VM, including generators (yield / yield from / send() / throw() / close()), context managers (with statements), and async/await coroutines. Free-threaded Python 3.13t (no-GIL) is not yet supported; use @vm_skip on any code that requires it and it will run normally via CPython.
Yes. Building is free during the beta. Create an account, open The Forge, and submit builds without a paid plan or credit card.
Beta accounts still have operational limits so the build queue stays usable: regular web builds allow one active job per user and up to three submissions per hour.
Yes. Your Python logic is virtualized and protected. Native C extensions such as NumPy, Pandas, Pillow, and SciPy are included in the build as-is and run at full native speed. They are not obfuscated, because they were never your source code to begin with.
The practical rule: if your proprietary logic is in Python, it is protected. If it delegates heavy math to NumPy, that call still runs at C speed.
No, not by default. The anti-VM / anti-sandbox detection is an optional hardening step that you enable per build. The standard release profile leaves it off, so your app runs normally inside cloud VMs, CI runners, and developer VMs.
Turn it on only when you distribute to end users and want to make analyst sandboxing harder.
No. PyVMProtect targets the ABI of a minor version, not a patch version. A .pyd built for cp311 works on every 3.11.x interpreter. You only need a new build when you move to a new minor line, for example 3.11 to 3.12.
For typical application code (business logic, JSON, Windows API calls) compiled modules run at 1.1–1.8× the CPython time. Pure compute loops (tight math, matrix ops) are much heavier through the VM, but they should not be virtualized in the first place. Exclude them via configuration and they run at native speed with ~0% overhead.
Cold start (import + first call) is 5–20 ms, amortized over the process lifetime.
C extensions (NumPy, SciPy, Pandas) are never virtualized and always run at native speed.
Measured on real builds: a compact module (~80 LOC) compiles to about 268 KB. That baseline is mostly the fused VM interpreter and security machinery, not your code. A 1,600-line module reaches roughly 1.5 MB. Heavier mutation profiles can push this further.
Full numbers with the benchmark methodology are on the Technology page.
During the current beta, built .pyd files are not signed by default, so Windows SmartScreen may warn on first run. Automatic signing by "PyVMProtect Systems" is planned before general availability. Enterprise customers will be able to sign with their own EV certificate.
Yes. Uncaught exceptions produce a normal Python traceback with line numbers and the original exception type and message. In the hardened release profile, variable names inside the traceback are obfuscated, but the structure stays readable.
A dev profile is available when you want completely clean traces for debugging.
It is held only long enough to run the build and let you download the protected output, then deleted from disk. It is not archived, not backed up, and not used for training. Full details are in the privacy policy.
A self-hosted compiler is available on request for enterprise customers that cannot send source code to a third party. It runs as a container inside your own infrastructure. Contact us if you need this.
A determined, skilled reverse engineer can always make progress on a compiled binary. PyVMProtect does not make binaries impossible to analyze; it removes the normal Python recovery path and pushes analysis into native code, VM behavior, and runtime state.
Every build gets build-specific opcode details, an encrypted bytecode blob, randomized dispatch behavior, and instruction-key rotation. Work done on one binary is less reusable against the next.
print) to intercept decrypted data?
▾
The runtime checks common built-in monkey-patching patterns before protected calls execute. If a built-in such as print, input, eval, exec, or open has been replaced with a Python-level hook, the VM can raise a security violation instead of continuing normally.
This is a hardening layer, not a claim that all runtime interception is impossible. Native instrumentation and process-level analysis still need separate defenses.
The VM raises a RuntimeError and terminates execution. On Windows, a modal error dialog can appear alongside the terminal message so the event is visible regardless of how the binary was launched. Runtime state is cleared where possible before exit to reduce the value of late memory dumps.
The checks span several signals, including debugger flags, hardware debug registers, kernel debug ports, timing checks, API hook detection, and watchdog liveness. These checks are designed to create friction, not to make debugging mathematically impossible.
Obtaining a trusted EV (Extended Validation) code-signing certificate requires a formal identity verification process that takes several weeks. We are in that process now. Until it completes, Windows SmartScreen may display a warning on first run for binaries downloaded from the internet.
This does not affect whether the protected code can run. The .pyd also has internal integrity checks that run independently of the OS signature chain. Signing is mainly an OS-level trust signal for distribution.
Enterprise customers who cannot wait can provide their own EV certificate and we will apply it at build time.
The VM runtime is closed-source. Build-specific details such as opcode mappings, dispatch cookies, epoch boundaries, bytecode encryption keys, and handler layout are generated per build. That means there is no single static mapping that applies to every customer artifact.
Access to the runtime design would help an analyst understand the family of protections, but they would still need to analyze the specific binary and its generated VM details.