# oci-cli is Oracle's scriptable door into its own cloud

> oci-cli is the Python command line interface for Oracle Cloud Infrastructure, maintained by Oracle Corp, with an interactive mode, a container image and an offline install path. It suits engineers automating OCI, and it is a poor fit for anyone who needs a stable command surface across provider versions.

**oracle/oci-cli** — Command Line Interface for Oracle Cloud Infrastructure

- Repository: https://github.com/oracle/oci-cli
- Website: https://cloud.oracle.com/cloud-infrastructure
- Stars: 679 · Forks: 235
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/oracle-oci-cli

## A vendor CLI, which is the point and the constraint

oci-cli is the command line interface for Oracle Cloud Infrastructure, and it is maintained by Oracle Corp. That single fact shapes both its value and its limits. It is a first-party tool for one cloud, so it can cover services and parameters that a generic cloud CLI either abstracts away or does not reach at all, and it is generated against the same API surface the cloud console uses. The consequence is that nothing in it is portable. Every command name, every flag and every resource type belongs to OCI, and there is no compatibility layer for other providers. For an engineer who works in Oracle Cloud and wants the resource operations to be scripted, reviewable and repeatable, that focus is an advantage. For a team with a multi-cloud estate looking for one tool to rule them all, this is the wrong repository, because adopting it does not reduce the number of clouds you operate, it adds a second interface alongside whatever you already use. The project is open source, with its own contributing guide and a code of conduct in the repository.

## Interactive mode is the answer to a large command surface

The design problem for a CLI covering a whole cloud is that the command tree becomes too large to remember. The readme addresses this with interactive features, listed as suggestions and autocompletion to help compose commands, colour-coded suggestions to distinguish required parameters from optional ones, and quick references displayed alongside suggestions to recognise what a command or parameter is for. You enter that mode with the -i option, and it is available at any time:

```bash
    oci -i
```

That is a meaningful difference from a plain argument parser, and it is the feature most likely to change how you use the tool day to day. A cloud CLI is only usable if you can discover what the command is called without leaving the terminal and opening documentation in a browser tab. The interactive mode is the built-in answer to that problem, and it is worth knowing that it exists before you conclude that the tool is too big to learn. The ordinary help output is available too, in two forms, with the long form and the short form:

```bash
    oci --help
```

The readme itself points out that the detailed usage examples live in the OCI documentation rather than in the repository, under the section named Example Commands, so the repository is the reference for the tool and the documentation site is the reference for the commands.

## Five install routes, and an offline path for locked down networks

Installation is the best-documented part of the project, which makes sense for a tool that has to exist on many platforms. On macOS it goes through Homebrew:

```bash
    brew install oci-cli
```

On Linux the documented route is the install script fetched over the network:

```bash
    bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"
```

Packaged installs exist for specific distributions, with yum on Oracle Linux 7 and dnf on Fedora:

```bash
    sudo dnf install oci-cli
```

and Windows has its own PowerShell one-liner. The offline route is the part worth knowing about if you work in an environment without internet access. You go to the CLI releases page, locate the version you need, use the Assets area, download the zip for your operating system, copy it to the target machine, unzip it and run the installer from inside the unzipped folder, with a shell script on Linux and a PowerShell script on Windows:

```bash
       bash install.sh --offline-install
```

There is also a container image. The readme states that oci-cli is now available as container images, pullable from the GitHub Container Registry with a standards-compliant container runtime engine, and that previous image versions are on the project's package page. For a platform team that would rather not run a Python installer script on a host, that is the cleanest route, and it also gives you a versioned artefact to pin.

## A Python package with a long pinned dependency list

The repository is a Python project with a setup.py, a setup.cfg, a requirements.txt and a src directory, and the dependency pinning is unusually aggressive, which tells you how carefully Oracle tracks supported versions. The core requirement is the OCI Python SDK at oci==2.189.0, exactly pinned, and around it sit bounds on everything else. click is handled with two separate ranges depending on interpreter version, a tighter range below Python 3.11 and a different one from 3.11 upward. cryptography and pyOpenSSL are likewise split, with older ceilings for interpreters up to 3.7 and newer floors from 3.8. The requirements file shows the same structure for the test and coverage tooling, with pytest pinned to one version for Python 3.10 and below and a much newer one from 3.11, and sphinx pinned per interpreter minor version band. A few entries in the requirements file are flush left and give the shape of the runtime set:

```text
aiohttp<3.13.0
arrow>=1.0.0,<2.0.0
oci==2.189.0
```

The comment at the top of that file explains why it exists as a separate artefact at all, since the file format does not support the --trusted-host option and an --extra-index-url may be needed instead. Reading the dependency list tells you the real cost of adopting the tool, which is not the SDK but the surrounding pins that have to be reconciled with whatever is already in your environment.

## A fast release cadence means your version pin is a real decision

The release pattern is worth understanding before you build automation on top of the tool. The record shows three releases in the space of a fortnight, v3.94.2 on 2026-10-06, v3.95.0 on 2026-10-13 and v3.95.1 on 2026-10-20, and the last push to the repository was on 2026-10-20 as well. The last push being the same day as the newest release tells you that the master branch is the source of the published version rather than something that lags behind it. For a script that runs in CI, that cadence cuts both ways. You get fixes quickly, and you also get a moving target, because a version of the CLI that was correct last month may behave differently now. The changelog is maintained as CHANGELOG.rst in the repository, and the readme points to it for changes, which is the file to check before bumping a pinned version. Note also that the version in the package metadata is separate from the CLI version: the version string in the source is parsed out of src/oci_cli/version.py by setup.py at build time, and the setup script raises an error if it cannot find it, so the source of truth for the version lives in the code rather than in the setup file.

## Licensing, known issues and the limits of the repository itself

The licence is permissive but described in a way that deserves attention. The readme states that the SDK and sample are dual licensed under the Universal Permissive License 1.0 and the Apache License 2.0, and the header comment in setup.py says the same and adds that you may choose either. The repository metadata marks the licence as a custom one that GitHub cannot classify, which is a consequence of the dual licensing rather than a restriction, and the actual text sits in LICENSE.txt with THIRD_PARTY_LICENSES.txt alongside it and a NOTICE.txt at the root. The readme also lists where known problems live, including the OCI known issues page, a COMMON_ISSUES.rst file in the repository and the GitHub issues tab, which tells you that a CLI this wide is expected to have service-specific rough edges. The last thing to note is where the documentation boundary sits. This repository is the tool, its build and its changelog, and every command reference, the installation guide, the troubleshooting notes and the example commands live on the OCI documentation site, so a self-contained offline copy of the documentation is something you have to assemble yourself.

## Conclusion

oci-cli is the right tool for an engineer who already has an Oracle Cloud tenancy and wants repeatable, scriptable operations against it, especially where the container image or the offline zip avoids pulling dependencies from the internet. It is the wrong tool if you need a provider-neutral multi-cloud interface, since every command and every flag is tied to one cloud and one API, and it is a poor fit for a team that wants stable command names, because the release cadence is frequent. Verify first that your tenancy and API signing configuration work with a single oci --help and one read-only call, and that the Python version on your machine falls inside the range the pinned dependencies allow. The last push was on 2026-10-20 and the current release is v3.95.1 from the same day.

## FAQ

### How do I install oci-cli on macOS?

Use Homebrew with brew install oci-cli. Linux has a script based route, and there is also a yum package for Oracle Linux 7 and a dnf package for Fedora.

### What does the -i option do in oci-cli?

It turns on the interactive features, which give suggestions and autocompletion, colour-coded required and optional parameters, and quick reference text displayed alongside the suggestions.

### Can I install oci-cli without internet access?

Yes. Download the zip for your operating system from the Assets area of the CLI releases page, copy it to the target machine, unzip it and run bash install.sh --offline-install on Linux, or install.ps1 -OfflineInstall on Windows.

### Is there a container image for oci-cli?

The readme states that oci-cli is available as container images, pullable from the GitHub Container Registry with a standards-compliant container runtime engine, with previous image versions listed on the project package page.

### What licence is oci-cli released under?

It is dual licensed under the Universal Permissive License 1.0 and the Apache License 2.0, and you may choose either. The full text is in LICENSE.txt, with third party licences in THIRD_PARTY_LICENSES.txt.

## Sources

- [Issues](https://github.com/oracle/oci-cli/issues)
- [oracle/oci-cli on GitHub](https://github.com/oracle/oci-cli)
- [Project website](https://cloud.oracle.com/cloud-infrastructure)
- [README](https://github.com/oracle/oci-cli/blob/master/README.md)
- [Releases](https://github.com/oracle/oci-cli/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oracle-oci-cli