jetson-containers Documentation

Technical Documentation: dusty-nv/jetson-containers

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

CUDA Containers for Edge AI & Robotics

Modular container build system that provides the latest AI/ML packages for NVIDIA Jetson :rocket::robot:

See the packages directory for the full list, including pre-built container images for JetPack/L4T.

Using the included tools, you can easily combine packages together for building your own containers. Want to run ROS2 with PyTorch and Transformers? No problem - just do the system setup, and build it on your Jetson:

$ jetson-containers build --name=my_container pytorch transformers ros:humble-desktop

There are shortcuts for running containers too - this will pull or build a l4t-pytorch image that's compatible:

$ jetson-containers run $(autotag l4t-pytorch)

^{jetson-containers run launches docker run with some added defaults (like --runtime nvidia, mounted /data cache and devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

If you look at any package's readme (like l4t-pytorch), it will have detailed instructions for running it.

Changing CUDA Versions

You can rebuild the container stack for different versions of CUDA by setting the CUDA_VERSION variable:

CUDA_VERSION=12.6 jetson-containers build transformers

It will then go off and either pull or build all the dependencies needed, including PyTorch and other packages that would be time-consuming to compile. There is a Pip server that caches the wheels to accelerate builds. You can also request specific versions of cuDNN, TensorRT, Python, and PyTorch with similar environment variables like here.

Documentation Copy Chapter

• Package List
• Package Definitions
• System Setup
• Building Containers
• Running Containers

Check out the tutorials at the Jetson Generative AI Lab!

Getting Started Copy Chapter

Refer to the System Setup page for tips about setting up your Docker daemon and memory/storage tuning.

# install the container tools
git clone https://github.com/dusty-nv/jetson-containers
bash jetson-containers/install.sh

# automatically pull & run any container
jetson-containers run $(autotag l4t-pytorch)

To also spin up a local devpi PyPI + APT caching server during install, pass --pypi:

sudo bash jetson-containers/install.sh --pypi

This launches a containerized devpi instance with per-architecture indexes (jp6, jp7, sbsa, amd64) and an nginx-based APT cache, so subsequent builds resolve wheels and packages locally instead of hitting the network.

Or you can manually run a container image of your choice without using the helper scripts above:

sudo docker run --runtime nvidia -it --rm --network=host dustynv/l4t-pytorch:r36.2.0

Looking for the old jetson-containers? See the legacy branch.

Only Tested and supported Jetpack 6.2 (Cuda 12.6) and JetPack 7 (CUDA 13.x). Copy Section

[!NOTE]
Ubuntu 24.04 containers for JetPack 6 and JetPack 7 are now available (with CUDA support)

     LSB_RELEASE=24.04 jetson-containers build pytorch:2.8
     jetson-containers run dustynv/pytorch:2.8-r36.4-cu128-24.04

ARM SBSA (Server Base System Architecture) is supported for GH200 / GB200.
To install CUDA 13.0 SBSA wheels for Python 3.12 / 24.04:

     uv pip install torch torchvision torchaudio \
            --index-url https://pypi.jetson-ai-lab.io/sbsa/cu129

See the Ubuntu 24.04 section of the docs for details and a list of available containers 🤗
Thanks to all our contributors from Discord and AI community for their support 🤗

[!IMPORTANT]
Jetson Orin now receives ARM SBSA CUDA in CUDA 13.2 — Starting with CUDA 13.2, the same Arm SBSA CUDA Toolkit is supported on Jetson Orin devices, unifying the toolkit across server-class (GH200/GB200) and embedded (Orin) platforms. This requires JetPack 7.2 with CUDA driver R595 minimum.

Code Style Copy Chapter

The project uses automated code formatting tools to maintain consistent code style. See Code Style Guide for details on:

• Setting up formatting tools
• Adding your package to formatting checks
• Troubleshooting common issues

Troubleshooting Copy Chapter

InvalidDefaultArgInFrom: Default value for ARG ${BASE_IMAGE} results in empty or invalid base image name Copy Section

This may be caused by corrupted caches. Docker caches both image results and build downloads. Try these simple steps first:

• Remove non-essential docker images using: *docker image rm --force *
• Prune resulting docker image cache: docker image prune -f
• Prune docker build image cache: docker buildx prune -f

Gallery Copy Chapter

Multimodal Voice Chat with LLaVA-1.5 13B on NVIDIA Jetson AGX Orin (container: NanoLLM)

Interactive Voice Chat with Llama-2-70B on NVIDIA Jetson AGX Orin (container: NanoLLM)

Realtime Multimodal VectorDB on NVIDIA Jetson (container: nanodb)

NanoOWL - Open Vocabulary Object Detection ViT (container: nanoowl)

Live Llava on Jetson AGX Orin (container: NanoLLM)

Live Llava 2.0 - VILA + Multimodal NanoDB on Jetson Orin (container: NanoLLM)

Small Language Models (SLM) on Jetson Orin Nano (container: NanoLLM)

Realtime Video Vision/Language Model with VILA1.5-3b (container: NanoLLM)

Citation Copy Chapter

Please see CITATION.cff for citation information.

Overview (`packages/README.md`) Copy Section

Packages

ATTENTION BUILD CODE CUDA CV HW LLM ML MULTIMEDIA NET PHYSICAL AI RAG SMART-HOME SPEECH VECTORDB VIT VLM

Attention Copy Chapter

Attention mechanism implementations and optimizations.

Build Copy Chapter

Build tools, compilers, and development dependencies.

Code Copy Chapter

Development environments and IDEs.

CUDA Copy Chapter

CUDA toolkit, libraries, and Python bindings.

CV Copy Chapter

Computer vision, 3D reconstruction, diffusion models, and related packages.

cv/3d/3dobjects Copy Section

cv/3d/3dvision Copy Section

cv/3d/gaussian_splatting Copy Section

cv/3d/nerf Copy Section

cv/diffusion Copy Section

cv (other) Copy Section

HW Copy Chapter

Hardware interfaces and device drivers.

LLM Copy Chapter

Large language model inference, training, quantization, and serving frameworks.

ML Copy Chapter

Machine learning frameworks, PyTorch ecosystem, numeric libraries, and RAPIDS.

ml/pytorch Copy Section

ml/tensorflow Copy Section

ml/jax Copy Section

ml/mamba Copy Section

ml/numeric Copy Section

ml/rapids Copy Section

ml/kans Copy Section

ml/xlstm Copy Section

ml/apache Copy Section

ml (other) Copy Section

ml/l4t Copy Section

Multimedia Copy Chapter

Media processing, video codecs, and streaming.

Net Copy Chapter

Networking, proxies, and self-hosted infrastructure.

PhysicalAI Copy Chapter

Robotics, simulation, embodied AI, and vision-language-action models.

physicalAI/sim Copy Section

physicalAI/vla Copy Section

physicalAI/cosmos Copy Section

physicalAI (other) Copy Section

RAG Copy Chapter

Retrieval-augmented generation and knowledge tools.

Smart-Home Copy Chapter

Home automation, voice assistants, and Wyoming protocol servers.

Speech Copy Chapter

Speech recognition, text-to-speech, and audio processing.

VectorDB Copy Chapter

Vector databases and similarity search.

VIT Copy Chapter

Vision transformer models and segmentation.

VLM Copy Chapter

Vision-language models for multimodal understanding.

Overview (`deprecated/auto_awq/README.md`) Copy Section

auto_awq

CONTAINERS IMAGES RUN BUILD

CONTAINERS

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag auto_awq)

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host auto_awq:35.2.1

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag auto_awq)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag auto_awq) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build auto_awq

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/gptq-for-llama/README.md`) Copy Section

gptq-for-llama

CONTAINERS IMAGES RUN BUILD

CONTAINERS

CONTAINER IMAGES

_{Container images are compatible with other minor versions of JetPack/L4T:
    • L4T R32.7 containers can run on other versions of L4T R32.7 (JetPack 4.6+)
    • L4T R35.x containers can run on other versions of L4T R35.x (JetPack 5.1+)}

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag gptq-for-llama)

# or explicitly specify one of the container images above
jetson-containers run dustynv/gptq-for-llama:r36.2.0

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host dustynv/gptq-for-llama:r36.2.0

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag gptq-for-llama)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag gptq-for-llama) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build gptq-for-llama

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/piper-tts/README.md`) Copy Section

piper-tts

CONTAINERS IMAGES RUN BUILD

CONTAINERS

CONTAINER IMAGES

_{Container images are compatible with other minor versions of JetPack/L4T:
    • L4T R32.7 containers can run on other versions of L4T R32.7 (JetPack 4.6+)
    • L4T R35.x containers can run on other versions of L4T R35.x (JetPack 5.1+)}

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag piper-tts)

# or explicitly specify one of the container images above
jetson-containers run dustynv/piper-tts:r36.4.0-cu128-24.04

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host dustynv/piper-tts:r36.4.0-cu128-24.04

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag piper-tts)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag piper-tts) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build piper-tts

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/shape-llm/README.md`) Copy Section

shape-llm

CONTAINERS IMAGES RUN BUILD

CONTAINERS

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag shape-llm)

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host shape-llm:36.3.0

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag shape-llm)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag shape-llm) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build shape-llm

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/stable-diffusion/README.md`) Copy Section

stable-diffusion

CONTAINERS IMAGES RUN BUILD

Generate images from text (txt2img) or from other images (img2img)

• stable-diffusion: https://github.com/CompVis/stable-diffusion (/opt/stable-diffusion)
• with memory optimizations: https://github.com/basujindal/stable-diffusion (/opt/stable-diffusion/optimizedSD)
• tested on stable-diffusion-1.4 model: https://huggingface.co/CompVis/stable-diffusion-v-1-4-original

See the stable-diffusion-webui container for a faster implementation with a web interface.

txt2img Copy Section

Download the stable-diffusion-1.4 model (sd-v1-4.ckpt)

wget https://huggingface.co/CompVis/stable-diffusion-v-1-4-original/resolve/main/sd-v1-4.ckpt -O /data/models/stable-diffusion/sd-v1-4.ckpt

Then run this in the container to generate images (by default, six 512x512 images with 50 refinement steps)

cd /opt/stable-diffusion && python3 scripts/txt2img.py --plms \
  --ckpt /data/models/stable-diffusion/sd-v1-4.ckpt \
  --outdir /data/images/stable-diffusion \
  --prompt "a photograph of an astronaut riding a horse"

See here for options: https://github.com/CompVis/stable-diffusion#reference-sampling-script

For just one 512x512 image with 25 steps:

cd /opt/stable-diffusion && python3 scripts/txt2img.py --plms \
  --n_samples 1 --n_iter 1 --ddim_steps 25 \
  --ckpt /data/models/stable-diffusion/sd-v1-4.ckpt \
  --outdir /data/images/stable-diffusion \
  --prompt "two robots walking in the woods"

• Change the image resolution with --W and --H (the default is 512x512)
• Change the --seed to have the images be different (the default seed is 42)

For Jetson Orin Nano and reduced memory usage:

cd /opt/stable-diffusion && python3 optimizedSD/optimized_txt2img.py \
  --sampler plms --seed 42 \
  --n_samples 1 --n_iter 1 --ddim_steps 25 \
  --ckpt /data/models/stable-diffusion/sd-v1-4.ckpt \
  --outdir /data/images/stable-diffusion \
  --prompt "a photograph of an astronaut riding a horse"

To run all these steps from a script, see stable-diffusion/test.sh

CONTAINERS

CONTAINER IMAGES

_{Container images are compatible with other minor versions of JetPack/L4T:
    • L4T R32.7 containers can run on other versions of L4T R32.7 (JetPack 4.6+)
    • L4T R35.x containers can run on other versions of L4T R35.x (JetPack 5.1+)}

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag stable-diffusion)

# or explicitly specify one of the container images above
jetson-containers run dustynv/stable-diffusion:r35.4.1

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host dustynv/stable-diffusion:r35.4.1

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag stable-diffusion)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag stable-diffusion) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build stable-diffusion

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`.github/workflows/scripts/README.md`) Copy Section

GitHub Actions Workflow Scripts

This directory contains reusable scripts for GitHub Actions workflows in the jetson-containers project.

Scripts Copy Chapter

Core Scripts Copy Section

• step-pre-checkout-cleanup.sh - Cleans up permission-restricted files before checkout
• step-system-info.sh - Displays Jetson system information
• step-env-info.sh - Records comprehensive environment variables and system info
• step-clean-environment.sh - Cleans up Docker, cache, and permission-restricted directories
• step-git-status.sh - Shows git repository state and recent history

Build Scripts Copy Section

• step-build-package.sh - Builds and tests a specific package
• step-analyze-results.sh - Analyzes build results and outputs status
• step-test-results-summary.sh - Generates a comprehensive test results summary

Workflow Generation Copy Section

• workflow-template.yml - Template for creating new package workflow files
• generate-workflow.sh [platform] - Generates a new workflow file from template

Usage Copy Chapter

Creating a New Workflow Copy Section

To create a new workflow for a package and platform:

cd .github/workflows/scripts
./generate-workflow.sh vllm orin
./generate-workflow.sh vllm thor

This will create:

• ../workflows/pr-on-dev_vllm_orin.yml
• ../workflows/pr-on-dev_vllm_thor.yml

Creating Multiple Workflows Copy Section

cd .github/workflows/scripts
# For Orin platform
./generate-workflow.sh vllm orin
./generate-workflow.sh cudnn orin
./generate-workflow.sh nccl orin

# For Thor platform
./generate-workflow.sh vllm thor
./generate-workflow.sh cudnn thor
./generate-workflow.sh nccl thor

Platform Support Copy Section

• orin - Jetson Orin (default if platform not specified)
• thor - Jetson Thor
• Any other platform - Just specify the platform name

Manual Workflow Creation Copy Section

1. Copy workflow-template.yml to ../workflows/pr-on-dev__.yml
2. Replace all instances of PACKAGE_NAME with the actual package name
3. Replace all instances of PLATFORM with the actual platform name
4. Update the workflow name as needed

Script Parameters Copy Chapter

step-build-package.sh Copy Section

• Required: `` - The package to build and test
• Example: ./step-build-package.sh vllm

step-analyze-results.sh Copy Section

• Required: <stage1> <stage2>
• Optional: [failure_phase] [failure_stage] [failure_component]

step-test-results-summary.sh Copy Section

• Required: <stage1> <stage2>
• Optional: [failure_phase] [failure_stage] [failure_component]

Benefits Copy Chapter

• Reusable: Same scripts work for all packages
• Maintainable: Update scripts once, affects all workflows
• Consistent: All workflows have the same behavior and output format
• Easy to create: Generate new workflows with a single command

Overview (`deprecated/cuda/cuda-python/README.md`) Copy Section

cuda-python

CONTAINERS IMAGES RUN BUILD

CONTAINERS

CONTAINER IMAGES

_{Container images are compatible with other minor versions of JetPack/L4T:
    • L4T R32.7 containers can run on other versions of L4T R32.7 (JetPack 4.6+)
    • L4T R35.x containers can run on other versions of L4T R35.x (JetPack 5.1+)}

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag cuda-python)

# or explicitly specify one of the container images above
jetson-containers run dustynv/cuda-python:r36.4.0-cu128-24.04

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host dustynv/cuda-python:r36.4.0-cu128-24.04

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag cuda-python)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag cuda-python) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build cuda-python

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/cuda/cuda/README.md`) Copy Section

cuda

CONTAINERS IMAGES RUN BUILD

CONTAINERS

CONTAINER IMAGES

_{Container images are compatible with other minor versions of JetPack/L4T:
    • L4T R32.7 containers can run on other versions of L4T R32.7 (JetPack 4.6+)
    • L4T R35.x containers can run on other versions of L4T R35.x (JetPack 5.1+)}

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag cuda)

# or explicitly specify one of the container images above
jetson-containers run dustynv/cuda:12.9-samples-r36.4.0-cu128-24.04

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host dustynv/cuda:12.9-samples-r36.4.0-cu128-24.04

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag cuda)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag cuda) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build cuda

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/cuda/cutlass/README.md`) Copy Section

cutlass

CONTAINERS IMAGES RUN BUILD

CONTAINERS

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag cutlass)

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host cutlass:36.4.0

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag cutlass)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag cutlass) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build cutlass

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/cuda/gdrcopy/README.md`) Copy Section

gdrcopy

CONTAINERS IMAGES RUN BUILD

CONTAINERS

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag gdrcopy)

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host gdrcopy:36.4.0

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}

To mount your own directories into the container, use the -v or --volume flags:

jetson-containers run -v /path/on/host:/path/in/container $(autotag gdrcopy)

To launch the container running a command, as opposed to an interactive shell:

jetson-containers run $(autotag gdrcopy) my_app --abc xyz

You can pass any options to it that you would to docker run, and it'll print out the full command that it constructs before executing it.

BUILD CONTAINER

If you use autotag as shown above, it'll ask to build the container for you if needed. To manually build it, first do the system setup, then run:

jetson-containers build gdrcopy

The dependencies from above will be built into the container, and it'll be tested during. Run it with --help for build options.

Overview (`deprecated/cuda/nccl/README.md`) Copy Section

nccl

CONTAINERS IMAGES RUN BUILD

CONTAINERS

RUN CONTAINER

To start the container, you can use jetson-containers run and autotag, or manually put together a docker run command:

# automatically pull or build a compatible container image
jetson-containers run $(autotag nccl)

# or if using 'docker run' (specify image and mounts/ect)
sudo docker run --runtime nvidia -it --rm --network=host nccl:36.4.0

^{jetson-containers run forwards arguments to docker run with some defaults added (like --runtime nvidia, mounts a /data cache, and detects devices)
autotag finds a container image that's compatible with your version of JetPack/L4T - either locally, pulled from a registry, or by building it.}