jetson-containers: sixty AI packages, one ARM chip family, built as Docker

A package tree organized by job, not by vendor

The project describes itself as machine learning containers for NVIDIA Jetson and JetPack L4T, a modular container build system providing the latest AI and ML packages for Jetson boards, with the Jetson AI Lab site and its PyPI index, pypi.jetson-ai-lab.io, as the upstream faces. The README's organizing table sorts packages by task rather than by origin. The ML row carries pytorch, tensorflow, jax, onnxruntime, deepstream, holoscan, CTranslate2 and JupyterLab. The L4T row holds the Jetson native builds, l4t-pytorch, l4t-tensorflow, l4t-ml, l4t-diffusion and l4t-text-generation. The CUDA row provides cupy, cuda-python, pycuda, cv-cuda, opencv with CUDA and numba. Reading the table top to bottom moves from general frameworks to inference engines to the CUDA plumbing under them.

The LLM row is the longest row

The LLM category dominates the table with more than twenty entries, and its composition shows the full pipeline rather than one stage. Serving engines include vLLM, SGLang, MLC, ollama, text-generation-webui, text-generation-inference and llama.cpp. Quantization support arrives as AWQ, gptqmodel, bitsandbytes and exllama, with ktransformers also listed. Training and tuning appear as transformers, optimum, openai, llama-factory and DeepSpeed. Attention and kernels get their own entries, FlashAttention, xformers and xgrammar. For a single ARM board family, the row reads like a server class LLM stack, and it is the clearest signal of where Jetson edge work has moved, the repository treats local large language model serving as a mainstream workload rather than an experiment.

VLM, ViT and RAG rows follow the same logic

Vision language models get their own category, llava, llama-vision, VILA, LITA, NanoLLM, Prismatic, xtuner and gemma_vlm, the multimodal generation cases where an image prompt must reach a language model. The vision transformer row is smaller and sharper, NanoOWL for detection, NanoSAM and Segment Anything for segmentation, Track Anything, and clip_trt for TensorRT optimized CLIP embeddings. The RAG row mixes the familiar orchestration frameworks, llama-index and langchain, with retrieval infrastructure sized for the edge, the NanoDB vector database, FAISS, and RAFT from the RAPIDS stack, plus jetson-copilot as a Jetson specific assistant entry. Each link lands on a package directory, so the table doubles as the index into the build recipes.

Robotics and simulation on the same tree

The Robotics row extends the project past models into embodied AI. ROS is packaged alongside LeRobot, and the vision language action models appear by name, OpenVLA, Crossformer and openpi, the policy architectures that map camera observations directly to robot actions. 3D Diffusion Policy sits in the diffusion category and MimicGen in simulation, OpenDroneMap brings photogrammetry, and the ZED package covers the stereo camera hardware. The Simulation category leads with Isaac Sim, NVIDIA's robotics simulator, before the table truncates. The through line is that a Jetson is usually bolted to something that moves, and the build system treats perception models, action policies and the simulation loop as one ecosystem to be containerized together.

Local PyPI and APT mirrors, one per CUDA version

The repository's docker-compose file stands up the distribution side, local PyPI and APT servers for Jetson CUDA variants with fallback to the Jetson Community registries. The declared services include pypi_cu126 for CUDA 12.6 on Orin as the default, pypi_cu129 and pypi_cu130 alongside it, each running pypiserver with a fallback URL such as https://pypi.jetson-ai-lab.io/jp6/cu126 and a gunicorn server. Wheel packages are stored under /home with the SCP upload user's dist/pypi path split by JetPack version, sbsa, and CUDA variant, and debian packages under the parallel apt path further split by Ubuntu 22.04 and 24.04. Every service carries a health check that opens its own front page with urllib, and the compose file documents its purpose in a header comment, compatibility with jetson-containers.

Scripts at the root, documentation as notebooks

The repository's shape is a build system first and a library second. The jetson-containers file at the root is the entry script, with a jetson_containers Python package beside it, and the classic trio of install.sh, build.sh and run.sh plus an autotag helper and launch_pypi.sh around them. The packages directory holds the build recipes the README table indexes into, data and deprecated directories keep housekeeping, and tests plus a test_suite directory cover behavior. GitHub registers the primary language as Jupyter Notebook, which fits a project whose documentation doubles as executable walkthroughs, and the Python requirements are a lean toolchain, packaging, pyyaml, wget, requests, tabulate, termcolor, the DockerHub API client pulled straight from its git repository, and black, flake8 and pre-commit for development.

An agent-ready repository, citable and unreleased

Several root files mark how this repository expects to be worked on. CLAUDE.md, AGENTS.md and a .claude directory configure coding agents as first class contributors, a sign of the times for a project that already automated its package builds. A CITATION.cff file makes the work citable through GitHub's citation tooling, and a pre-commit configuration keeps the black and flake8 gates local. The license situation is a small quirk, GitHub reports NOASSERTION while a LICENSE.md sits at the root, so the terms exist but automated detection did not classify them. There are no GitHub releases, the master branch is the distribution channel, and the last push landed on 2026-08-10, recent enough that the package table still reflects current ecosystem names.

Editorial conclusion

Use jetson-containers when deploying AI workloads on Jetson hardware and the cost of compiling CUDA aware wheels for ARM is the actual bottleneck, since its CUDA version matched package tree and local PyPI and APT mirrors exist precisely to remove that cost. Skip it for x86 servers, where upstream wheels already exist and the Jetson specific plumbing adds nothing. Before adopting, confirm the CUDA version of your JetPack matches one of the mirrored variants, cu126, cu129 or cu130 in the current compose stack, note there are no GitHub releases so the master branch is the version, with the last push on 2026-08-10, and check the package page for your specific model since coverage varies by category.

Frequently asked questions

Official sources

1. dusty-nv/jetson-containers on GitHub
2. Issues
3. README