Obfuscate JavaScript inside a Cloudflare Worker

"AfterPack in a Worker" means one of three things, and they are not interchangeable. The Free engine can run inside your Worker today, as a WebAssembly module you install from npm. Pro runs in AfterPack's cloud, reachable from a Worker like from anywhere else. An AfterPack-operated Pro that runs inside your Workers for Platforms account is roadmapped and does not exist yet.

This page covers all three, in that order.

The Free engine, inside your own Worker

@afterpack/wasm is the Free engine compiled to WebAssembly. It is the same Rust engine the CLI and the framework plugins run, built for wasm32 instead of your machine's architecture.

npm install @afterpack/wasm

import { obfuscate } from "@afterpack/wasm";

export default {
  async fetch(request) {
    const source = await request.text();
    const result = await obfuscate({ path: "app.js", source }, { preset: "hard" });
    return new Response(result.bytes, {
      headers: { "content-type": "application/javascript" },
    });
  },
};

That is the whole integration. No init call, no nodejs_compat flag, no wrangler rule for the .wasm file. The module has no WebAssembly imports, so it instantiates synchronously the first time you call obfuscate, and the package's exports map hands your bundler a Worker-shaped entry on its own. The same import works in Node, where a different entry reads the binary off disk.

The surface is identical to @afterpack/core — obfuscate, obfuscateAll, version, all async, all throwing on a build that cannot ship. Configuration is the same object documented on Configuration, including preset and seed.

What it costs you

The engine binary ships inside the package, already compiled.

Cloudflare's Worker size limit is 3 MB compressed on the free plan and 10 MB on paid, so the engine fits either. What the free plan does not fit is the work: it caps CPU at 10 ms per invocation, and obfuscating a 185 KB bundle at complexity 8 takes a few hundred milliseconds. Anything past a demo wants Workers Paid.

A Worker that obfuscates the same asset on every request pays that CPU every time. Caching the result for a rotation window, or doing the work in your build and serving the output, keeps the bill down where a new shape per request is not what you are after.

What the package you host can and cannot do

The .wasm you install performs Free protection. Pro transforms run only on AfterPack's infrastructure, so the package holds nothing to unlock: no key check to bypass, no switch that turns a hosted copy into a Pro build. A key routes work to the cloud; it does not enable anything locally.

The published package carries an npm provenance record — package version, the workflow that built it, and the artifact digest — so you can tie the bytes you installed to the build that produced them.

Pro, today: the cloud API

The Pro engine is not part of this package and will not be. It runs only on AfterPack's own infrastructure; that is the point of the tier boundary above. What the package does carry is the client for it.

Reaching it from a Worker is the same call you already write: pass a key to @afterpack/wasm and the same obfuscate() runs Pro. The package makes the Pro request to POST /v1/obfuscate/batch under the hood, so a Worker never codes the API by hand. The Cloud API reference is the full wire contract, and Deployment modes explains what changes when the engine moves.

Two consequences worth being explicit about. Your source leaves your Worker and is processed in AfterPack's cloud — in memory, not persisted, per Privacy & data handling. And the build fails closed if the cloud cannot be reached.

Roadmapped: AfterPack-operated Pro on Workers for Platforms

The shape that does not exist yet: an AfterPack-supplied wrapper for Workers, running inside a Workers for Platforms dispatch namespace. There is no package to install and no worker-to-worker request — the Pro build executes at the edge without a round trip out of Cloudflare's network.

It is on the roadmap and has no date. Nothing on this page depends on it, and Deployment modes describes what ships today. For the requirement "source must never leave our infrastructure", the answer is the Free local engine — not a future edge product.

Choosing

Next

• Deployment modes: local versus cloud, and what each one stores.
• Cloud API reference: the contract a Worker calls for Pro builds.
• Configuration: every key both packages accept.
• Tiers: what Free includes, and what Pro adds.
• Privacy & data handling: what leaves your machine in each mode.