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.

Software Licensing & Binding

Name: SitrTech Shield
Availability: InStock

SitrTech adds licensing to your protected builds so each release only runs where and when you allow. Combine any of the binding rules — they are encrypted inside each file and enforced by the compiled loader at runtime, so they are very difficult to edit or bypass.

Use it to control per-customer delivery, stop unpaid redistribution, and ship time-limited trials.

Because the rules live inside the encrypted code rather than in a separate license file, they travel with the build and apply even with no network connection.

Binding options

Mix and match the rules that fit your business.

Hardware / machine binding
Domain binding
IP or network range binding
Expiry date (time-limited trials or contracts)
Per-customer key isolation, so each customer gets a distinct key

Enforced at runtime, offline

Because rules live inside the encrypted files and are checked by the native loader, they travel with the build and apply offline. There is no separate license file to delete and no license server to spoof — a build simply won't run outside the rules compiled into it.

Common use cases

What licensing unlocks for your business.

Per-customer delivery: one build per client, locked to their environment
Time-limited trials and pilots that expire automatically
Contract/subscription enforcement by expiry date
Preventing a delivered build from being copied to another server

Licensing + encryption together

Licensing is strongest when the code is also encrypted: an attacker can't simply patch out a check that lives inside AES-256-GCM ciphertext and is enforced by a compiled loader. SitrTech applies both in one step.

Frequently asked questions

Can I issue time-limited trials?

Yes — set an expiry date so a build stops running after the trial or contract window.

Does licensing work offline?

Yes — the rules are enforced by the compiled loader at runtime, so they apply even without a network connection.

Can I combine several binding rules?

Yes — combine hardware, domain, IP and expiry as needed; all of them must pass for the build to run.

What stops someone editing the license rules?

The rules are encrypted inside each file and enforced by the compiled native loader, so they are very difficult to edit or bypass — there is no plain license file to change.

Can each customer get a different key?

Yes — per-customer key isolation gives each customer a distinct key, so one customer's license can never unlock another's build.

Get started · read the documentation or see the capabilities.