Data Residency · Sovereignty · Source Handling · Vendor Review

A residency question about a build tool is answered by removing the transfer, not by naming a region.

Security reviews now ask where your source code is processed before they ask what the tool does to it, and that is a reasonable order to ask in. The question has an unusually clean answer here, because the strongest response is not a data centre location. It is that several of these paths never transmit your source at all, and the ones that do can be described exactly rather than approximately.

Security and Processing Security Evidence Packet
The Short Version

Transmitted, or not

Three facts settle most of a residency review before the transform is discussed at all.

Some paths send nothingLocal Standard, paid Local Advanced, and the npm CLI run with --local protect on the machine itself.
The entitlement check is source-freeLocal Advanced confirms your plan over the network without submitting the code it is about to protect.
One capability needs the serviceA build requesting VM bytecode fails with a clear message rather than quietly producing weaker output.
What Is Being Asked

Residency, sovereignty and transfer are three different questions

They arrive in the same paragraph of a questionnaire and they have different answers, so it is worth separating them before answering any of them.

Residency is about where processing happens

The plain form of the question is which country or region a system stores and processes data in. For most software this is answered with a region selector and a contractual commitment, and the review moves on. For a build tool the answer is more interesting, because a large part of the workflow can be arranged so that the data never leaves the machine that created it. At that point the region question stops applying rather than being answered, which is a materially better outcome for both sides.

Sovereignty is about whose law reaches it

A related but distinct concern: which jurisdiction could compel access to the data, regardless of which country the disks are in. This is why an in-region deployment operated by a foreign-headquartered company does not automatically satisfy a sovereignty requirement, and it is a large part of why these questions have become sharper over the last few years. It is also the reason eliminating a transfer beats relocating one, since data that was never sent cannot be produced by the party that never received it.

Transfer is the question you can actually answer

The narrowest and most useful version: what specifically leaves your network, when, and in what form. A build tool can answer this exactly, because the set of things it might transmit is small and enumerable rather than open-ended. Answering the transfer question first usually resolves the other two, and it is the only one of the three that does not depend on facts about somebody else’s infrastructure.

What Each Path Transmits

The paths that send source, and the paths that do not

This is the load-bearing section. The boundary is a product boundary rather than a setting you could misconfigure, which is what makes it worth writing into a review.

Hosted paths send selected JavaScript

The online obfuscator, the npm CLI in its default mode, the Windows Forms client and the WinUI application in hosted mode all send the JavaScript you select to the hosted service, which returns the protected result. Requests are processed for the duration of the request. Large transport payloads may use temporary server storage, which is size limited and removed when the request ends, and source is not retained as part of the normal workflow. The privacy statement carries the formal version of this.

Local paths protect on the machine

WinUI Local Standard runs fully offline and processes plain ES5 .js files. Paid Local Advanced keeps modern .js/.jsx and mixed HTML or server-script source on the workstation, splitting and reassembling those files on-device and writing the protection report locally. Since jso-protector 0.3.0 the npm CLI --local flag runs that same local executable instead of posting to the API, which is what makes the local path available to a build pipeline rather than only to somebody sitting at a desktop.

The entitlement check carries no code

Local Advanced is a paid capability, so it confirms entitlement and option availability over the network. That check carries no source. State this in exactly those terms, because offline and does not transmit source are two different claims, and a reviewer who discovers the difference on their own will reasonably discount the rest of the response. Local Standard, by contrast, is fully offline and needs no such call.

The Boundaries Worth Declaring

Three limits a thorough reviewer will find anyway

Each of these is better volunteered than discovered, and none of them is unusual once it is stated plainly.

The local executable is Windows-only

Source-local protection runs through a Windows executable, so a Linux build agent cannot use it today. In practice teams that need the local path either run a Windows agent for that one step or run the protection on a developer workstation and commit the artefact. It is a real constraint rather than a preference, and quoting it early avoids a review that concludes with a surprise in the last week.

VM bytecode requires the hosted service

VM bytecode protection is produced by the service, so it is not available on a source-local path. The behaviour when the two are combined is worth knowing: the build fails with a clear message rather than silently falling back to weaker output. That is the right failure mode for a compliance-sensitive pipeline, because the alternative is a build that appears to have succeeded while producing something other than what was requested.

The rest of your pipeline is still in scope

A residency review that stops at the obfuscator has usually missed larger transfers. Your CI runner has a region, your artifact registry has a region, and your error monitoring may be receiving stack traces and source maps continuously. Those flows are typically higher volume and more sensitive than a build step. Handling the build tool carefully and leaving the rest unexamined is a common and expensive shape of review.

Answering The Review

Classify the material first, then choose the path

Most of the difficulty in these reviews comes from answering before deciding what kind of data is actually in question.

Source code is usually not personal data

The material in question here is normally your own intellectual property rather than information about a person, and the two attract different frameworks. That distinction is worth making explicitly, because a privacy questionnaire applied unchanged to a build tool produces questions that have no sensible answer. If your source does contain personal data, embedded fixtures and test records being the usual culprits, that is a finding about your repository which is worth acting on regardless of which tool you choose.

Match the requirement to the path

If the requirement is that source must not leave the network, the local paths meet it and the hosted paths do not, and that is the whole decision. If the requirement is a named processing region, that belongs in a contract discussion rather than a documentation page. If the requirement is really about retention, the hosted answer is that requests are processed for the duration of the request and source is not kept as part of the normal workflow.

Write the answer down once

These questions recur with every enterprise customer and the answer does not change between them. A short internal note recording which path your pipeline uses, what that path transmits, and which of the three limits above apply, converts each future questionnaire into an editing job. The evidence packet is the natural home for it, alongside the build records you would be asked for next.

Frequently Asked Questions

Questions security and procurement reviewers ask

Does the online obfuscator upload my source code?

Yes. The online tool, the npm CLI in its default mode, the Windows Forms client and the WinUI application in hosted mode all send the JavaScript you select to the hosted service, which protects it and returns the result. Requests are processed for the duration of the request, large transport payloads may use temporary server storage that is size limited and removed when the request ends, and source is not retained as part of the normal workflow. If your policy is that source must not leave your network, use a source-local path instead of relying on retention behaviour.

Which paths never transmit source code?

WinUI Local Standard, which runs fully offline on plain ES5 files, and paid Local Advanced, which keeps modern .js and .jsx along with mixed HTML or server-script source on the workstation. Since jso-protector 0.3.0 the npm CLI can run that same local executable through the --local flag, which is the option that matters if the requirement has to be met inside a build pipeline rather than by a person working at a desktop.

Is Local Advanced fully offline?

No, and the distinction matters enough to state carefully. Local Advanced keeps your source on the workstation and writes its protection report locally, but because it is a paid capability it makes a source-free entitlement and option check over the network. No code is submitted in that call. Local Standard is the fully offline mode, with the trade-off that it processes plain ES5 files only. Describing Local Advanced as offline in a review would be an overstatement that a reviewer could later find.

Can I use VM bytecode protection without sending source?

No. VM bytecode is produced by the hosted service, so requesting it commits you to the transfer. What the toolchain does not do is quietly resolve that conflict for you: a source-local build that asks for VM bytecode fails with a clear message rather than falling back to weaker output. If your policy forbids the transfer, VM bytecode is off the table and the rest of the transform set remains available locally.

Where is the hosted service processed?

This page does not assert a processing region, because a documentation page is the wrong place to make a commitment that belongs in a contract and that a reviewer would need in writing anyway. If your requirement is a named region or a specific set of subprocessors, raise it directly so it can be answered in a form you can rely on. If your requirement is that source must not leave your network at all, the source-local paths answer it without needing a region at all, which is usually the faster route through the review.

Is source code personal data for residency purposes?

Usually not. Source code is normally the organisation’s own intellectual property rather than information relating to an identified person, which is why privacy frameworks tend to fit it awkwardly. The exception is worth checking rather than assuming: repositories sometimes carry personal data in test fixtures, seed data, sample exports or committed logs. If that is true of yours, it is a finding about the repository that is worth fixing on its own merits, independently of which protection path you choose.

Related Guides

Where to read next

Security and processing

The reference page that states each processing boundary exactly, including what Local Advanced runs on-device.

Security and trust

The wider trust position, including data minimisation and what the service does and does not retain.

Privacy statement

The formal statement of how submitted code is handled on each path, in the language a reviewer will want to quote.

The npm command line

How the automation package fits a pipeline, and what changes when it runs with the local flag.

Next Step

Answer the transfer question once and reuse it

The costly part of these reviews is rediscovering the same three facts under a deadline. Record which path your pipeline uses and what it transmits while nothing is pending, and the next questionnaire becomes a short edit rather than an escalation.

Read Security and Processing Build the Evidence Packet