What’s New

Last May we announced the public beta of the next-generation Anaconda Command Line Interface (CLI). One command configured conda and pixi against package sources your organization trusts. Since then, more of your workflow has moved outside the terminal where you set those sources up.

Projects move to a platform for deployment, a coding agent adds dependencies for you, and your team publishes packages to its own channel. Each step has its own configuration and sign-in, and the sources you configured in the terminal don’t carry over to any of them. Packages can enter your work from sources your organization never approved.

Today the Anaconda CLI is generally available (GA). You run it as ana, and it handles each of those steps from one tool: trusted packages, deployment, package security and policy information for your coding agent, and publishing to your channels, all in the terminal you already use.

The Anaconda CLI now asks you to sign in, which lets it configure channels for your plan and connect your agent to Anaconda.

Let’s Dig Deeper

Your project runs locally, and it’s time to move it to production. ana platform app deploy deploys it to Anaconda Platform, where it runs as a service inside your organization’s perimeter.

ana platform configure connects the CLI to your Anaconda Platform organization, using the setup string from your organization’s Local Setup page.
ana platform app deploys and manages your apps: list what’s running, check logs, and delete what you no longer need.
ana platform perimeter shows and switches the perimeter you’re working in, which sets the code, data, models, and compute your work can use.

From there, AI orchestration gives you repeatable runs; tracks models, lineage, and artifacts; and runs across cloud, hybrid, and on-premises infrastructure. These commands work on macOS and Linux with the standalone installer. Learn more about AI orchestration on Anaconda Platform.

When your agent picks a package

You ask your coding agent to add a plotting library. It picks one, with no way of knowing whether your organization allows it or whether it has a known vulnerability.

ana mcp setup connects your AI coding assistant to Anaconda Model Context Protocol (MCP), a remote server. Before the assistant chooses a package, it can check package metadata, security information, and your organization’s channel policies. Business and Custom plans include full vulnerability details.

Setup also installs the Anaconda Intelligence skill, a markdown file added to your agent’s directory, which guides it through package selection, security review, and troubleshooting. A package being available on a channel isn’t the same as your organization approving it, and the skill helps the agent tell the two apart.

The setup wizard configures AI coding assistants, including Claude Code, Codex, Cursor, Devin, Kilo Code, OpenCode, and VS Code.

The MCP service is read-only: it doesn’t install packages or enforce policy on other tools the agent uses. For more information, read the Anaconda MCP documentation.

When you publish to your channel

You’ve built a package and want it on your team’s channel. Now you can do it with the Anaconda CLI. Create public channels, or private channels (now in open beta), on anaconda.org, named in organization/channel format such as my-org/my-channel.

ana channel create makes a new channel, public or private.
ana channel upload publishes packages to it.
ana channel remove deletes a channel.

See Private channels for sharing and installing. To publish every time you tag a release, the Upload Package action for GitHub Actions does the same job from continuous integration (CI). See how to automate conda publishing with GitHub Actions.

Setup that matches your plan

main-x is an authenticated Anaconda channel that extends main with more than 13,000 additional Anaconda-curated conda packages. Run ana feature enable main-x and the Anaconda CLI checks your Anaconda subscription and adds the right channel URLs for your plan to conda, or to pixi if you add --pixi. For what’s in the channel, see the main-x GA post.

Less upkeep

The Anaconda CLI now checks for new releases and lets you know when one is out. It doesn’t upgrade itself. Run ana self update on your schedule.

Each release pins the versions of the tools the Anaconda CLI manages. When you run ana self update, it also updates eligible managed tools to those versions, so the update doesn’t pull in whatever changed upstream that week.

Setting up conda on a new machine? ana tool download miniconda downloads the right Miniconda installer for your platform. It doesn’t run the installer; you decide when and where conda should install.

Why This Matters

Your deployments, your coding agent’s suggestions, and your team’s channel now run through the same trusted package sources. Builders spend less time switching tools and looking up repository URLs.

If you set package policy for your organization, coding agents connected through the Anaconda CLI can see that policy when they choose a package.

conda and pixi keep handling your packages and environments. The Anaconda CLI connects them to the rest of your workflow without replacing either one.

Give It a Shot

Before you start: You need an Anaconda account to authenticate and use some of the features that connect to Anaconda services. Sign up to create an account.

Install the Anaconda CLI:

On Windows (PowerShell 5.1 or later):

powershell -ExecutionPolicy ByPass -Command "Invoke-RestMethod https://anaconda.sh/install.ps1 | Invoke-Expression"

On macOS (Apple Silicon) and Linux:

curl -fsSL https://anaconda.sh/install.sh | bash

Already using the beta? Update in place with ana self update.

Then: