Use Advanced Docker Operations with Artifactory CLI
Push and pull Docker images with Podman, Kaniko, buildx, or OpenShift and Artifactory.
Advanced Docker operations using JFrog CLI's Artifactory commands (jf rt). These commands are separate from the main jf docker command and provide integration with alternative container tools (Podman, Kaniko, buildx, OpenShift) and Docker image lifecycle management (build-docker-create, docker-promote).
This topic covers the following tasks:
- Pull Docker images using Podman
- Push Docker images using Podman
- Push Docker images using Kaniko
- Push Docker images using buildx
- Push Docker images using OpenShift CLI
- Add published Docker images to the build-info
- Promote Docker images
Deprecation notice
The
jf rt docker-pushandjf rt docker-pullcommands are deprecated. Usejf docker pushandjf docker pullinstead. The deprecated commands are hidden from--helpoutput but still functional for backwards compatibility.This deprecation applies only to
jf rt docker-pushandjf rt docker-pull. The Podman-specific commandsjf rt podman-pullandjf rt podman-pushare not deprecated and remain the supported path for Podman-based workflows.
Package Alias (Ghost Frog)
To run
dockerwithout thejfprefix, enable Package Alias insetup-jfrog-cliand setJFROG_CLI_GHOST_FROG=true. If you install the tool after the action (for examplesetup-javaorsetup-node), re-pin the alias path toGITHUB_PATH. See Use JFrog CLI Package Alias.
Prerequisites
Before running any commands on this page, ensure the following are in place.
To prepare your environment:
- JFrog CLI configured — run
jf config addand verify withjf config show. - Docker repositories exist — the source and target repositories must already exist in your Artifactory instance.
- Podman installed — required for
podman-pullandpodman-pushcommands.- On macOS, Podman requires a running VM:
podman machine init && podman machine start - Verify:
podman --version
- On macOS, Podman requires a running VM:
- Podman authenticated to your registry — the CLI automatically attempts
podman loginbefore pull/push. Pre-authenticate to avoid failures:If your Artifactory server is configured with a reference token (non-JWT), Podman requires explicit username credentials. Use thepodman login <your-registry>--userflag onpodman-pullandpodman-push, or pre-login manually:podman login <your-registry> --username <artifactory-username> --password <access-token> jf dockerintegration — If you also usejf docker(native Docker client flows), see Environment variables on that page forJFROG_CLI_CONTAINER_MANAGERandJFROG_CLI_SKIP_DOCKER_IMAGE_ID_VERIFICATION.
Pull Docker Images Using Podman
Podman is a daemon-less container engine for developing, managing, and running OCI Containers. The podman-pull command pulls docker images from Artifactory using Podman, while collecting build-info.
To pull Docker images using Podman:
- Ensure Prerequisites are met and your image tag uses the form
<registry>/<repo-path>/<image>:<tag>. - Run
jf rt podman-pullwith the image tag, source repository, and optional build-info flags (see Example).
| Parameter | Description |
|---|---|
| Command-name | rt podman-pull |
| Abbreviation | rt ppl |
--server-id | [Optional] Server ID configured using jf config |
--user | [Optional] Artifactory username. Required when the server uses a reference token (non-JWT). |
--build-name | [Optional] Build name |
--build-number | [Optional] Build number |
--project | [Optional] JFrog project key |
--module | [Optional] Module name for build-info |
--skip-login | [Default: false] Skip Docker login |
--format | [Optional] Output format: json or table. When omitted, output is backward-compatible. See jf rt output format. |
| Image tag | The docker image tag to pull. Must be in the form <registry>/<repo-path>/<image>:<tag> |
| Source repository | Source repository in Artifactory |
Image tag format
The image tag must include a repository sub-path between the registry domain and the image name:
<registry>/<repo-path>/<image>:<tag>. For example,my-registry.io/my-repo/my-image:latest. A two-component path such asmy-registry.io/my-image:latestis not accepted.
Example
jf rt podman-pull <registry>/<repo-path>/<image>:<tag> <source-repo> --build-name <build-name> --build-number <build-number>Where:
<registry>is your Artifactory Docker registry (for example,my-docker-registry.io)<repo-path>is the repository sub-path within the registry (for example,my-repo)<image>:<tag>is the Docker image name and tag (for example,my-docker-image:latest)<source-repo>is the source repository in Artifactory (for example,docker-local)
For example:
jf rt podman-pull my-docker-registry.io/my-repo/my-docker-image:latest docker-local --build-name my-build-name --build-number 7Expected output
On success, the command prints the pulled image layers and build-info collection status:
[Info] Pulling image: my-docker-registry.io/my-repo/my-docker-image:latest
[Info] Build info successfully collected for build my-build-name/7
Push Docker Images Using Podman
After building your image, the podman-push command pushes the image layers to Artifactory, while collecting build-info.
To push Docker images using Podman:
- Ensure Prerequisites are met and your image tag uses the form
<registry>/<repo-path>/<image>:<tag>. - Run
jf rt podman-pushwith the image tag, target repository, and optional build-info flags (see Example).
| Parameter | Description |
|---|---|
| Command-name | rt podman-push |
| Abbreviation | rt pp |
--server-id | [Optional] Server ID configured using jf config |
--user | [Optional] Artifactory username. Required when the server uses a reference token (non-JWT). |
--build-name | [Optional] Build name |
--build-number | [Optional] Build number |
--project | [Optional] JFrog project key |
--module | [Optional] Module name for build-info |
--skip-login | [Default: false] Skip Docker login |
--threads | [Default: 3] Number of working threads |
--detailed-summary | [Default: false] Include affected files in the command summary |
--validate-sha | [Default: false] Enable SHA validation during Docker push |
--format | [Optional] Output format: json or table. Setting --format enables detailed summary. See jf rt output format. |
| Image tag | The docker image tag to push. Must be in the form <registry>/<repo-path>/<image>:<tag> |
| Target repository | Target repository in Artifactory |
Image tag format
The image tag must include a repository sub-path between the registry domain and the image name:
<registry>/<repo-path>/<image>:<tag>. For example,my-registry.io/my-repo/my-image:latest. A two-component path such asmy-registry.io/my-image:latestis not accepted.
Example
jf rt podman-push <registry>/<repo-path>/<image>:<tag> <target-repo> --build-name <build-name> --build-number <build-number>Where:
<registry>is your Artifactory Docker registry (for example,my-docker-registry.io)<repo-path>is the repository sub-path within the registry (for example,my-repo)<image>:<tag>is the Docker image name and tag (for example,my-docker-image:latest)<target-repo>is the target repository in Artifactory (for example,docker-local)
For example:
jf rt podman-push my-docker-registry.io/my-repo/my-docker-image:latest docker-local --build-name my-build-name --build-number 7Expected output
On success, the command prints the pushed image layers and build-info collection status:
[Info] Pushing image: my-docker-registry.io/my-repo/my-docker-image:latest
[Info] Build info successfully collected for build my-build-name/7
Push Docker Images Using Kaniko
JFrog CLI allows pushing containers to Artifactory using Kaniko, while collecting build-info and storing it in Artifactory.
The Kaniko workflow uses the jf rt build-docker-create command (jf rt bdc) to attach the already-built and pushed image to the build-info after Kaniko completes the push.
To push Docker images using Kaniko:
-
Run Kaniko to build and push the image to Artifactory, capturing the image digest.
-
Write the image reference to a file in the format
<IMAGE-TAG>@sha256:<MANIFEST-SHA256>. -
Run
jf rt bdcto add the image to the build-info:jf rt bdc <target-repo> --image-file <path-to-image-file> --build-name <build-name> --build-number <build-number> -
Publish the build-info with
jf rt build-publish.
For a complete setup including the Kaniko container configuration and Dockerfile, refer to the Kaniko project example on GitHub.
Push Docker Images Using buildx
JFrog CLI allows pushing containers to Artifactory using buildx, while collecting build-info and storing it in Artifactory.
The buildx workflow uses docker buildx build --push to build and push a multi-platform (fat manifest) image to Artifactory, then attaches it to the build-info using jf rt bdc.
To push Docker images using buildx:
-
Run
docker buildx build --pushtargeting your Artifactory registry, capturing the image digest. -
Write the image reference to a file in the format
<IMAGE-TAG>@sha256:<MANIFEST-SHA256>. -
Run
jf rt bdcto add the image to the build-info:jf rt bdc <target-repo> --image-file <path-to-image-file> --build-name <build-name> --build-number <build-number> -
Publish the build-info with
jf rt build-publish.
For a complete setup including multi-platform build configuration, refer to the buildx project example on GitHub.
Push Docker Images Using the OpenShift CLI
JFrog CLI allows pushing containers to Artifactory using the OpenShift CLI, while collecting build-info and storing it in Artifactory.
The jf rt oc start-build command (abbreviation jf rt osb) wraps OpenShift's native build system. It runs oc start-build on your behalf and then reads the resulting image tag and digest directly from OpenShift to add them to the build-info — no separate jf rt bdc step is required.
To push Docker images using the OpenShift CLI:
-
Configure your OpenShift
BuildConfigto push to your Artifactory Docker registry. -
Ensure the OpenShift CLI (
oc), version 3.0.0 or higher, is installed and authenticated to the cluster. -
Run
jf rt oc start-buildwith the build config name and target repository:jf rt oc start-build <build-config-name> --repo <target-repo> --build-name <build-name> --build-number <build-number>Parameter Description Command-name rt oc start-buildAbbreviation rt osb--repo[Mandatory] The name of the repository to which the image was pushed --server-id[Optional] Server ID configured using jf config--build-name[Optional] Build name --build-number[Optional] Build number --project[Optional] JFrog project key --module[Optional] Module name for build-info Build config name The OpenShift BuildConfigname to trigger (or--from-build=<build name>to reuse an existing build)The
-w/--wait,--template, and-o/--outputocoptions are not supported, sincejf rt oc start-buildmanages waiting for build completion and reads the result itself. Only thestart-buildsubcommand ofocis supported. -
Publish the build-info with
jf rt build-publish.
For a complete setup including the OpenShift BuildConfig and pipeline integration, refer to the OpenShift build project example on GitHub.
Add Published Docker Images to the Build-Info
The build-docker-create command allows adding a docker image that is already published to Artifactory into the build-info.
To add a published Docker image to the build-info:
- Write the image reference (including digest) to a file (see Example).
- Run
jf rt bdcwith the target repository,--image-file, and optional build-info flags.
| Parameter | Description |
|---|---|
| Command-name | rt build-docker-create |
| Abbreviation | rt bdc |
--image-file | [Mandatory] Path to a file containing: IMAGE-TAG@sha256:MANIFEST-SHA256 |
--server-id | [Optional] Server ID |
--build-name | [Optional] Build name |
--build-number | [Optional] Build number |
--project | [Optional] JFrog project key |
--module | [Optional] Module name for build-info |
| Target repository | The repository to which the image was pushed |
If your Docker image has multiple tags pointing to the same digest, provide them in comma-separated format in the --image-file.
Example
Create the image file first:
echo "<registry>/<repo-path>/<image>:<tag>@sha256:<manifest-sha256>" > image-file-details.txtThen run:
jf rt bdc docker-local --image-file image-file-details.txt --build-name myBuild --build-number 1Expected output
On success:
[Info] Build info successfully created
Promote Docker Images
The docker-promote command moves or copies a Docker image from one repository to another in Artifactory.
To promote a Docker image between repositories:
- Identify the source image name, source repository, and target repository in Artifactory.
- Run
jf rt docker-promote(orjf rt dpr) with those arguments and optional flags (see Example).
| Parameter | Description |
|---|---|
| Command-name | rt docker-promote |
| Abbreviation | rt dpr |
--server-id | [Optional] Server ID |
--copy | [Default: false] Copy instead of move |
--source-tag | [Optional] Tag name to promote |
--target-docker-image | [Optional] Docker target image name |
--target-tag | [Optional] Target tag to assign after promotion |
--format | [Optional] Output format: json only. When omitted, produces no output (backward-compatible). See jf rt output format. |
| Source docker image | The docker image name to promote |
| Source repository | Source repository in Artifactory |
| Target repository | Target repository in Artifactory |
Example
jf rt docker-promote hello-world docker-dev-local docker-staging-localExpected output
On success:
[Info] Promoting image hello-world from docker-dev-local to docker-staging-local
[Info] Docker image promotion completed successfully
Note
The
jf rt docker-promotecommand currently requires the source and target repositories to be different. It does not support promoting a Docker image to the same repository while assigning a different target image name.
Note
The
--projectflag is not supported bydocker-promote. To scope build-info by project, use--projecton thebuild-publishcommand instead.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
podman login failed / must provide --username with --password-stdin | Server uses a reference token (non-JWT), so Podman requires basic auth | Add --user <artifactory-username> to the podman-pull or podman-push command, or pre-login: podman login <registry> --username <user> --password <token> |
podman image must be in the form: registry-domain/path-in-repository/image-name:version | Image tag is missing the repository sub-path | Use the three-component format: <registry>/<repo-path>/<image>:<tag> (for example, my-registry.io/my-repo/my-image:latest) |
| Podman push/pull 401 errors | Authentication not configured for Podman | Run podman login <registry-url> or use --server-id |
build-docker-create fails | Image file format is incorrect | Ensure the file contains IMAGE-TAG@sha256:MANIFEST-SHA256 |
docker-promote fails with same source and target repository | Same-repository promotion is not supported | Use different source and target repositories |
| Kaniko/buildx integration issues | Configuration not set up correctly | Refer to the linked project examples for step-by-step instructions |
Enable debug logging: export JFROG_CLI_LOG_LEVEL=DEBUG
Frequently Asked Questions
This section provides answers to frequently asked questions.
FAQs
Q: When should I use jf rt podman-push instead of jf docker push?
jf rt podman-push instead of jf docker push?A: Use the Podman commands when your workflow already runs Podman instead of the Docker CLI. See Push Docker Images Using Podman for the required image tag format.
Q: What happens if my Podman image tag is missing the repository sub-path?
A: The command fails because the tag must be in the three-component form <registry>/<repo-path>/<image>:<tag>. See Prerequisites for the required format.
Q: What is the difference between the Kaniko and buildx push workflows?
A: Both build and push the image themselves, then use jf rt bdc to attach the already-pushed image to the build-info. Kaniko is typically used for in-cluster builds, while buildx adds multi-platform (fat manifest) images. See Push Docker Images Using Kaniko and Push Docker Images Using buildx.
Q: Do I need jf rt bdc after pushing with the OpenShift CLI?
jf rt bdc after pushing with the OpenShift CLI?A: No. jf rt oc start-build reads the resulting image tag and digest directly from OpenShift and adds them to the build-info, so no separate jf rt bdc step is required.
Q: Can I promote a Docker image to the same repository under a new name?
A: No. jf rt docker-promote requires the source and target repositories to be different. See Promote Docker Images.
Related Topics
Updated 2 days ago
