How to protect Node.js source code when you ship it to customers

You wrote a Node.js application, and it is going to run on a machine you do not control. Whatever you ship, that machine has to be able to run it, so the question is never whether the code can be read. It is what reading it costs, and who holds the key. Four approaches, each described from its own page as read on 17 October 2026, then what Nextweb does and where it stops.

Obfuscation

javascript-obfuscator calls itself "a powerful obfuscator for JavaScript and Node.js". Its README says the output "is still JavaScript", and that "the obfuscated code is 15-80% slower (depends on options)". Obfuscation raises the price of reading the program. It leaves the whole program on the machine, readable by anyone patient, and nothing decides who may run it.

V8 bytecode

bytenode says it "truly compiles your JavaScript code into V8 bytecode, so that you can protect your source code". The source text is removed from the .jsc files it writes, and the README adds two conditions: the files "must run with the same Node.js version that was used to compile it", and code that depends on Function.prototype.toString breaks. Bytecode is the same program in another form. The machine still holds all of it, and there is no key.

Single executable applications

Node.js's own single executable applications feature "allows the distribution of a Node.js application conveniently to a system that does not have Node.js installed". The page marks it "Stability: 1.1 - Active development". The script goes into the executable as a blob that the program finds and runs at start. The page says nothing about hiding the script, because that is not what the feature is for: it is packaging, not protection.

Encrypted on disk, decrypted in memory, with the key held elsewhere

This is what Nextweb does, in two layers.

The package. When you run pkg create, Nextweb encrypts the package with a key made for that one build and seals that key to your account's key, which stays on our license server. The file carries nothing that opens it. The build is registered, so a copy is still that file, and a file changed afterwards or rebuilt is a different file that gets no key. When a server installs the package, Nextweb asks the license server for the key, and the server gets it only if its license is allowed: your own license for a package you publish as yourself, and an organization's members and the servers linked to it for a package the organization owns. Every other license is refused.

nextweb:/> pkg create example-hello 0.1.0

Building example-hello 0.1.0 for example (internal)...
Built and registered dist/example-hello_0.1.0_all.zip.enc
  owner        example (you)
  files        1; source not encrypted
...
Next: pkg validate, then pkg publish.

That is the second lesson's build. The files line says whether the build's source is encrypted, and in that run it is not, which brings in the second layer.

The source. The package's encryption ends when it installs. For a Node.js application you can also keep named source files encrypted on the server after install. Name them in .nextwebrc:

"encrypt": { "source": ["app.js", "lib/**/*.js"] }

Those files stay encrypted on disk. When the application starts, Nextweb gets its key and decrypts each file in memory as Node.js loads it. The plaintext is never written to disk, and your application never sees the key. Each file is checked against the package's file list before it loads, and a changed file stops the application. Source encryption covers .js and .json files, except package.json, which the installer reads before a key exists. Nextweb's own core runs this way. We turn it on for an account on request; until then pkg create refuses a build that asks for it. Package DRM has the full description and the .nextwebrc guide the field.

What it does not do

• Code is decrypted on the machine that runs it, so whoever controls a licensed server can extract what its license opens. Encryption makes a license the cheapest way to get your software; it does not make copying impossible.
• Revoking a build, removing a member or unlinking a server stops the key going to any machine that has not had it. A machine that already holds the key keeps it for up to 7 days.
• Files a server has already installed stay on its disk. Source-encrypted files need the key each time the application starts, and stop loading only once that is refused.
• Any license can download the encrypted file. Only the key is restricted.
• Your account's keys are held by our license server, so publishing a package means trusting it with them. Nextweb is not open source, and it checks its license each time it starts.
• A package installs today on your own license or on the licenses and linked servers of an organization you belong to. A public catalog, where anyone can install a package, is on the roadmap under Not yet; so is a license check that a compiled program can call, and keeping PHP protected after install.

Choosing

Obfuscation runs anywhere and costs speed. Bytecode ties you to one Node.js version and removes the source text. A single executable is a convenient file with the script inside it. All three leave the whole program on the machine with nothing to decide who runs it. Nextweb adds that decision, a key that comes from a server you do not have to run, and files that are never plain on disk, and asks in return that the machine runs Nextweb, reaches the license server at each start, and that you accept the limits above.

Next step

The second lesson packages a small Node.js application, installs it by name, and shares it with a second server. It takes about fifteen minutes.

Questions

Is the source ever written to disk in plain text?

No. Nextweb decrypts each source-encrypted file in memory as Node.js loads it. The plaintext is never written to disk, and your application never sees the key.

Can a customer with root on the server read my code?

With enough patience, yes. The code is decrypted on the machine that runs it, so whoever controls a licensed server can extract what its license opens. Encryption makes a license the cheapest way to get your software; it does not make copying impossible.

Does it protect PHP?

No. After install, PHP files are ordinary files on that server, readable by anyone who can read its disk. Keeping PHP protected after install is on the roadmap under Not yet.

How do I turn source encryption on?

Email support and we enable it for your account. Until then pkg create refuses a build that asks for it. Once it is on, name the files under encrypt.source in .nextwebrc and build again.