Skip to content

Protection

PyLocket applies maximum protection to every build automatically. This includes military-grade encryption, anti-reverse-engineering measures, memory protection, and binary hardening. No configuration is needed — every build receives the full protection suite.

What Gets Protected

  • Function bodies: Every Python function, method, and lambda expression
  • Class bodies: All class-level code
  • Module-level code: Top-level module initialization code

What Is Not Protected

  • Non-Python files: Images, configuration files, data files, HTML templates, and other static assets
  • C extension modules: Compiled .pyd and .so files from C/Cython are not modified by PyLocket
  • Function signatures: Argument lists remain visible in stubs so calls work normally
  • Module names and directory structure: Package layout is preserved
  • Code that cannot be encrypted without breaking your app: a small number of scopes are deliberately left unencrypted because encrypting them would stop the application running. Each is reported in the build's coverage summary rather than skipped silently:
    • Bodies that use free variables from an enclosing function. Python's exec() rejects a code object with free variables outright, so a class defined inside a function that reads an enclosing local cannot be sealed.
    • Generator and coroutine bodies.
    • Bodies too small to be worth encrypting. A scope of one or two instructions carries no more information than the fact that it exists.
    • Bodies with no names or string constants to hide. There is nothing in them that encryption would conceal.
    • Any packaging shape where sealing cannot be applied safely. This includes wheels and other Python package layouts today. A working application always takes priority over maximum coverage.

Tip: If you need to protect non-Python data files, encrypt them at the application level and decrypt them within your protected Python code.

Function signatures remain visible

Argument lists remain in the stub code after protection so that calls into your functions continue to work. Docstrings inside encrypted function and class bodies are encrypted along with the body.

What protection does NOT do: hide values from the running app

Encryption removes your class attributes, constants and docstrings from the shipped files: someone holding the artifact without a valid licence cannot recover them. It does not hide them from a licensed user while the app is running.

Your application has to be able to use its own values, so cls.API_TOKEN returns the real credential at runtime and tools such as inspect.getmembers() can reach it. This is inherent to any client-side protection, PyLocket included.

Never treat a protected binary as a safe place to store a secret you would not give to your customer. Server-side secrets belong on your server.

Module Selection

PyLocket automatically determines which modules to protect. By default, only your application code is protected — standard library modules, PyInstaller internals, and common third-party packages are skipped automatically.

You can override this behavior using the PYLOCKET_FORCE_INCLUDE and PYLOCKET_FORCE_EXCLUDE environment variables.

For the full guide, see Module Selection.

See Also