Which frameworks does SitrTech support?

Python: Odoo, Frappe/ERPNext, Django, Flask, FastAPI and Tornado. PHP: WordPress, Laravel and generic PHP projects — nine frameworks in total.

How does SitrTech protect my source code?

Every file is sealed with authenticated AES-256-GCM under its own unique key, then executed by a compiled per-OS/arch/Python native loader. The master key lives only inside that native binary, never in readable code, and each build can be bound to an expiry, domain, IP range, MAC, machine-id, hostname, disk serial or Odoo database.

Will encryption slow down my application?

The impact is negligible. Protected code runs at ordinary Python speed once loaded — there is only a one-time load per module at first import (about 0.1s), and the app then runs fully offline with no per-call cost.

Does my source code get uploaded to SitrTech?

In local mode your source never leaves your machine — encryption runs on your side and only line counts are metered for billing.

Can I lock a protected build to a customer or a machine?

Yes. You can bind a build to an expiry date, a domain, an IP/CIDR range, a MAC address, a machine-id, a hostname, a disk serial or an Odoo database. The rules are enforced locally at runtime and cannot be edited or bypassed.

What platforms does the protected code run on?

Python 3.8 to 3.14 on Linux, macOS and Windows. The same protected build runs everywhere, including fully offline.

Protecting Python Code from Reverse-Engineering

Compiling to .pyc and renaming symbols won't stop a determined analyst. Here's what actually raises the cost of reverse-engineering Python.

Python is wonderful to write and, unfortunately, wonderful to read back. If you distribute a Python application or module, anyone who receives it can inspect your logic. Let's look at what does and doesn't protect it.

Why .pyc files aren't protection

Shipping compiled .pyc bytecode feels safer than shipping .py, but it isn't. Decompilers reconstruct readable Python from bytecode with high fidelity, especially for the CPython versions most projects target. Bytecode is an implementation detail, not a security boundary.

Why obfuscation only slows things down

Renaming symbols and mangling control flow raises the effort to read your code, but the logic is still present and still runs as-is. Given time, an analyst can recover a working, readable approximation. Obfuscation is a speed bump, not a wall.

Encrypting the source itself

The stronger approach is to make the source unreadable at rest. SitrTech encrypts each .py file with AES-256-GCM and injects a compiled native loader that decrypts files in memory at import. There's no plaintext program in the shipped build to decompile — just ciphertext and a loader — which makes reverse-engineering far harder and impractical for most real-world attackers.

Every .py file is encrypted; your entry point stays runnable.
Decryption happens once at import, then code runs at native speed.
Third-party pip packages are left as-is, so the app keeps working.
Licensing rules can be embedded and enforced offline.

Pair it with licensing

Reverse-engineering isn't the only risk — unlicensed running and redistribution are too. Because SitrTech encrypts and licenses in one step, you can bind a build to a machine, domain, IP range or expiry so it only runs where and when you allow, even with no network connection.

An honest word on limits

Encrypted code has to be decrypted to run, so no scheme is absolute. The goal is to move the economics decisively in your favour: turning a quick decompile into an impractical amount of work against ciphertext and a compiled loader. For paid software delivered to customers, that's usually the difference that matters.

Get started with SitrTech · read the documentation or browse more articles.