# Deepstream 9.1 Production Base Image

**URL:** <https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664>\
**Category:** DeepStream SDK\
**Tags:** deepstream\
**Created:** [September 8, 2026, 6:55am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664 "2026-09-08T06:55:00Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![johannesrhvw](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@johannesrhvw](https://forums.developer.nvidia.com/u/johannesrhvw)\
**Post date:** [September 8, 2026, 6:55am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/1 "2026-09-08T06:55:00Z")

</div>

- **Hardware Platform: RTX5070Ti/Jetson Orin AGX 64GB**
- **DeepStream Version 9.1**
- **JetPack Version (valid for Jetson only) 7.2.1**
- **TensorRT Version 10.16.x**
- **NVIDIA GPU Driver Version (valid for GPU only) 610 open**
- **Question**

What is the recommended minimal size docker base image to deploy a compiled C++ binary as part of a Docker Image.  
There seem to be only two images supported:

deepstream-9.1:triton-multiarch:  
This seems to be the “large” one with still \> 12 Gigabytes, containing all samples and dev dependencies

deepstream-9.1:samples:  
this is a little bit smaller but still huge.

I already created a split approach having a base image with additional installs like gstreamer-rs plugins for webrtc, but this base image is 18 Gigabytes, then my release image only adds the compiled binary ~5MB to it.  
If i ever need to update the base image accross the fleet downloading ~20 Gigabytes per machine is a no-go, as in deepstream 9.2 updates etc.. This size seems like it is bloated and contains thinges i will never use in production.

What ways does nvidia recommend to deploy deepstream based applications in 2026?

---

<div class="post-metadata">

**Author:** ![junshengy](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/junshengy/32/251332_2.png) [@junshengy](https://forums.developer.nvidia.com/u/junshengy)\
**Post date:** [September 8, 2026, 9:28am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/3 "2026-09-08T09:28:37Z")

</div>

You could consider building your own Docker image from dockerfile.

> <https://github.com/NVIDIA-AI-IOT/deepstream_dockers/blob/main/jetson_dockerfiles/Dockerfile_Jetson_Run>

If you want to minimize the image size, you could remove unused video/.so files from the image.

> [@johannesrhvw](#):
>
> - Jetson Orin AGX 64GB

Noting that you’re using Orin. I don’t recommend Docker deployment because Docker images depend on the Jetpack version; host deployment is generally a better recommendation.

---

<div class="post-metadata">

**Author:** ![Fiona.Chen](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/fiona.chen/32/15508_2.png) [@Fiona.Chen](https://forums.developer.nvidia.com/u/Fiona.Chen)\
**Post date:** [September 8, 2026, 9:31am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/4 "2026-09-08T09:31:24Z")

</div>

For DeepStream 9.1, please refer to [DeepStream/deepstream\_dockers at main · NVIDIA/DeepStream](https://github.com/NVIDIA/DeepStream/tree/main/deepstream_dockers) for the docker files.

---

<div class="post-metadata">

**Author:** ![johannesrhvw](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@johannesrhvw](https://forums.developer.nvidia.com/u/johannesrhvw)\
**Post date:** [September 8, 2026, 12:27pm UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/5 "2026-09-08T12:27:05Z")

</div>

before i go through the effort to create my own deepstream docker file.  
can you estimate the reduction in size.  
Only saving on some .so files seems like its not worth it.  
I was talking like tools that are never used, nsight systems for example.  
Where does the 14 Gigabyte difference between the base cuda image and the deepstream images come from?

---

<div class="post-metadata">

**Author:** ![johannesrhvw](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@johannesrhvw](https://forums.developer.nvidia.com/u/johannesrhvw)\
**Post date:** [September 8, 2026, 12:28pm UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/6 "2026-09-08T12:28:49Z")

</div>

if docker deployment is not recommendet, why are you providing Dockerfiles specifically for jetson?  
I dont see a different way, as our services are deployed using k8s

---

<div class="post-metadata">

**Author:** ![junshengy](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/junshengy/32/251332_2.png) [@junshengy](https://forums.developer.nvidia.com/u/junshengy)\
**Post date:** [September 8, 2026, 1:10pm UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/7 "2026-09-08T13:10:51Z")

</div>

> [@johannesrhvw](#):
>
> Where does the 14 Gigabyte difference between the base cuda image and the deepstream images come from?

No relevant data is currently available.  
The increased size includes the `gstreamer` base library, `TensorRT`, `tritonserver`(for nvinferserver), deepstream libraries, deepstream sdk test videos, etc.

> [@johannesrhvw](#):
>
> if docker deployment is not recommendet, why are you providing Dockerfiles specifically for jetson?

This is just a suggestion that it’s not recommended. If you’re using Kubernetes, please continue to use container deployment.

---

<div class="post-metadata">

**Author:** ![johannesrhvw](https://developer.download.nvidia.com/images/forums/profile-default-devtalk-84.png) [@johannesrhvw](https://forums.developer.nvidia.com/u/johannesrhvw)\
**Post date:** [September 8, 2026, 1:42pm UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/8 "2026-09-08T13:42:19Z")

</div>

my pipeline is not using tritonserver.  
also the test videos are not needed as well, are these also contained in the samples docker image?  
if so, then i will give it a shot to build my own base image

---

<div class="post-metadata">

**Author:** ![junshengy](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/junshengy/32/251332_2.png) [@junshengy](https://forums.developer.nvidia.com/u/junshengy)\
**Post date:** [September 10, 2026, 6:31am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/9 "2026-09-10T06:31:12Z")

</div>

Compared to the TensorRT base image, the `samples-multiarch` image adds only about 2 GB. Libraries related to Triton Inference Server have been removed from `samples-multiarch`;  
`Disk USAGE` refers to the space occupied after extraction; this is related to Docker image layers, This is not something DeepStream can handle.

```auto
IMAGE ID DISK USAGE CONTENT SIZE 
nvcr.io/nvidia/cuda:13.0.0-tensorrt-runtime-ubuntu24.04 198208c45877 9.69GB 4.19GB 
nvcr.io/nvidia/deepstream:9.1-samples-multiarch 4f80b374e4a5 16.2GB 6.39GB

```

The `/opt/nvidia/deepstream/deepstream-9.1/samples` directory within the image—containing models and test video files—accounts for approximately 624 MB.  
Whether the other directories can be deleted depends on your application.

```auto
root@d6ec4519c615:/opt/nvidia/deepstream/deepstream-9.1/samples# ls
configs models prepare_classification_test_video.sh prepare_ds_triton_model_repo.sh prepare_ds_triton_tao_model_repo.sh streams triton_backend_setup.sh triton_model_repo triton_tao_model_repo trtis_model_repo
root@d6ec4519c615:/opt/nvidia/deepstream/deepstream-9.1/samples# du -sh .
624M	.

```

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/nvidia/user_avatar/forums.developer.nvidia.com/system/32/68080_2.png) [@system](https://forums.developer.nvidia.com/u/system)\
**Post date:** [September 24, 2026, 6:31am UTC](https://forums.developer.nvidia.com/t/deepstream-9-1-production-base-image/382664/10 "2026-09-24T06:31:36Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
