Developers
Proprietary applications with .jfpkg
Deliver your machine's HMI and process logic as a compiled application while keeping your source private.
Your machine's interface, process sequences, and device integration represent real engineering work. JetFlight lets you deliver that work as a compiled .jfpkg application while keeping your original source in-house.
Customers receive the application they need to operate the machine. You retain the readable source used to develop, maintain, and extend it. Manufacturer-authored applications can remain closed source; using JetFlight does not require publishing your own application code.
The runtime and the application
JetFlight is the runtime. It provides the motion engine, scripting environment, native HMI widgets, and supported device interfaces.
A .jfpkg is your application. It bundles compiled scripts and application assets into one file that JetFlight loads. Your branding, operator workflow, process logic, and device adapters can travel together in a versioned machine application.
| You maintain privately | You deliver to the machine |
|---|---|
| Readable source and development history | Compiled .jfpkg application |
| Internal engineering notes and development tools | Matching JetFlight executable |
| Private build inputs | Required machine configuration and assets |
| Your update and maintenance process | Operator documentation and applicable license notices |
Keep readable source out of the delivery
The package builder compiles .js files into bytecode: instructions for JetFlight's scripting engine, rather than the original JavaScript text. Customers cannot simply open those packaged modules in a text editor and copy your readable implementation.
That provides a practical barrier to casual source inspection and reuse. It supports closed-source OEM distribution without requiring you to hand over the project that created the application.
Compiled does not mean encrypted or copy-protected. The package itself can be copied, and a determined person can inspect its bytecode and reconstruct logic. Assets are stored as ordinary data, and strings or other metadata can remain visible. Keep credentials and private keys outside the package. Packaging alone does not add machine locking, license enforcement, or a guarantee against reverse engineering.
Build a clean application package
Work from readable source during development. For delivery, prepare a clean application directory containing main.js, the modules it needs, and only the assets you intend to ship.
my-hmi/
main.js
lib/
process.js
device-adapter.js
assets/
logo.png
Build the package with the JetFlight executable selected for the deployment:
JetFlight --build ./my-hmi -o ./MyMachine.jfpkg
The builder includes files recursively. It compiles .js files and includes other files unchanged, so keep source backups, source maps, repository metadata, credentials, and internal documents out of that directory. Write the output outside the input directory, as shown above.
Test with the same JetFlight binary that built the package. Treat the runtime and application as a matched release; rebuild and verify the application when changing the runtime. Do not assume bytecode compatibility across runtime builds or target platforms.
Deliver, start, and update
A launcher starts the packaged application:
JetFlight --run ./MyMachine.jfpkg
On a dedicated control computer, an OEM startup script can launch it directly into the machine HMI. See JC3 Appliance controls for startup and display integration. On Windows the executable is JetFlight.exe; on macOS/Linux, use ./JetFlight when launching it from the current directory.
Keep a tested runtime/package pair and its machine configuration together for each machine revision. Develop updates in your private source project, build a new package, and validate it in simulation before commissioning it on hardware. Retain the previous working deployment for recovery.
Your application and the starter ecosystem
JetFlight's runtime and core firmware remain closed source and free to download. Your own application can use your own licensing and remain closed source.
Our planned open-source HMI and peripheral starters are a separate offering, intended for commercial reuse. When using a published starter or any third-party component, follow its actual license and retain required notices. Compilation does not change those obligations.
Start with native HMI and scripting for an original sensor-panel example, or distributed automation for an application that coordinates several stations.
Reviewed 2026-11-06. Confirm the hardware catalog and current published release before connecting a machine.