Deployment modes: run the engine locally or in the cloud

A deployment mode changes where the work happens and what touches your source. It does not change what the transforms do: the same input and the same settings produce the same protection wherever the engine runs. AfterPack runs in two modes.

Mode 1: Local (Free)

npx afterpack@latest <path> runs the free-tier engine natively on your machine, and so does every framework plugin with no key configured. Your source never leaves your filesystem. Install, build, done. No account, no key, no network round trip for the obfuscation itself.

This is the default path and the one almost every build should take.

Two Pro-only settings behave differently here: the hardening flags transforms.selfIntegrity.enabled and transforms.comparisonHardening.enabled are not applied, and a per-region @afterpack directive stops the build. See Pro.

One network call that isn't obfuscation

A build that emits an error or critical diagnostic reports anonymous build diagnostics: code, severity, versions, bucketed counts, never source. A clean build sends nothing. Turn it off with AFTERPACK_telemetry_enabled=false, or telemetry.enabled in your plugin options. Details in Privacy & data handling.

Mode 2: AfterPack cloud (Pro)

Same package, plus a key. It is an ordinary configuration key, settable the three ways every other key is: --key=ap_v1_… on the command line, AFTERPACK_key=ap_v1_… in the environment, or "key" in afterpack.json. The flag wins over the environment, which wins over the file; Configuration has the full precedence rule.

A key belongs in the environment, not on the command line

--key= is there for a one-off local run. A command line lands in shell history, CI logs and ps output, so use AFTERPACK_key for anything shared. There is no sign-in step and no separate credential: the key from the dashboard is the whole of it.

When a key resolves, the engine batches your files and calls POST /v1/obfuscate/batch. The cloud runs the Pro engine build and streams obfuscated output back as each file completes; your build writes each result as it arrives. Source is processed in memory only and is not persisted. One artifact is stored: the per-build Protection Map that powers the dashboard, which you can switch off per project. The full wire contract is the Cloud API reference.

Cloud-down fails closed. If the cloud is unreachable (DNS failure, connection refused, retries exhausted against a 5xx, or a request timeout), the build fails rather than dropping to Free-tier output. Diagnostics owns that rule and the exit codes behind it.

The client retries 503/504 on a 1 s / 4 s / 16 s schedule (four attempts total) and honors a 429's Retry-After exactly once before giving up. Every other status is non-retryable and surfaces as a build failure with the API's own diagnostic code.

Choosing between them

Situation	Mode
Default: zero friction, nothing leaves your machine	Mode 1 (Local)
You want per-region directives actually honored	Mode 2 (Cloud)
You want stored Protection Maps and build history in the dashboard	Mode 2 (Cloud)
Compliance says source may not leave your infrastructure	Mode 1 (Local)

Other deployment shapes

AfterPack on Edge

The engine is small enough to run inside a Cloudflare Worker, and that is where cloud builds run today: your bundle is transformed in a Worker isolate and returned in milliseconds. You can run the free engine in your own Worker the same way: see Running AfterPack in a Cloudflare Worker.

Having AfterPack serve per-request or per-rotation-window shapes for you, rather than you running the Worker, is on the public roadmap and not available today.

Source that may not leave your infrastructure

Mode 1 already answers this: Free, local, no network call, nothing to review. For a Pro engine running inside your own account, see Enterprise; it is not something you can switch on today.