Reading the docs…
Stopped.
What Tack is
Tack is a collaborative whiteboard for planning open source work. You put GitHub issues and pull requests on a freeform board as live cards, next to stickies, stacks, sections, connectors and decisions, and work through them with your team, live or over days, on a computer, a tablet or a phone.
Arranging a board never touches GitHub. When the session has produced something worth keeping (new issues, labels, a milestone, links between issues, a decision record), you stage it, review it as one batch, and push it. Until then, nothing changes on GitHub.
Tack is open source (MIT) and self-hosted: each instance is one Cloudflare Worker and a GitHub App you own. There’s no hosted service. See Deploy Tack, or try it in your browser first.
The rules Tack keeps
Section titled “The rules Tack keeps”These decide how every feature behaves:
- GitHub is the source of truth; the board is a lens. Tack stores the layout, the stickies and the things GitHub has no home for (votes, decisions in progress, comments on the board). It never keeps its own copy of an issue’s state: a card shows what GitHub says, and updates when GitHub changes.
- Moving things never changes GitHub. Only explicit actions do, and they’re staged, previewed and pushed as a batch. See Writing back to GitHub.
- Automation adds, people arrange. Inboxes and rules can put cards on a board, but never move or delete what someone placed.
- Async first. Everything that works in a live session also works across time zones over days: votes stay open, comments thread, and since you were here shows what changed while you were away.
- Boards aren’t owned by a repository. A board can hold items from any repository. Public repositories work with no setup; installing the GitHub App on a repository makes its cards live and lets Tack write to it.
Who sees what
Section titled “Who sees what”You sign in with GitHub, and GitHub decides what you can see and do:
- Cards from a private repository only show their details to people who can read that repository on GitHub. Everyone else on the board sees a “Private” placeholder. Being on a board never grants access to a repository’s data.
- Pushing writes to GitHub with your own permissions: if you can’t write to a repository, you can stage changes there but not push them.
- Board roles (owner, editor, viewer) decide who can change the board itself. See Boards and sharing.
What’s on a board
Section titled “What’s on a board”| Thing | What it’s for |
|---|---|
| Cards | Live GitHub issues and pull requests: state, labels, assignees, CI and reviews |
| Stickies and text | Ideas, notes and headings. Stickies can become issues |
| Stacks | Stickies, issues and pull requests gathered into a named theme. A stack can become a parent issue |
| Sections | Frames that hold things. A section can become a parent issue, an inbox, a silent brainstorm or a vote |
| Connectors | Arrows between things. A connector between two issues can become a blocked-by link |
| Decisions | Proposals people vote on, decided, then written back as an ADR pull request or a Discussion |
| Action items | Who’ll do what by when, following their issues, and carried into the next session |
| History | The board over time: replay it, see who changed what, bring back what was removed |
| Widgets | Live searches and views: lists, a timeline, a release draft, a dependency map, a review queue, a milestone and a stale finder |
| Custom widgets | Your own code, in a sandbox, drawing the board’s data |
Cards can also come from GitLab, Codeberg, Forgejo and Tangled, and AI can name stacks, set up a widget from a sentence, summarise and draft decisions, always shown to you first.
Next, take the two-minute tour.