The Cloudinary CLI (Command Line Interface) enables you to interact with Cloudinary through the command line. For example, you can perform Admin and Upload API operations by typing commands into a terminal without having to spend time setting up a formal coding environment. Additional helper commands are provided to help you to try out transformations, optimizations, and other common actions with minimal effort. You can also combine CLI commands in a batch file to automate laborious tasks.
It is fully documented at https://cloudinary.com/documentation/cloudinary_cli.
Built for AI agents too. cld agent cloud create provisions a working Cloudinary cloud in a single command — no signup, no verification email, no credentials to ask a human for — so an agent can start uploading and transforming right away, then hand the human a claim URL to keep it.
Python 3.8 or later. You can install Python from https://www.python.org/. Note that the Python Package Installer (pip) is installed with it.
A Cloudinary account. There are two ways to get one:
Are you an AI agent? Run cld agent cloud create — no signup, no verification email, no human in the loop. You get a working cloud name, API key and secret in one command, and can upload and transform immediately:
cld agent cloud create
The cloud is temporary: media delivery is limited to the IP that created it, and it expires in about 24 hours unless a human claims it. Hand them the claim URL from the output — or run cld agent cloud claim — and it becomes a permanent account, keeping the same credentials and everything already uploaded.
Are you a human? Sign up at https://cloudinary.com/users/register/free, then see Configuration below. If you'd rather an agent set it up for you, cld agent signup creates a Free-plan account in your name and emails you to verify it.
The CLI is published on PyPI as cloudinary-cli. The package name (cloudinary-cli) is what you install; the command it provides is cld (it also installs a cloudinary alias). Pick the method that fits your setup. If you just want a working cld command and aren't sure, use pipx or uv — they install the CLI in its own isolated environment, so it won't conflict with other Python packages and you don't need to manage a virtual environment yourself.
pipx installs Python CLI tools into isolated environments and puts the cld command on your PATH automatically.
# Install pipx if you don't have it:
# macOS: brew install pipx && pipx ensurepath
# Debian/Ubuntu: sudo apt install pipx && pipx ensurepath
# Any platform: python3 -m pip install --user pipx && python3 -m pipx ensurepath
pipx install cloudinary-cli
# Upgrade later with:
pipx upgrade cloudinary-cliAfter pipx ensurepath, open a new terminal so the updated PATH takes effect.
uv is a fast Python package manager. Its uv tool command installs CLIs in isolation, like pipx:
uv tool install cloudinary-cli
# Upgrade later with:
uv tool upgrade cloudinary-cliOr run it once without installing. The package's command is cld, so name it with --from:
uvx --from cloudinary-cli cld --help # uvx is shorthand for `uv tool run`A plain pip install also works. Prefer a virtual environment so the CLI and its dependencies don't collide with your system or other projects:
python3 -m venv ~/.venvs/cloudinary-cli
source ~/.venvs/cloudinary-cli/bin/activate # Windows: .\.venvs\cloudinary-cli\Scripts\activate
pip install cloudinary-cliTo install without a virtual environment, use a per-user install (avoids needing sudo and keeps it out of system Python):
python3 -m pip install --user cloudinary-cliIf cld is not found afterwards, the user scripts directory is not on your PATH. See Troubleshooting.
If you'd rather not install Python at all, run the CLI from the official Docker image. See Docker Usage below.
cld --versionIf your shell reports cld: command not found after installing:
-
pipx / uv: run
pipx ensurepath(oruv tool update-shell), then open a new terminal. -
pip
--userinstall: the user scripts directory is not on yourPATH. Find it withpython3 -m site --user-base(the scripts live in itsbinsubdirectory on macOS/Linux, orScriptson Windows) and add that to yourPATH. For example, on macOS/Linux add this to~/.zshrcor~/.bash_profile:export PATH="$PATH:$(python3 -m site --user-base)/bin"
-
As a fallback, you can always invoke the CLI through Python:
python3 -m cloudinary_cli.cli <command>.
Once installed, point your cld commands at a Cloudinary account using either of the following.
Option A — Log in with OAuth (recommended). Run:
cld loginThis opens your browser to authorize the CLI, then saves the login as a configuration (named after the cloud) and sets it as the default. The CLI refreshes the token automatically, and you can remove the login at any time with cld logout.
Option B — Set your CLOUDINARY_URL environment variable. For example:
- On Mac or Linux:
export CLOUDINARY_URL=cloudinary://123456789012345:abcdefghijklmnopqrstuvwxyzA@cloud_name - On Windows (cmd.exe):
set CLOUDINARY_URL=cloudinary://123456789012345:abcdefghijklmnopqrstuvwxyzA@cloud_name - On Windows (PowerShell):
$Env:CLOUDINARY_URL="cloudinary://123456789012345:abcdefghijklmnopqrstuvwxyzA@cloud_name"
Note: you can copy and paste your account environment variable from the Account Details section of the Dashboard page in the Cloudinary console.
Then check your configuration by running cld config. A response of the following form is returned:
cloud_name: <CLOUD_NAME>
api_key: <API_KEY>
api_secret: ***************<LAST_4_DIGITS>
private_cdn: <True|False>
If cld itself is not found, see Troubleshooting the cld command.
For details, see the Cloudinary CLI documentation.
Usage: cld [cli options] [command] [command options] [method] [method parameters]
cld --help # Lists available commands.
cld login # Logs in to a Cloudinary account via OAuth in your browser.
cld logout # Revokes and removes a saved OAuth login.
cld search --help # Shows usage for the Search API.
cld admin # Lists Admin API methods.
cld uploader # Lists Upload API methods.
cld agent signup # For AI agents: creates a Cloudinary account on behalf of a human.
cld agent cloud # For AI agents: creates a temporary cloud that works immediately.
The Cloudinary CLI is also available as a Docker image, perfect for containerized environments, CI/CD pipelines, or when you prefer not to install Python locally.
# Check configuration
docker run --rm -e CLOUDINARY_URL cloudinary/cli config
# Upload files from your local machine
docker run --rm -e CLOUDINARY_URL \
-v /path/to/your/images:/app/images \
cloudinary/cli uploader upload /app/images/sample.jpg
# Search for assets
docker run --rm -e CLOUDINARY_URL \
cloudinary/cli search "resource_type:image" --max_results 5
# Interactive mode for multiple commands
docker run --rm -it -e CLOUDINARY_URL --entrypoint /bin/bash cloudinary/cliDocker Image: cloudinary/cli • Base: Debian 12 • Size: ~175MB • Multi-arch: amd64, arm64
For comprehensive Docker usage, examples, and troubleshooting, see DOCKER.md.
Enables you to run any methods that can be called through the upload API.
You can find documentation for each of the Upload API methods at https://cloudinary.com/documentation/image_upload_api_reference.
The basic syntax using the Upload API is as follows:
cld [cli options] uploader [command options] [method] [method parameters]
For details, see the Cloudinary CLI documentation.
Example: change the asset with public_id:"flowers" from type:upload to type:private and rename it using the rename method, which takes two parameters - from_public_id and to_public_id.
Use any of the following commands:
cld uploader rename flowers secret_flowers to_type=private
cld uploader rename flowers secret_flowers -o to_type private
cld rename flowers secret_flowers to_type=private
Note: you can omit 'uploader' from the command when calling an Upload API method.
Enables you to run any methods that can be called through the admin API.
You can find documentation for each of the Admin API methods at https://cloudinary.com/documentation/admin_api.
The basic syntax using the Admin API is as follows:
cld [cli options] admin [command options] [method] [method parameters]
For details, see the Cloudinary CLI documentation.
Example: create a transformation and get information about that transformation:
cld admin create_transformation my_new_transformation w_500,h_500,c_crop,e_vectorize
cld admin transformation my_new_transformation
Note: you can omit 'admin' from the command when calling an Admin API method.
Runs the admin API search method, allowing you to use a Lucene query string as the expression.
You can find documentation for the Search API at https://cloudinary.com/documentation/search_api.
The basic syntax using the Search API is as follows:
cld [cli options] search [command options] [expression]
For details, see the Cloudinary CLI documentation.
Generates a Cloudinary URL, which you can optionally open in your browser.
cld [cli options] url [command options] public_id [transformation]
For details, see the Cloudinary CLI documentation.
Example: generate a URL that displays the image in your media library that has the public ID of 'sample', with a width of 500 pixels and transformed using the cartoonify effect, then open this URL in a browser.
cld url -rt image -t upload -o sample w_500,e_cartoonify
The URL that is returned is:
http://res.cloudinary.com/<YOUR CLOUD NAME>/image/upload/w_500,e_cartoonify/sample
Returns template code for implementing the specified Cloudinary widget.
cld [cli options] make [command options] [widget]
For details, see the Cloudinary CLI documentation.
Example: output the HTML required to embed the Upload Widget on your website.
cld make upload_widget
Uploads a folder of assets, maintaining the folder structure.
cld [cli options] upload_dir [command options] [local_folder]
For details, see the Cloudinary CLI documentation.
Example: upload the local folder, my_images, and all its contents and sub-folders to your Cloudinary folder my_images_on_cloudinary.
cld upload_dir -f my_images_on_cloudinary my_images
Synchronizes between a local folder and a Cloudinary folder, maintaining the folder structure.
cld [cli options] sync [command options] local_folder cloudinary_folder
For details, see the Cloudinary CLI documentation.
Example: push up changes from the local folder, my_images, to your Cloudinary folder, my_images_on_cloudinary/my_images.
cld sync --push my_images my_images_on_cloudinary/my_images
Migrates a list of external media files to Cloudinary. The URLs of the files to migrate are listed in a separate file and must all have the same prefix.
cld [cli options] migrate [command options] upload_mapping file
For details, see the Cloudinary CLI documentation.
For AI agents only. Creates a Free-plan Cloudinary account on behalf of a human. No existing configuration is required to run it. A verification email is sent to the address, and the returned credentials are inert until the human completes that verification. The new product environment is saved as a named configuration (named after the cloud) so it is ready to use once activated.
cld agent signup [command options] <email> <agent_framework> <agent_llm_model> <agent_goal>
Example:
cld agent signup you@example.com claude-code claude-fable-5 "test the agent account flow"
Options:
--name <name>— name for the saved configuration (default: the returned cloud name).--set-default— set the saved configuration as the default.--no-save— show the credentials but do not save them as a configuration.--sdk-framework <name>— the Cloudinary SDK framework the agent intends to use.--json— output the full raw JSON response (the agent contract) instead of the human-readable summary.
For AI agents acting on behalf of a human. Creates and claims Claimable Clouds: temporary clouds whose credentials work immediately, with no signup and no verification email. No existing configuration is required.
Media delivery is restricted to an IP allow-list, and the cloud is disabled after about 24 hours — along with everything uploaded to it — unless a human claims it. Claiming makes it permanent, keeps the credentials and assets, and lifts the IP restriction.
cld agent cloud create [command options] [email]
Example:
cld agent cloud create you@example.com --claim
The cloud is saved as a named configuration along with its claim URL, which the server returns exactly once and cannot be looked up again. A cloud saved without it — or created outside the CLI — cannot be claimed via agent cloud claim.
The optional email only pre-fills the claim page. It is never verified and no mail is sent to it at creation, but it must be a real unused address: the server rejects addresses already taken and disposable domains.
Options:
--ip <address>— an additional IP permitted to deliver media, repeatable. Omit to let the server use the address the request comes from; the literalrequester_ipmeans that same address.--name <name>— name for the saved configuration (default: the returned cloud name).--set-default— set the saved configuration as the default.--no-save— show the credentials but do not save them as a configuration. The claim URL is then only in the output, so store it yourself.--claim— open the claim page as soon as the cloud is created.--agent-framework <name>,--agent-llm-model <name>,--agent-goal <text>,--sdk-framework <name>— attribution for the agent creating the cloud.--json— output the full raw JSON response (the agent contract) instead of the human-readable summary.
Delivery IPs are sent to the server as given; it validates them and returns the allow-list it actually stored. Read delivery_ips back from the response rather than assuming the list you sent was kept — behind a proxy or VPN your own address may be dropped, and the server refuses to create a cloud with no publicly routable address in the list.
Because the allow-list covers media delivery only, the Upload and Admin APIs are unaffected. Uploads succeeding while a delivery URL returns x-cld-error: ACL deny is the expected symptom of the restriction, not a broken cloud or bad credentials. It is therefore not a confidentiality control.
cld agent cloud claim [command options] [name]
Example:
cld agent cloud claim mycloud --print
Opens the claim page for a saved Claimable Cloud. Run without a name to pick from the saved clouds that have not expired.
Claiming is a human action completed in a browser: they enter an email address there, then click the link sent to it. This command only opens or prints the page — it cannot claim anything itself, and nothing reports whether a claim succeeded.
Options:
--print(or--no-open) — print the claim URL instead of opening a browser. Required for headless and agent use; also implied by--json. The CLI prints rather than opens whenever stdout is not a terminal.--json— output{cloud_name, claim_url, expires_at}as JSON.
Saved Claimable Clouds are flagged in cld config -ls and cld config -s <name> with an expiry countdown, so you can see what is still claimable:
NAME CLOUD TYPE DEFAULT ACTIVE STATUS
mycloud abcd1234 api_key unclaimed, expires in 8h
A configuration is a reference to a specified Cloudinary account or cloud name via its environment variable. You set the default configuration during setup and installation. Using different configurations allows you to access different Cloudinary cloud names, such as sub-accounts of your main Cloudinary account, or any additional Cloudinary accounts you may have.
The config command displays the current configuration and lets you manage additional configurations.
You can specify the environment variable of additional Cloudinary accounts either explicitly (-c option) or as a saved configuration (-C option).
For example, using the -c option:
cld -c cloudinary://123456789012345:abcdefghijklmnopqrstuvwxyzA@cloud_name admin usage
Whereas using the saved configuration "accountx":
cld -C accountx admin usage
Caution: Creating a saved configuration may put your credentials at risk as they are stored in a local plain text file. This applies to both API-key configurations and OAuth logins.
You can create, delete and list saved configurations using the config command.
cld config [options]
For details, see the Cloudinary CLI documentation.
Instead of saving an API key and secret, you can log in to a Cloudinary account through your browser. The CLI saves the resulting session as a named configuration and refreshes its token automatically.
cld login # Log in and save the configuration (named after the cloud).
cld login my-account # Save the login under a specific name.
cld logout # Choose a saved OAuth login to log out of.
cld logout my-account # Log out of a specific saved OAuth login.
The first login becomes the default automatically. When other configurations already exist, the new login is saved but not made the default; cld login tells you so and prints the command to make it the default. Once saved, an OAuth login is selected with -C <name> just like any other saved configuration.
cld logout revokes the login's token at the server and removes the saved configuration. If the token cannot be revoked (for example, you are offline), the saved configuration is still removed.
The default configuration is used when no -c/-C option is given and no CLOUDINARY_URL environment variable is set. The first OAuth login becomes the default automatically; you can change it at any time.
cld config -d <name> # Set an existing saved configuration as the default.
cld config --unset-default # Clear the stored default.
cld config -ls # List saved configurations, marking the default and the active one.
When creating a configuration with -n or --from_url, add --set-default to make it the default in the same step. Resolution precedence is: -c (inline URL) > -C (saved name) > stored default > CLOUDINARY_URL environment variable.
OAuth tokens are refreshed automatically as needed, but you can refresh them manually.
cld config --refresh <name> # Refresh a saved OAuth configuration's token.
cld config --refresh-all # Refresh every saved OAuth configuration whose token is stale.
cld config --refresh <name> --force # Refresh even if the token is still fresh.
If a token can no longer be refreshed (for example, the login was revoked), the CLI reports the configuration and the cld login command to use to log in again.