Camelopard
A fast alternative to the Jira web UI for your Scrum board, on Jira Server and Data Center. It responds instantly: an issue opens in about 35 ms, the board shows in under 150 ms. On top of the speed, it brings features that Jira's board lacks.
Features
What Jira's board doesn't do
- A detail panel that leaves the board alone: it opens over the board, on the side away from the card, so the board never resizes, reflows or flickers. Or dock it at the bottom, in three columns: the whole issue in sight, without scrolling.
- No login page, no SSO redirects: Camelopard reaches Jira with your personal access token, so the board is there as soon as the tab opens, even when the browser restores yesterday's tabs. No sign-in form, no wait for the company's single sign-on.
- Description changes as a real diff: where Jira strikes the whole old text through and repeats the new one, Camelopard shows only the lines that changed, with the changed words marked.
- Planned sprints as a board: a sprint planned ahead opens in the board's columns, not as a list in the backlog.
- Stand-up mode: go round the team person by person, with what each one did since the previous working day.
- Less scrolling: when the window or the zoom leaves room, cards sit side by side within each column.
- The keyboard for everything: move between cards with the arrows, jump to a section of the detail by its first letter, assign with A; ? lists the shortcuts.
- Drag across the workflow: drop a card in any column and it walks the statuses in between for you.
- Since your last visit: the column moves, assignments and comments others made while you were away, and browser notifications when someone changes an issue assigned to you.
- Search as you type, with keywords:
@me,type:bug,-label:back. - Your own views: on a board of many columns, each role picks the columns it works on, in your own configuration, without Jira admin rights.
- Several cards at once: pick them, copy them as a list with links to Jira, assign or move them together.
- Links stay in the panel: a link to another issue opens it in the panel, not in a new Jira tab.
And everything you already use in Jira
- The board's columns, epics and quick filters, as configured in Jira.
- Filters by status, reporter, type, priority and epic.
- The issue's fields, description, links and attachments.
- Comments and history together, in time order, as in Jira's All tab.
- Rank, status and assignee changed from the board.
- Active and planned sprints of the board.
- Light and dark themes.
A day without opening Jira
Reading the board, following the sprint, moving an issue, assigning it: Camelopard covers most of what a day asks of Jira. Jira itself is only needed for the rest, such as creating an issue or editing other fields: some hours into the day, and some days not at all.
The rest can skip the browser too. An AI coding agent, such as Claude Code or Codex, can write a description or create an issue through Jira's API, with the same personal access token.
Try it in three commands
The demo comes with its own sample board, so you can try everything without a Jira server, a token or any configuration.
git clone https://github.com/YannRobert/camelopard.git
cd camelopard
python3 demo/run.pyThen point it at your own board: the README explains the configuration and the personal access token it needs.
Measured, not promised
Jira's board feels slow? Below 100 ms, a response feels instant. Median times over repeated runs of the demo:
| Action | Median | 9 runs out of 10 |
|---|---|---|
| Open an issue (click to detail drawn) | 35 ms | 90 ms or less |
| Reload the board (to first card drawn) | 85 ms | under 90 ms |
| Reload the board, Jira slowed down by 1.5 s | 140 ms | under 160 ms |
| Local server answer for an issue | 2 ms | 2 ms |
Measured with headless Chromium on a Linux laptop (Intel Core i7-10750H), against the demo. The first visit from a new browser waits for Jira once, to fetch the board; after that, the board and the issues come from the cache.
How it works
A very small server runs on your machine and keeps the board in a cache, refreshed in the background, much like a browser cache. Once the board has been loaded, the page reads the cache and never waits for Jira.
- Far fewer Jira requests: the whole board comes in one call, then only the issues that changed. A counter shows the load put on Jira.
- Nothing to install but Python 3, which most Linux machines already have: no dependency, no framework, no build, no administrator rights. Start it from a terminal, or let it start with the computer, as a systemd service, a macOS LaunchAgent or a Windows startup shortcut. Without Python on the machine, the python.org installer can install it for the current user only.
The README gives the exact requirements.
Security
- The local server listens on
127.0.0.1only, and rejects any other host name, so that a web page cannot reach it through DNS rebinding. - The personal access token comes from the
JIRA_PATenvironment variable of your user account. Camelopard never writes it to a file and never sends it to the browser. - The cache is written to disk, as JSON files in your user cache directory (
%LOCALAPPDATA%on Windows,~/Library/Cacheson macOS,~/.cacheon Linux). It can be deleted at any time and rebuilds itself. - Camelopard talks to your Jira server and nothing else: no telemetry, no third-party service.
- Only reads are relayed, to the paths the page needs. The only writes are the rank, assignee and status changes you make, built by the local server from validated values.
The full security model is in the README; vulnerabilities are reported privately, as SECURITY.md explains.
Current limits
- Jira Cloud is not supported yet: Camelopard speaks the Jira Server and Data Center API.
- Camelopard shows the sprints of a Scrum board, active and planned. Kanban boards, which have no sprints, are not supported yet.
- On the board, you can change the rank, the assignee and the status of an issue. Anything else is edited in Jira, one key away from the detail panel.