Docs / Overview
Everything you need to protect a Python codebase with Nyami: the settings that drive the pipeline, the dashboard and API that submit to it, and what each protection layer actually defends against.
Nyami takes a Python file and returns a hardened artifact that still runs. It is not a wrapper around the interpreter and not a scrambler that renames a few symbols. Source, bytecode, encryption and runtime defence are all handled in a single pass, and every build is structurally different from the last.
The default output. A single file that still imports like a normal Python module, so it drops into existing code with no packaging change.
The bytecode is packed into an in-memory container, with either decoy entries or a minimal single-entry layout. Smaller output and a faster build.
Your source is compiled to a native extension through Cython. No Python source reaches the customer, and it still presents the usual module interface.
A PyInstaller build wraps everything into a standalone executable, with the import resolution handled for you.
A submission moves through five stages. You control how deep each one goes through the settings, but none of them are skipped entirely.
| Stage | What happens |
|---|---|
| 1. Prepare | The source is parsed and mapped, then given random identifiers, stripped of comments and docstrings, and rewritten with mixed-format numeric literals. |
| 2. Lower | Builtin call sites are moved out of Python and into the native kernel across 14 families, so the operations your code performs are no longer recognisable Python calls. |
| 3. Obfuscate | Strings are encrypted, function bodies are wrapped or compressed, control flow is flattened, and decoys are injected so the structure no longer matches the original. |
| 4. Harden | Decompiler-specific corruption is applied, integrity verification is embedded, and the runtime monitors that watch for tampering are installed. |
| 5. Seal | The whole payload is encrypted, white-box wrapped, compressed, and emitted through one of the four output modes above. |
Both surfaces submit the same job to the same engine and debit the same credit balance. They differ only in authentication and in how much control they expose. The command line client still ships as part of the product, but it is not covered by these docs.
| Surface | Authentication | Best suited to |
|---|---|---|
| Dashboard | Your account session | Trying options and protecting one file at a time without handling keys. |
| HTTP API | An API key on an API plan | Build scripts, CI/CD pipelines, and anything that protects on every tag. |
The dashboard is the quickest path because your session already carries an internal key. External API keys are issued only on an API plan, and the full key is shown once at creation, so store it in a secret manager or an environment variable.
You can target Python 3.10, 3.11, 3.12, 3.13 or 3.14. The emitted artifact carries a version lock covering the interpreter minor version, operating system, architecture and pointer size, so running the output under the wrong interpreter fails immediately with a clear message instead of a confusing runtime error further in.
The native protection layer is compiled for Windows by default and can be targeted at Linux instead. Compiling the artifact itself to a native extension requires Cython on the build machine, and packaging to an executable requires PyInstaller.
Every obfuscation, whether it comes from the dashboard or the API, debits one credit from a finite balance. Nothing is unlimited, on any plan. That is deliberate: it is what keeps a scripted wrapper of the dashboard no cheaper than using the API properly.
| Plan | Allowance | Notes |
|---|---|---|
| Pay as you go | 1 credit, no expiry | One obfuscation, no subscription. |
| Starter | 50 credits over 30 days | Dashboard access. |
| Starter API | 100 credits over 30 days | Adds external API keys. |
| Pro | 1000 credits over 30 days | Dashboard access and the priority queue. |
| Pro API | 500 credits over 30 days | External API keys. |
| Business | 1000 credits over 30 days | API only, built for teams and CI/CD. |
Refilling a bucket that is still funded adds bonus days, capped per bucket. Credits are consumed in the same transaction that creates the job, so a failed job does not leave a half-charged account behind.
The API path in full is three calls: submit, poll, download. This example protects one file.
curl -X POST https://nyami.cc/api/obfuscate \
-H "X-API-Key: nyami_your_key_here" \
-F "file=@script.py" \
-F 'settings={"optimization":"1","python_version":"3.14","anti_debug":"none"}'{
"jobId": "clx0a1b2c3d4e5f6g7h8i9j0",
"message": "Job submitted successfully. Poll GET /api/obfuscate/[jobId] for status."
}Poll that job id until it reports COMPLETED, then fetch the signed download URL it returns. The full walkthrough, including a complete Python client and every error the endpoint can return, is in the quickstart.
Protect your first Python file in under five minutes, through the dashboard or the API.
Every obfuscation setting, its accepted values, and what it does.
Endpoints, authentication, job lifecycle, limits and error codes.
What each layer of the pipeline does and what it defends against.
Machine-locked builds, trial windows and how the two interact.
The failure modes you are most likely to hit, and how to clear them.
Most problems are covered in troubleshooting. If yours is not, the Discord is monitored by the people who build the engine.