One CLI for Jira, Confluence, and Bitbucket

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.

Why one CLI for Jira, Confluence, and Bitbucket?

If you want a single CLI for Jira, Confluence, and Bitbucket, the short answer is atlassian-cli: one binary that talks to all of them, plus Jira Service Management, using the same flags and the same config file. You install one tool, authenticate once per site, and every product becomes a subcommand.

Most teams end up with a drawer full of half-scripts. A Python snippet hits the Jira REST API. A separate curl loop pushes pages to Confluence. Bitbucket gets its own token and its own wrapper. Each one has different auth, different pagination, and different output shapes, so gluing them together means writing adapter code before you write anything useful.

A single cross-product CLI collapses that. The Jira, Confluence, Bitbucket, and JSM command groups all live under one atlassian-cli entry point. They share global flags like --profile and --format, they read the same credentials, and they emit the same JSON envelope. That means a release script, an audit job, or a nightly cron can move data between products without translation glue.

One install, one config, one auth profile

The whole idea rests on one config file. atlassian-cli stores credentials in ~/.atlassian-cli/config.yaml, keyed by named profiles. You log in once for a site, and that single profile authenticates Jira, Confluence, and JSM (which all share an Atlassian Cloud API token), plus Bitbucket.

# Authenticate once for a site, drives Jira, Confluence, and JSM
atlassian-cli auth login \
  --profile work \
  --base-url https://your-team.atlassian.net \
  --email you@company.com \
  --token "$ATLASSIAN_TOKEN" \
  --default

# Confirm which profiles exist and which is the default
atlassian-cli auth list
atlassian-cli auth status
atlassian-cli auth whoami --profile work

From that point on, every product is a subcommand of the same binary, and every command accepts --profile <name> if you need to target a second site or a personal account:

# Jira
atlassian-cli jira issue search --jql "project = DEV order by created desc" --limit 5

# Confluence
atlassian-cli confluence page list --space DEV --limit 25

# Bitbucket (bb is an alias for bitbucket)
atlassian-cli bitbucket --workspace myteam pr list api-service --state OPEN --limit 5

# Jira Service Management
atlassian-cli jsm request list --servicedesk-id 10 --limit 25

A single profile can hold both an Atlassian API token (for Jira, Confluence, and JSM) and a Bitbucket token, so --profile work resolves the right credential for whichever product you call. You can manage them independently when you need to: atlassian-cli auth logout --profile old --bitbucket removes only the Bitbucket token and leaves the rest of the profile intact.

To switch the default profile later, re-run auth login --default for the profile you want, or edit default_profile: in the config file directly. See the Authentication & Profiles guide for token setup and multi-site patterns, and if you are weighing token types, the API token vs PAT comparison explains which one to use where.

How this differs from Atlassian's acli

atlassian-cli is an independent, community open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with Atlassian. Use the official acli for first-party vendor support; use atlassian-cli if you want a single free Rust binary spanning Jira, Confluence, Bitbucket, and JSM with one config file and one output format.

The project is MIT-licensed and distributed as a single self-contained binary, so there is no runtime to install and nothing to keep in sync across machines. That is the practical reason it works well in CI: drop the binary in, point it at a profile, and run.

What one binary covers

Here is the mental model. One executable, four product namespaces, each with its own verbs. Every row below is driven by the same install and the same credentials.

Each namespace goes much deeper than these examples: Jira has search, create, transition, assign, sprints, and bulk operations; Confluence covers spaces, pages, blog posts, folders, attachments, and CQL search; Bitbucket handles repos, branches, pull requests, pipelines, and permissions. The full list lives in the command reference, and the atlassian-cli cheat sheet is the quickest way to keep the common ones handy.

A script that spans all three products

This is where a single CLI earns its keep. A typical release touches all three products: you merge a reviewed pull request in Bitbucket, close the linked Jira issue, then publish a release note in Confluence. With three separate tools that is three auth setups and three output formats to reconcile. With one binary it is one script.

#!/bin/bash
# Ship a release: merge the PR, close the Jira issue, publish release notes
set -euo pipefail

WORKSPACE="myteam"
REPO="api-service"
PR=123
ISSUE="DEV-742"
SPACE="DOCS"

# 1. Merge the reviewed pull request in Bitbucket
atlassian-cli bitbucket --workspace "$WORKSPACE" pr merge "$REPO" "$PR" \
  --strategy merge_commit

# 2. Move the linked Jira issue to Done
atlassian-cli jira issue transition "$ISSUE" --transition "Done"

# 3. Publish a release note as a Confluence blog post
atlassian-cli confluence blog create \
  --space "$SPACE" \
  --title "Release: api-service $(date +%Y-%m-%d)" \
  --body "<p>Merged PR #$PR, closed $ISSUE.</p>"

echo "Release shipped."

Because it is one tool, there is nothing to translate between steps. The same --profile flag would target a staging site; the same error handling wraps all three calls. You can drop this into a Bitbucket Pipeline or a GitHub Actions job and it runs the same way it does on your laptop.

The reverse direction works too. Say you run a weekly audit that pulls open bugs from Jira, checks which repos have stale pull requests, and confirms the docs space still exists:

# Weekly cross-product audit
atlassian-cli jira issue search \
  --jql "project = DEV AND type = Bug AND status != Done" \
  --format json | jq 'length'

atlassian-cli bitbucket --workspace myteam pr list api-service \
  --state OPEN --format json | jq '.[].id'

atlassian-cli confluence search cql \
  "space = DOCS and type = page" --limit 1

One output format for every product

The other payoff of a single CLI is a single output contract. Every command accepts --format (or -f) with the same choices: table, json, csv, yaml, quiet, and markdown. Learn the flag once and it works the same across Jira, Confluence, Bitbucket, and JSM.

# Human-readable table (default)
atlassian-cli jira issue search --jql "project = DEV"

# JSON for piping into jq, identical shape across products
atlassian-cli bitbucket --workspace myteam pr list api-service --format json | jq '.[].title'

# CSV for a spreadsheet
atlassian-cli jira issue search --jql "project = DEV" --format csv --output issues.csv

# Quiet, exit code only, useful for CI gating
atlassian-cli auth test --profile prod --format quiet && echo OK

For list output, add --envelope to wrap JSON or YAML in {"data": [...], "count": N}. That gives downstream scripts a stable place to read the count and the rows, no matter which product produced them. When every command speaks the same JSON dialect, chaining them together stops being an integration project and becomes a two-line pipe.

New to the whole tool? Start with the atlassian-cli guide for the full walkthrough, then keep the cheat sheet open while you work.

Wiring it into CI

A single binary is easiest to appreciate in automation, where installing three separate tools and managing three sets of secrets is real friction. In a pipeline you do not run auth login interactively; you feed the token in from a secret and log in non-interactively, then gate the rest of the job on a health check.

# In CI: authenticate from a secret, then verify before doing work
atlassian-cli auth login \
  --profile ci \
  --base-url https://your-team.atlassian.net \
  --email "$ATLASSIAN_EMAIL" \
  --token "$ATLASSIAN_TOKEN" \
  --default

# Fail fast if credentials are wrong, exit code only, no noise
atlassian-cli auth test --profile ci --format quiet || exit 1

# Now any product command runs against the same profile
atlassian-cli jira issue transition "$ISSUE" --transition "In Review"

The same binary works in a Bitbucket Pipeline, a GitHub Actions job, or a plain cron entry. Because there is no runtime to provision, the install step is a single download, and the credential story is one token (two if you also touch Bitbucket) rather than a different auth flow per product. If something misbehaves, add the global --debug flag to any command to log the underlying HTTP request and response, which is usually enough to see whether a 4xx is an auth problem or a bad JQL query.

That consistency is the quiet advantage of a cross-product CLI. You are not learning three tools, memorising three flag conventions, or reconciling three output shapes. You learn one set of verbs, one config, and one JSON envelope, and it applies whether you are closing a sprint, backing up a Confluence space, or auditing pull requests across a workspace.

FAQ

Related Resources