For those deep in the Oracle Cloud Infrastructure (OCI) trenches, the command-line interface (CLI) can feel less like a tool and more like an adversary. We’re talking about developers, DevOps engineers, and MSPs wrangling multiple tenancies for production, staging, dev environments, and a gaggle of client accounts. The expectation for years has been a streamlined experience, especially with the growing complexity of cloud deployments. What we’ve largely gotten, however, is a repetitive battle with long, obscure identifiers.
This is where the friction truly bites. The OCI CLI already mandates the --compartment-id flag on what feels like every conceivable command. These IDs, essential for resource isolation, are anything but memorable. Add to this the necessity of managing distinct accounts—think prod, staging, dev, and numerous client environments—and the --profile flag, tacked onto the already burdensome --compartment-id, transforms routine tasks into a slog. It’s the kind of operational drag that erodes productivity and breeds errors.
The market for cloud developer tools is intensely competitive, and efficiency is paramount. Companies often tout integrations and simplified workflows, but the reality on the ground, particularly with legacy or more complex enterprise clouds like Oracle’s, can fall short. The demand for tools that genuinely reduce cognitive load for engineers working at scale is immense.
Does This Solve the OCI Multi-Tenancy Conundrum?
The latest entrant aiming to address this persistent annoyance is a humble open-source script called ocswitch. Developed by an engineer clearly fed up with the status quo, it tackles the core problem: the tedious, session-scoped nature of switching between different OCI configurations.
The OCI CLI’s native handling of multiple profiles involves either cramming them all into a single ~/.oci/config file and explicitly calling --profile each time, or relying on environment variables like OCI_CONFIG_FILE and OCI_CLI_PROFILE. The issue? These variables are typically session-bound. Open a new terminal window, and you’re back to square one, defaulting to whatever’s set in [DEFAULT], or worse, potentially hitting the wrong environment.
ocswitch’s primary innovation lies in its persistence. It achieves this by writing the currently active profile name to a dedicated file, ~/.oci/active_profile. When your shell starts up, it sources this file and automatically sets the necessary environment variables, ensuring your chosen OCI profile follows you across terminal sessions without manual intervention.
This approach neatly sidesteps the limitations of the native tooling. Instead of relying on per-command flags or volatile environment variables that vanish with your terminal session, ocswitch establishes a persistent state. The setup itself is straightforward: profiles are stored as separate configuration files, e.g., ~/.oci/config_prod, ~/.oci/config_staging, and so on. A simple command like ocswitch prod then updates the state file and exports the required environment variables for your current shell.
The persistence part lives at the top of the script, outside the function, so it runs every time the shell sources the file.
This ensures that even after closing and reopening your terminal, the correct OCI configuration remains active. It’s a small change in workflow—a single command to switch—but the cumulative time and mental overhead saved over weeks and months can be substantial for engineers who frequently navigate multiple environments.
Beyond Simple Switching: Enhanced Usability
ocswitch doesn’t stop at just profile management. It includes a list command that helpfully enumerates all detected profiles (matching the ~/.oci/config_* pattern) and clearly highlights the active one. A clear command provides an easy way to reset the active profile. Crucially for developer experience, tab completion is integrated for both Bash and Zsh, making it simple to see available commands and profile names.
Perhaps one of the most practically useful features, especially in high-stakes environments where misconfigurations can lead to costly mistakes, is the ocid command. After switching profiles, you can run ocid to quickly display the human-readable tenant name, the tenancy OCID, and your user email. This provides an immediate, unambiguous confirmation of which environment you’re operating within before executing any critical commands. It’s a crucial safeguard.
Is this a game-changer? For the niche group of OCI users managing multiple tenancies, absolutely. It addresses a genuine pain point that official tooling has, for too long, left unaddressed with adequate persistence and ease of use.
This isn’t about reinventing the wheel; it’s about making the wheel spin more smoothly. The Oracle Cloud CLI, while powerful, has historically suffered from a degree of administrative overhead that doesn’t always align with the agile development practices prevalent in the open-source community. Tools like ocswitch are vital for bridging that gap, enabling developers to focus on building and deploying, rather than wrestling with configuration.
Installation is as simple as fetching a script:
zsh
curl -fsSL https://gist.githubusercontent.com/amaanx86/2621a181e2f4b572a1904d65748d66bd/raw/ocswitch.zsh \
-o ~/.oci/ocswitch.zsh
echo 'source ~/.oci/ocswitch.zsh' >> ~/.zshrc
source ~/.zshrc
bash
curl -fsSL https://gist.githubusercontent.com/amaanx86/2621a181e2f4b572a1904d65748d66bd/raw/ocswitch.bash \
-o ~/.oci/ocswitch.bash
echo 'source ~/.oci/ocswitch.bash' >> ~/.bashrc
source ~/.bashrc
The command structure is intuitive:
ocswitch # show help + logo
ocswitch list # list profiles (active highlighted)
ocswitch <profile> # switch profile (persists across all terminals)
ocswitch clear # clear active profile
Each profile is a standard OCI config file, named config_<profile> (e.g., ~/.oci/config_prod) and containing a corresponding section header [config_prod]. This mirrors the file naming convention, adding another layer of clarity.
This tool’s success hinges on its adoption by the OCI developer community. If it alleviates the friction effectively, it could become an indispensable part of the OCI developer toolkit, much like kubectl plugins or other environment management utilities in different ecosystems. For now, it stands as a proof to the power of community-driven development in solving real-world operational challenges that vendor-provided tools sometimes overlook.
🧬 Related Insights
- Read more: RBAC for Morpheus: Beyond UI Hiding for Real Security
- Read more: Azure VMs: Cloud Computing for Everyone
