Why this step matters more than it looks
Your tracker is where your team has already agreed what matters. Priorities live there. States live there. Owners live there. Ship treats the tracker as the source of truth for all of that — it never invents a priority of its own, never decides on your behalf that something is more urgent than something else, never changes a state without an action a human can trace.
If the tracker says "ready," Ship can act. If it says "blocked," Ship waits. The tracker is the contract.
One tracker per workspace. Two trackers means two contracts, which means an argument every Friday afternoon. You can switch later if your team migrates; you can't run two at once.
Pick the tracker you already use
Don't switch trackers to get Ship. Bind whatever your team is already living in. If three people are using Linear and two are using Notion-as-a-tracker, fix the disagreement first. Ship makes a sloppy tracker faster; it doesn't make a contested tracker calmer.
Five options today.
Linear has the lightest setup. You generate a workspace key in your Linear settings, paste it into Ship, and Ship picks up your team list, projects, and workflow states. If your team is already on Linear, this is the lowest-friction path.
Jira binds with four pieces: your Jira Cloud site (yourorg.atlassian.net), the email you authenticate with, an API token you generate in Atlassian, and the project key you want as default. Self-hosted Jira works the same way with your own host. Bind to one project to start, not the whole portfolio.
GitHub Issues is the easiest path because you've already done the work: the GitHub app you installed for repos is the same credential. No additional setup. Eligible issues come from the repos you've already activated. If you're not sure which to pick, this is the path of least resistance.
GitLab asks for the host (gitlab.com or your self-hosted URL), a default group, and a personal access token with project read/write scopes. The group acts as a scope: Ship only sees issues inside it.
Azure DevOps asks for your organization, your default project, and a personal access token. One thing to remember: Azure tokens expire by default. Set a calendar reminder for ninety days from when you create it — if it expires silently the binding fails silently, and Ship just stops finding work.
What happens after you bind
Ship reads your projects, states, and labels and shows them back to you for a quick confirmation. You'll see the workflow states your tracker uses, mapped onto the ones Ship recognizes — usually "todo" or its equivalent is where automation enters work. If your tracker has custom states the mapping isn't obvious for, you'll be asked.
You'll also pick a default project: where new tickets land when something Ship does requires creating one. Most teams point this at the active sprint project or the team's working backlog.
Trackers are not orchestrators
A small clarification because we keep getting asked. GitHub, GitLab, and Azure DevOps host code and run automated builds. Their issue surfaces can stand in for a tracker, and we support them as such. But running the work is a separate layer from deciding which work to run. Most teams keep the priorities in a dedicated tracker (Linear, Jira) and let the code host focus on execution. That's the cleanest split, but not required.
When the tracker isn't on this list
If your team uses something not on this list, the lowest-ceremony fallback is GitHub Issues — assuming your code is on GitHub anyway. Let us know what you'd want supported; we add new trackers based on which gaps show up first.
The next part of these docs walks the chat window, which is where most of your actual work in Ship happens.