What Is NVIDIA JetPack? The Jetson Software Stack Explained

NVIDIA JetPack is the software development kit for the Jetson family: it bundles Jetson Linux, NVIDIA’s Ubuntu-based operating system and board support package, with CUDA, cuDNN, TensorRT and the camera, video and vision libraries a Jetson needs to run GPU-accelerated AI. Without it, a Jetson module is a board with an unconfigured processor; with it, the GPU, deep learning accelerators and video engines are driven by one supported stack.

JetPack is what turns NVIDIA Jetson silicon into a usable AI computer on the software side, and the same stack runs across the whole range, from Orin Nano to Thor. It is the same CUDA platform NVIDIA uses on its data-centre GPUs, scaled down to the edge, so tools and models carry over.

This guide explains what is inside JetPack, how it relates to Jetson Linux, how releases line up with modules, how to install and update it, and what changes when a JetPack image moves from a developer kit to a production fleet on industrial carrier boards.

A JetPack release has three layers: the operating system and board support package, the accelerated libraries, and the developer tools. Frameworks for video analytics, robotics and sensor processing install on top.

The operating system and libraries ship together as one versioned release, which is why JetPack is treated as a single stack rather than a set of parts to assemble. Our explainers on NVIDIA Holoscan and ROS cover two of the frameworks most often installed on top, and what NVIDIA Jetson is maps the stack onto the hardware.

Jetson Linux, also called Linux for Tegra or L4T, is the board support package and operating system: the bootloader, kernel, drivers and Ubuntu root filesystem that make the module boot and run. JetPack is Jetson Linux plus the AI, vision and multimedia libraries and the developer tools. Every JetPack release names the Jetson Linux release it is built on, such as JetPack 6 on R36, so the two version numbers always travel together. Our answer on Linux for Tegra covers L4T in more depth.

CUDA is the foundation: every accelerated library on Jetson runs on it, and it is what lets code use the GPU at all. TensorRT is where much of the real-time speed comes from, because it compiles and optimizes a trained model for the exact Jetson it will run on, choosing precision and fusing layers. Because the same libraries run from Orin Nano to Thor, an application moves across modules without a rewrite, though each TensorRT engine is rebuilt for its target.

A new release can change performance as well as compatibility. The Orin Nano Super update raised the same module from 40 to 67 TOPS through JetPack 6.2 alone. Our answer on Jetson Super mode explains how.

From a trained model to a running engine

The engine step is why JetPack versions matter so much in practice. A TensorRT engine is tied to the GPU it was built for and the TensorRT version that built it, so a JetPack upgrade or a module change means rebuilding every engine and re-checking accuracy, especially at lower precision. Our comparison of PyTorch and TensorFlow covers the training side, and AI inference vs training explains why the two run on different hardware.

Each JetPack release supports a particular set of modules and a particular CUDA and TensorRT version, so the release a module is flashed with decides which drivers, libraries and model formats work on it. The table summarizes the main lines.

In practice that means two things. A newer module generation needs a JetPack new enough to support it, and Orin and Thor are on newer lines than Xavier ever reached. And an application built against one JetPack does not move to another without revalidation, because the CUDA and TensorRT versions underneath change. Our answer on NVIDIA JetPack versions covers each release line in more detail, including how to check the version on a running system; always confirm the exact module list in NVIDIA’s release notes before fixing a version.

There are four common routes, and the right one depends on whether the board is a developer kit, a third-party carrier or a production system.

Third-party carriers are the common trap. A carrier’s connectors only work when its device tree and drivers are present, so flash the vendor’s board support package for the JetPack release you want rather than NVIDIA’s developer kit image. If the vendor has not yet released a BSP for the newest JetPack, the carrier stays on the previous line until it does.

Can I upgrade JetPack without reflashing?

Within a major line, often yes. From JetPack 5 onwards, point releases can usually be installed as package updates with apt. Moving between major versions, such as JetPack 5 to 6 or 6 to 7, changes the kernel, the Ubuntu release and the bootloader, so it normally means a reflash. NVIDIA provides over-the-air update tools for some paths; check the release notes and the carrier vendor’s support before relying on them in the field.

JetPack is built around the developer experience: flash a module, install the SDK and start building. A product that ships in volume needs more. Every industrial carrier depends on its vendor’s board support package, and vendors typically follow NVIDIA’s releases by weeks or months, so the carrier, not NVIDIA, often sets which JetPack a system can run.

Containers deserve a note. Many Jetson applications now ship as containers built on NVIDIA’s Jetson base images. The GPU driver lives on the host and is mounted into the container at run time, so a container built for one Jetson Linux major release will not run correctly on another; upgrade the host and containers together. Our explainer on secure boot covers the boot-chain side.

A full JetPack install is large, and much of it, compilers, samples and desktop packages, has no place on a deployed system. Production images are therefore often built with the Yocto Project, which assembles a minimal, reproducible Linux from the Jetson board support package and only the libraries the application needs. Our explainer on embedded Linux sets out why that matters.

JetPack 7.2 brought an officially supported Yocto path for Orin and Thor, which narrows the gap between the two. Our article on JetPack 7.2 and Yocto on Jetson Orin covers what that means for deployed fleets.

For a product, the newest JetPack is not automatically the right one. The version has to support the module, the carrier vendor has to provide a BSP for it, and your application and its dependencies have to be validated on it.

A module that reaches the end of its software line keeps working but receives no new libraries, so choose a module with a long software runway as well as the performance you need. Our Jetson modules comparison sets out the lifecycle of each module, and our guide to Xavier and TX2 end of life covers the move off JetPack 4.6 and 5.1.

The JetPack details below come from each product’s own specification.

We flash each system with the JetPack release and BSP your application is validated on, set the power mode and test it before it ships.