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.

How to Protect Odoo Modules Before Delivering Them to Clients

Custom Odoo modules are trivial to copy once the source is in a client's hands. Here's how to deliver them protected and license-bound.

Odoo partners live with a hard problem: the moment you hand a client a custom module, its Python source is on their server in plain text. Nothing stops it being copied to another database, another company, or resold. This guide walks through protecting a module before delivery.

Why Odoo modules are so easy to copy

Odoo loads modules from readable Python files. That's great for development, but it means every model, method and business rule you wrote is sitting in the addons folder for anyone with server access to read, copy or modify. Obfuscation helps a little, but the logic is still recoverable.

Encrypt the Python, keep the manifest readable

SitrTech encrypts your module's .py files with AES-256-GCM while leaving __manifest__.py readable, so Odoo can still discover and load the module. Your models and methods run normally through a compiled native loader; the non-Python assets — XML views, data files, the manifest — are left intact.

# Zip your module, then protect it (CLI example)
zip -r my_module.zip my_module/
sitr encrypt my_module.zip --bind-domain client.example.com --expiry 2027-12-31

License each delivery

Encryption alone stops reading; licensing stops running where you didn't authorize. Bind each build to the client's machine, domain, an IP range, an expiry date, or a combination. The rules are encrypted inside the files and enforced by the loader at runtime, so copying the folder to another server or database won't make it work — and it all applies offline.

Bind a module to one client's server (machine/domain).
Sell the same module to many customers, each build license-bound to them.
Ship a time-limited pilot that expires automatically.
Give each customer a distinct key with per-customer key isolation.

Make it part of your delivery pipeline

Protection shouldn't slow you down. Encrypt modules as a build step from the CLI or the REST API in GitHub Actions, GitLab CI or Docker, so every handover ships protected without a manual chore. SitrTech supports Odoo 13 through the latest releases, on both Community and Enterprise.

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