Atlassian acli vs atlassian-cli: Official Tool vs Independent Open-Source CLI

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

The short answer

Search for acli Atlassian and you land on two very different things with confusingly similar names. acli is Atlassian's official, first-party command-line interface, built and supported by Atlassian. atlassian-cli is an independent, community-maintained, MIT-licensed open-source binary that is not affiliated with Atlassian. Both talk to Atlassian Cloud over its REST APIs, but they are separate projects with different owners, licenses, and support models.

The decision is mostly about what you value. If you want first-party vendor backing, official documentation, and a tool that ships from Atlassian itself, use acli. If you want a single free open-source binary that spans Jira, Confluence, Bitbucket, and Jira Service Management with scriptable JSON and CSV output, atlassian-cli is built for that. Neither choice is wrong, and plenty of people keep both installed.

What is Atlassian's acli?

acli is Atlassian's official command-line tool. Because it is a first-party product, it comes with the things you expect from a vendor tool: official installation and command documentation, vendor support channels, and lifecycle backing from Atlassian. If your organization requires vendor-supported tooling for compliance or procurement reasons, an official CLI is often the natural fit.

The authoritative source for acli, including how to install it, which products it targets, and its exact command surface, is Atlassian's own documentation at developer.atlassian.com/cloud/acli. We deliberately do not restate acli's feature specifics here, because those details are Atlassian's to define and can change over time. Always check the official page for the current, authoritative scope.

What is atlassian-cli?

atlassian-cli is an independent open-source project. It is a single Rust binary distributed under the MIT license, with its full source public on GitHub. It is not made by Atlassian and does not carry vendor support; help comes from the project's GitHub issues and community.

Its defining trait is breadth from one binary. A single install gives you commands across four Atlassian products:

• Jira: issue search, create, update, transition, assign, plus sprint and bulk operations.
• Confluence: pages, spaces, CQL search, folders, attachments, bulk operations, and analytics.
• Bitbucket: repositories, branches, pull requests, pipelines, permissions, and webhooks.
• Jira Service Management: service desks, requests, queues, approvals, SLAs, and customers.

Every command supports machine-readable output (--format json|csv|yaml) so results pipe cleanly into jq, spreadsheets, or CI pipelines. You can browse the complete surface in the command reference.

acli atlassian vs atlassian-cli at a glance

Here is a factual side-by-side. Where a cell points to Atlassian's docs, that is intentional: those specifics belong to Atlassian and are best read from the authoritative source rather than restated here.

The pattern is clear: acli's value is official standing and vendor support; atlassian-cli's value is an open, free, multi-product binary you can read, fork, and script. For a wider look at the CLI landscape, including other community tools, see Jira CLI tools compared.

When to choose acli

Reach for Atlassian's official acli when official standing matters more than anything else. Common reasons:

• You need vendor support. If a broken command has to go through a support contract, a first-party tool is the right call.
• Procurement or compliance requires it. Some organizations only permit vendor-provided tooling for touching production systems.
• You want the canonical reference. As the official CLI, acli's behavior is documented and maintained by Atlassian directly.

In all of these cases, start at the official acli documentation for install instructions and the current command set.

When to choose atlassian-cli

Reach for atlassian-cli when you want an open, free, scriptable tool that covers more than one Atlassian product from a single binary:

Authentication is the first step, and it uses your own Atlassian API token. Set up a profile once:

# Authenticate with your own Atlassian API token
atlassian-cli auth login \
  --profile work \
  --base-url https://your-team.atlassian.net \
  --email you@example.com \
  --token $ATLASSIAN_TOKEN \
  --default

# Verify the profile works
atlassian-cli auth test --profile work

See the authentication guide for API-token creation and multi-profile setups.

Can you use both together?

Yes, and it is a perfectly reasonable setup. acli and atlassian-cli are separate binaries with different names, so they do not conflict on your PATH. Both authenticate with your own Atlassian credentials against the same instance, and neither changes anything about the other.

A practical split many teams land on: use the official acli where vendor support or policy requires it, and use atlassian-cli for quick cross-product scripting, bulk cleanups, and exports where a single open binary with JSON output is convenient. The tools are complementary, not mutually exclusive.

atlassian-cli in practice

To make the independent option concrete, here are real, copy-pasteable atlassian-cli commands that show why people keep it around for scripting.

Query Jira and pipe to jq

# Search issues, get machine-readable JSON, extract keys
atlassian-cli jira issue search \
  --jql "project = DEV AND status = 'In Progress'" \
  --format json | jq '.[].key'

Create and transition an issue

atlassian-cli jira issue create \
  --project DEV --issue-type Task \
  --summary "Ship release notes"

atlassian-cli jira issue transition DEV-123 \
  --transition "In Progress"

Bulk operations with a dry run

# Preview first: nothing is modified
atlassian-cli jira bulk transition \
  --jql "project = DEV AND status = Open" \
  --transition "In Progress" \
  --dry-run

The --dry-run flag on every bulk command shows exactly what would change before you commit. For a production-grade workflow, see the bulk transition runbook.

Cross-product, one binary

# Confluence: create a page
atlassian-cli confluence page create \
  --space DEV --title "Release Notes" \
  --body "<p>Shipped today</p>"

# Bitbucket: list open pull requests
atlassian-cli bitbucket --workspace myteam pr list api-service --state OPEN

# JSM: list requests in a service desk
atlassian-cli jsm request list --servicedesk-id 10 --limit 25

That single-binary reach across Jira, Confluence, Bitbucket, and JSM is the main reason to add atlassian-cli alongside whatever official tooling you already run. For command-by-command detail, the acli Jira commands guide and the best Atlassian CLI tools of 2026 both go deeper.

FAQ

Related Resources