Single executable applications | Node.js v24.21.0 Documentation
https://nodejs.org/docs/latest-v24.x/api/single-executable-applications.html • 57 KB fetched
Open original page
Single executable applications | Node.js v24.21.0 Documentation
Skip to content
Node.js
* About this documentation
* Usage and example
* Assertion testing
* Asynchronous context tracking
* Async hooks
* Buffer
* C++ addons
* C/C++ addons with Node-API
* C++ embedder API
* Child processes
* Cluster
* Command-line options
* Console
* Crypto
* Debugger
* Deprecated APIs
* Diagnostics Channel
* DNS
* Domain
* Environment Variables
* Errors
* Events
* File system
* Globals
* HTTP
* HTTP/2
* HTTPS
* Inspector
* Internationalization
* Iterable Streams API
* Modules: CommonJS modules
* Modules: ECMAScript modules
* Modules: node:module API
* Modules: Packages
* Modules: TypeScript
* Net
* OS
* Path
* Performance hooks
* Permissions
* Process
* Punycode
* Query strings
* Readline
* REPL
* Report
* Single executable applications
* SQLite
* Stream
* String decoder
* Test runner
* Timers
* TLS/SSL
* Trace events
* TTY
* UDP/datagram
* URL
* Utilities
* V8
* VM
* WASI
* Web Crypto API
* Web Streams API
* Worker threads
* Zlib
* Code repository and issue tracker
Node.js v24.21.0 documentation
* Node.js v24.21.0
*
Table of contents
* Single executable applications
* Generating single executable preparation blobs
* Assets
* Startup snapshot support
* V8 code cache support
* Execution arguments
* Execution argument extension
* In the injected main script
* Single-executable application API
* sea.isSea()
* sea.getAsset(key[, encoding])
* sea.getAssetAsBlob(key[, options])
* sea.getRawAsset(key)
* sea.getAssetKeys()
* require(id) in the injected main script is not file based
* __filename and module.filename in the injected main script
* __dirname in the injected main script
* Using native addons in the injected main script
* Notes
* Single executable application creation process
* Platform support
*
Index
* About this documentation
* Usage and example
*
Index
* Assertion testing
* Asynchronous context tracking
* Async hooks
* Buffer
* C++ addons
* C/C++ addons with Node-API
* C++ embedder API
* Child processes
* Cluster
* Command-line options
* Console
* Crypto
* Debugger
* Deprecated APIs
* Diagnostics Channel
* DNS
* Domain
* Environment Variables
* Errors
* Events
* File system
* Globals
* HTTP
* HTTP/2
* HTTPS
* Inspector
* Internationalization
* Iterable Streams API
* Modules: CommonJS modules
* Modules: ECMAScript modules
* Modules: node:module API
* Modules: Packages
* Modules: TypeScript
* Net
* OS
* Path
* Performance hooks
* Permissions
* Process
* Punycode
* Query strings
* Readline
* REPL
* Report
* Single executable applications
* SQLite
* Stream
* String decoder
* Test runner
* Timers
* TLS/SSL
* Trace events
* TTY
* UDP/datagram
* URL
* Utilities
* V8
* VM
* WASI
* Web Crypto API
* Web Streams API
* Worker threads
* Zlib
* Code repository and issue tracker
*
Other versions
* 26.x
* 25.x
* 24.x LTS
* 23.x
* 22.x LTS
* 21.x
* 20.x
* 19.x
*
Options
*
View on single page
*
View as JSON
* Edit on GitHub
Table of contents
* Single executable applications
* Generating single executable preparation blobs
* Assets
* Startup snapshot support
* V8 code cache support
* Execution arguments
* Execution argument extension
* In the injected main script
* Single-executable application API
* sea.isSea()
* sea.getAsset(key[, encoding])
* sea.getAssetAsBlob(key[, options])
* sea.getRawAsset(key)
* sea.getAssetKeys()
* require(id) in the injected main script is not file based
* __filename and module.filename in the injected main script
* __dirname in the injected main script
* Using native addons in the injected main script
* Notes
* Single executable application creation process
* Platform support
Single executable applications #
History
Version Changes
v20.6.0
Added support for "useSnapshot".
v20.6.0
Added support for "useCodeCache".
v19.7.0, v18.16.0
Added in: v19.7.0, v18.16.0
Stability: 1.1 - Active development
Source Code: src/node_sea.cc
This feature allows the distribution of a Node.js application conveniently to a
system that does not have Node.js installed.
Node.js supports the creation of single executable applications by allowing
the injection of a blob prepared by Node.js, which can contain a bundled script,
into the node binary. During start up, the program checks if anything has been
injected. If the blob is found, it executes the script in the blob. Otherwise
Node.js operates as it normally does.
The single executable application feature currently only supports running a
single embedded script using the CommonJS module system.
Users can create a single executable application from their bundled script
with the node binary itself and any tool which can inject resources into the
binary.
Here are the steps for creating a single executable application using one such
tool, postject :
*
Create a JavaScript file:
echo 'console.log(`Hello, ${process.argv[2]}!`);' > hello.js copy
*
Create a configuration file building a blob that can be injected into the
single executable application (see
Generating single executable preparation blobs for details):
echo '{ "main": "hello.js", "output": "sea-prep.blob" }' > sea-config.json copy
*
Generate the blob to be injected:
node --experimental-sea-config sea-config.json copy
*
Create a copy of the node executable and name it according to your needs:
* On systems other than Windows:
cp $( command -v node) hello copy
* On Windows:
node -e "require('fs').copyFileSync(process.execPath, 'hello.exe')" copy
The .exe extension is necessary.
*
Remove the signature of the binary (macOS and Windows only):
* On macOS:
codesign --remove-signature hello copy
* On Windows (optional):
signtool can be used from the installed Windows SDK . If this step is
skipped, ignore any signature-related warning from postject.
signtool remove /s hello.exe copy
*
Inject the blob into the copied binary by running postject with
the following options:
* hello / hello.exe - The name of the copy of the node executable
created in step 4.
* NODE_SEA_BLOB - The name of the resource / note / section in the binary
where the contents of the blob will be stored.
* sea-prep.blob - The name of the blob created in step 1.
* --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 - The
fuse used by the Node.js project to detect if a file has been injected.
* --macho-segment-name NODE_SEA (only needed on macOS) - The name of the
segment in the binary where the contents of the blob will be
stored.
To summarize, here is the required command for each platform:
*
On Linux:
npx postject hello NODE_SEA_BLOB sea-prep.blob \
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 copy
*
On Windows - PowerShell:
npx postject hello.exe NODE_SEA_BLOB sea -prep .blob `
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 copy
*
On Windows - Command Prompt:
npx postject hello.exe NODE_SEA_BLOB sea-prep.blob ^
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 copy
*
On macOS:
npx postject hello NODE_SEA_BLOB sea-prep.blob \
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 \
--macho-segment-name NODE_SEA copy
*
Sign the binary (macOS and Windows only):
* On macOS:
codesign --sign - sea copy
* On Windows (optional):
A certificate needs to be present for this to work. However, the unsigned
binary would still be runnable.
signtool sign /fd SHA256 sea.exe copy
*
Run the binary:
* On systems other than Windows
$ ./sea world
Hello, world! copy
* On Windows
$ .\sea.exe world
Hello, world! copy
Generating single executable preparation blobs #
Single executable preparation blobs that are injected into the application can
be generated using the --experimental-sea-config flag of the Node.js binary
that will be used to build the single executable. It takes a path to a
configuration file in JSON format. If the path passed to it isn't absolute,
Node.js will use the path relative to the current working directory.
The configuration currently reads the following top-level fields:
{
"main" : "/path/to/bundled/script.js" ,
"output" : "/path/to/write/the/generated/blob.blob" ,
"disableExperimentalSEAWarning" : true , // Default: false
"useSnapshot" : false , // Default: false
"useCodeCache" : true , // Default: false
"execArgv" : [ "--no-warnings" , "--max-old-space-size=4096" ] , // Optional
"execArgvExtension" : "env" , // Default: "env", options: "none", "env", "cli"
"assets" : { // Optional
"a.dat" : "/path/to/a.dat" ,
"b.txt" : "/path/to/b.txt"
}
} copy
If the paths are not absolute, Node.js will use the path relative to the
current working directory. The version of the Node.js binary used to produce
the blob must be the same as the one to which the blob will be injected.
Note: When generating cross-platform SEAs (e.g., generating a SEA
for linux-x64 on darwin-arm64 ), useCodeCache and useSnapshot
must be set to false to avoid generating incompatible executables.
Since code cache and snapshots can only be loaded on the same platform
where they are compiled, the generated executable might crash on startup when
trying to load code cache or snapshots built on a different platform.
Assets #
Users can include assets by adding a key-path dictionary to the configuration
as the assets field. At build time, Node.js would read the assets from the
specified paths and bundle them into the preparation blob. In the generated
executable, users can retrieve the assets using the sea.getAsset() and
sea.getAssetAsBlob() APIs.
{
"main" : "/path/to/bundled/script.js" ,
"output" : "/path/to/write/the/generated/blob.blob" ,
"assets" : {
"a.jpg" : "/path/to/a.jpg" ,
"b.txt" : "/path/to/b.txt"
}
} copy
The single-executable application can access the assets as follows:
const { getAsset, getAssetAsBlob, getRawAsset, getAssetKeys } = require ( 'node:sea' );
// Get all asset keys.
const keys = getAssetKeys ();
console . log (keys); // ['a.jpg', 'b.txt']
// Returns a copy of the data in an ArrayBuffer.
const image = getAsset ( 'a.jpg' );
// Returns a string decoded from the asset as UTF8.
const text = getAsset ( 'b.txt' , 'utf8' );
// Returns a Blob containing the asset.
const blob = getAssetAsBlob ( 'a.jpg' );
// Returns an ArrayBuffer containing the raw asset without copying.
const raw = getRawAsset ( 'a.jpg' ); copy
See documentation of the sea.getAsset() , sea.getAssetAsBlob() ,
sea.getRawAsset() and sea.getAssetKeys() APIs for more information.
Startup snapshot support #
The useSnapshot field can be used to enable startup snapshot support. In this
case, the main script would not be executed when the final executable is launched.
Instead, it would be run when the single executable application preparation
blob is generated on the building machine. The generated preparation blob would
then include a snapshot capturing the states initialized by the main script.
The final executable, with the preparation blob injected, would deserialize
the snapshot at run time.
When useSnapshot is true, the main script must invoke the
v8.startupSnapshot.setDeserializeMainFunction() API to configure code
that needs to be run when the final executable is launched by the users.
The typical pattern for an application to use snapshot in a single executable
application is:
* At build time, on the building machine, the main script is run to
initialize the heap to a state that's ready to take user input. The script
should also configure a main function with
v8.startupSnapshot.setDeserializeMainFunction() . This function will be
compiled and serialized into the snapshot, but not invoked at build time.
* At run time, the main function will be run on top of the deserialized heap
on the user machine to process user input and generate output.
The general constraints of the startup snapshot scripts also apply to the main
script when it's used to build snapshot for the single executable application,
and the main script can use the v8.startupSnapshot API to adapt to
these constraints. See
documentation about startup snapshot support in Node.js .
V8 code cache support #
When useCodeCache is set to true in the configuration, during the generation
of the single executable preparation blob, Node.js will compile the main
script to generate the V8 code cache. The generated code cache would be part of
the preparation blob and get injected into the final executable. When the single
executable application is launched, instead of compiling the main script from
scratch, Node.js would use the code cache to speed up the compilation, then
execute the script, which would improve the startup performance.
Note: import() does not work when useCodeCache is true .
Execution arguments #
The execArgv field can be used to specify Node.js-specific
arguments that will be automatically applied when the single
executable application starts. This allows application developers
to configure Node.js runtime options without requiring end users
to be aware of these flags.
For example, the following configuration:
{
"main" : "/path/to/bundled/script.js" ,
"output" : "/path/to/write/the/generated/blob.blob" ,
"execArgv" : [ "--no-warnings" , "--max-old-space-size=2048" ]
} copy
will instruct the SEA to be launched with the --no-warnings and
--max-old-space-size=2048 flags. In the scripts embedded in the executable, these flags
can be accessed using the process.execArgv property:
// If the executable is launched with `sea user-arg1 user-arg2`
console . log (process. execArgv );
// Prints: ['--no-warnings', '--max-old-space-size=2048']
console . log (process. argv );
// Prints ['/path/to/sea', 'path/to/sea', 'user-arg1', 'user-arg2'] copy
The user-provided arguments are in the process.argv array starting from index 2,
similar to what would happen if the application is started with:
node --no-warnings --max-old-space-size=2048 /path/to/bundled/script.js user-arg1 user-arg2 copy
Execution argument extension #
The execArgvExtension field controls how additional execution arguments can be
provided beyond those specified in the execArgv field. It accepts one of three string values:
* "none" : No extension is allowed. Only the arguments specified in execArgv will be used,
and the NODE_OPTIONS environment variable will be ignored.
* "env" : (Default) The NODE_OPTIONS environment variable can extend the execution arguments.
This is the default behavior to maintain backward compatibility.
* "cli" : The executable can be launched with --node-options="--flag1 --flag2" , and those flags
will be parsed as execution arguments for Node.js instead of being passed to the user script.
This allows using arguments that are not supported by the NODE_OPTIONS environment variable.
For example, with "execArgvExtension": "cli" :
{
"main" : "/path/to/bundled/script.js" ,
"output" : "/path/to/write/the/generated/blob.blob" ,
"execArgv" : [ "--no-warnings" ] ,
"execArgvExtension" : "cli"
} copy
The executable can be launched as:
./my-sea --node-options="--trace-exit" user-arg1 user-arg2 copy
This would be equivalent to running:
node --no-warnings --trace-exit /path/to/bundled/script.js user-arg1 user-arg2 copy
In the injected main script #
Single-executable application API #
The node:sea builtin allows interaction with the single-executable application
from the JavaScript main script embedded into the executable.
sea.isSea() #
Added in: v21.7.0, v20.12.0
* Returns: <boolean> Whether this script is running inside a single-executable
application.
sea.getAsset(key[, encoding]) #
Added in: v21.7.0, v20.12.0
This method can be used to retrieve the assets configured to be bundled into the
single-executable application at build time.
An error is thrown when no matching asset can be found.
* key <string> the key for the asset in the dictionary specified by the
assets field in the single-executable application configuration.
* encoding <string> If specified, the asset will be decoded as
a string. Any encoding supported by the TextDecoder is accepted.
If unspecified, an ArrayBuffer containing a copy of the asset would be
returned instead.
* Returns: <string> | <ArrayBuffer>
sea.getAssetAsBlob(key[, options]) #
Added in: v21.7.0, v20.12.0
Similar to sea.getAsset() , but returns the result in a <Blob> .
An error is thrown when no matching asset can be found.
* key <string> the key for the asset in the dictionary specified by the
assets field in the single-executable application configuration.
* options <Object>
* type <string> An optional mime type for the blob.
* Returns: <Blob>
sea.getRawAsset(key) #
Added in: v21.7.0, v20.12.0
This method can be used to retrieve the assets configured to be bundled into the
single-executable application at build time.
An error is thrown when no matching asset can be found.
Unlike sea.getAsset() or sea.getAssetAsBlob() , this method does not
return a copy. Instead, it returns the raw asset bundled inside the executable.
For now, users should avoid writing to the returned array buffer. If the
injected section is not marked as writable or not aligned properly,
writes to the returned array buffer is likely to result in a crash.
* key <string> the key for the asset in the dictionary specified by the
assets field in the single-executable application configuration.
* Returns: <ArrayBuffer>
sea.getAssetKeys() #
Added in: v24.8.0
* Returns <string[]> An array containing all the keys of the assets
embedded in the executable. If no assets are embedded, returns an empty array.
This method can be used to retrieve an array of all the keys of assets
embedded into the single-executable application.
An error is thrown when not running inside a single-executable application.
require(id) in the injected main script is not file based #
require() in the injected main script is not the same as the require()
available to modules that are not injected. It also
Links found on this page
- Skip to content [direct]
- Node.js [direct]
- About this documentation [direct]
- Usage and example [direct]
- Assertion testing [direct]
- Asynchronous context tracking [direct]
- Async hooks [direct]
- Buffer [direct]
- C++ addons [direct]
- C/C++ addons with Node-API [direct]
- C++ embedder API [direct]
- Child processes [direct]
- Cluster [direct]
- Command-line options [direct]
- Console [direct]
- Crypto [direct]
- Debugger [direct]
- Deprecated APIs [direct]
- Diagnostics Channel [direct]
- DNS [direct]
- Domain [direct]
- Environment Variables [direct]
- Errors [direct]
- Events [direct]
- File system [direct]
- Globals [direct]
- HTTP [direct]
- HTTP/2 [direct]
- HTTPS [direct]
- Inspector [direct]
- Internationalization [direct]
- Iterable Streams API [direct]
- Modules: CommonJS modules [direct]
- Modules: ECMAScript modules [direct]
- Modules: node:module API [direct]
- Modules: Packages [direct]
- Modules: TypeScript [direct]
- Net [direct]
- OS [direct]
- Path [direct]
- Performance hooks [direct]
- Permissions [direct]
- Process [direct]
- Punycode [direct]
- Query strings [direct]
- Readline [direct]
- REPL [direct]
- Report [direct]
- SQLite [direct]
- Stream [direct]
- String decoder [direct]
- Test runner [direct]
- Timers [direct]
- TLS/SSL [direct]
- Trace events [direct]
- TTY [direct]
- UDP/datagram [direct]
- URL [direct]
- Utilities [direct]
- V8 [direct]
- VM [direct]
- WASI [direct]
- Web Crypto API [direct]
- Web Streams API [direct]
- Worker threads [direct]
- Zlib [direct]
- Code repository and issue tracker [direct]
- Index [direct]
- 26.x [direct]
- 25.x [direct]
- 23.x [direct]
- 22.x LTS [direct]
- 21.x [direct]
- 20.x [direct]
- 19.x [direct]
- View on single page [direct]
- View as JSON [direct]
- Edit on GitHub [direct]
- src/node_sea.cc [direct]
- single executable applications [direct]