Implementation:Triton inference server Server Docker Tag Push

Field	Value
Page Type	Implementation
Title	Docker_Tag_Push
Namespace	Triton_inference_server_Server
Workflow	Custom_Container_Build
Domains	Container_Build, DevOps
Last Updated	2026-02-13 17:00 GMT

Overview

Concrete Docker CLI procedure for tagging and pushing custom Triton containers to registries.

Description

After a custom Triton container has been built (via compose.py or build.py) and verified through health checks, the image must be tagged with a registry-qualified name and pushed to a container registry. This is accomplished using the standard Docker CLI commands docker tag and docker push.

The default image name produced by compose.py is tritonserver (configurable via --output-name). The default image name produced by build.py is also tritonserver. These local names must be re-tagged with the full registry path before pushing.

The tagging and push process involves:

1. Identify the source image -- The locally built image name (e.g., tritonserver)
2. Construct the target tag -- Combine registry hostname, repository path, and version tag
3. Apply the tag -- Use docker tag to create an alias pointing to the same image layers
4. Authenticate with the registry -- Use docker login or cloud-specific credential helpers
5. Push the image -- Use docker push to upload the image layers to the registry

Usage

Tagging and Pushing to Docker Hub

# Tag the locally built image
docker tag tritonserver myorg/tritonserver:24.12-custom

# Push to Docker Hub
docker push myorg/tritonserver:24.12-custom

Tagging and Pushing to AWS ECR

# Authenticate with ECR
aws ecr get-login-password --region us-east-1 | \
  docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com

# Tag for ECR
docker tag tritonserver 123456789.dkr.ecr.us-east-1.amazonaws.com/tritonserver:24.12-custom

# Push to ECR
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/tritonserver:24.12-custom

Tagging and Pushing to GCP Artifact Registry

# Authenticate with GCP
gcloud auth configure-docker us-docker.pkg.dev

# Tag for Artifact Registry
docker tag tritonserver us-docker.pkg.dev/my-project/my-repo/tritonserver:24.12-custom

# Push to Artifact Registry
docker push us-docker.pkg.dev/my-project/my-repo/tritonserver:24.12-custom

Tagging and Pushing to Azure ACR

# Authenticate with ACR
az acr login --name myregistry

# Tag for ACR
docker tag tritonserver myregistry.azurecr.io/tritonserver:24.12-custom

# Push to ACR
docker push myregistry.azurecr.io/tritonserver:24.12-custom

Code Reference

Source Location

File	Lines	Description
N/A	N/A	This implementation uses external Docker CLI commands, not Triton source code
compose.py	L455-456	Default output image name (tritonserver) used as the source for tagging

Signature

# Tag an image
docker tag <source-image> <registry>/<repo>:<tag>

# Push an image
docker push <registry>/<repo>:<tag>

Import

No code imports required. This procedure uses:

• docker CLI (Docker Engine 19.03+ recommended)
• Registry-specific authentication tools:
  • AWS: aws ecr get-login-password
  • GCP: gcloud auth configure-docker
  • Azure: az acr login
  • Docker Hub: docker login
  • Private registries: docker login <registry-url>

I/O Contract

Inputs

Input	Type	Description
Built Docker image	Container image	The locally built and verified Triton container (e.g., tritonserver)
Registry credentials	Authentication	Valid credentials for the target container registry
Target tag	String	Registry-qualified image name: <registry>/<repo>:<tag>

Outputs

Output	Type	Description
Tagged image (local)	Container image	Local image alias with the registry-qualified name
Pushed image (remote)	Registry artifact	Image layers and manifest stored in the container registry, pullable by tag

Tagging Best Practices

Practice	Example	Rationale
Include Triton version	:24.12-custom	Identifies the base Triton version
Include backend summary	:24.12-trt-py-onnx	Communicates which backends are available
Include build date	:24.12-20260213	Disambiguates multiple builds of the same version
Include git hash	:24.12-a1b2c3d	Enables tracing the image back to the exact source
Avoid mutable tags	Avoid :latest for production	Mutable tags break reproducibility guarantees
Use multi-tag	Tag with both version and :latest	Provides convenience while maintaining version tags

Usage Examples

Example 1: Simple push after compose build

# After compose.py and verification
docker tag tritonserver myregistry.example.com/ml/tritonserver:24.12-slim
docker push myregistry.example.com/ml/tritonserver:24.12-slim

Example 2: Multi-tag push for CI/CD

# Tag with version, date, and latest
VERSION="24.12"
DATE=$(date +%Y%m%d)
HASH=$(git rev-parse --short HEAD)

docker tag tritonserver myregistry.example.com/triton:${VERSION}-${DATE}-${HASH}
docker tag tritonserver myregistry.example.com/triton:${VERSION}-latest
docker tag tritonserver myregistry.example.com/triton:latest

docker push myregistry.example.com/triton:${VERSION}-${DATE}-${HASH}
docker push myregistry.example.com/triton:${VERSION}-latest
docker push myregistry.example.com/triton:latest

Example 3: Push to multiple registries for multi-cloud

TAG="24.12-trt-py-gpu"

# Push to AWS ECR
docker tag tritonserver 123456789.dkr.ecr.us-east-1.amazonaws.com/tritonserver:${TAG}
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/tritonserver:${TAG}

# Push to GCP Artifact Registry
docker tag tritonserver us-docker.pkg.dev/my-project/ml/tritonserver:${TAG}
docker push us-docker.pkg.dev/my-project/ml/tritonserver:${TAG}

# Push to private registry
docker tag tritonserver registry.internal.example.com/tritonserver:${TAG}
docker push registry.internal.example.com/tritonserver:${TAG}

Related Pages

• Principle:Triton_inference_server_Server_Container_Distribution
• Environment:Triton_inference_server_Server_Docker_Container_Build