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: Bind Your Build to a Machine, Domain, IP or Expiry

Name: SitrTech Shield
Availability: InStock

Licensing decides where and when your build runs. Here are the binding options, how they're enforced, and why they work offline.

Protecting your source from being read is half the job. The other half is controlling where and when it runs — so a delivered build can't be copied to another server, resold, or used past the contract. That's what licensing does.

The binding options

SitrTech lets you attach one or more rules to a protected build. All of them must pass for the code to run:

Hardware / machine binding — runs only on authorized machines.
Domain binding — runs only under a specific domain.
IP or network-range binding — runs only from allowed addresses.
Expiry date — a time-limited trial or contract window.
Per-customer key isolation — each customer gets a distinct key.

How the rules are enforced

Rather than shipping a separate license file that can be deleted or edited, SitrTech encrypts the rules inside the code itself and enforces them with the compiled native loader at runtime. There's no plain license file to change and no license server to spoof — a build simply won't run outside the rules compiled into it.

Why it works offline

Because the rules travel inside the encrypted build, enforcement doesn't depend on a call home. Your customer's server can be fully air-gapped and the license is still checked at runtime. That matters for on-premise and regulated deployments where outbound connections aren't allowed.

Licensing is strongest with encryption

A licensing check is only as strong as the code around it. If your program ships as readable source, an attacker can patch the check out. When the check lives inside AES-256-GCM ciphertext and is enforced by a compiled loader, that's far harder and impractical for most cases. SitrTech applies both encryption and licensing in a single step.

Common ways teams use it

Per-customer delivery: one build per client, locked to their environment.
Automatic trial expiry for pilots and evaluations.
Contract or subscription enforcement by expiry date.
Preventing a delivered build from spreading to other servers.

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