An open-source alternative to Linear
Issues with workspace keys, two-week cycles, projects, estimates, labels, sub-issues and blocking links, on the same records as the board the idea came from.
| Feature | Tuval | Linear |
|---|---|---|
| Licence and hosting | AGPL-3.0. Run it on your own Postgres and bucket; a setting marks the install self-hosted and the limits stop applying. | Proprietary, hosted only. |
| Price | Free for up to 3 people with 1 GB of files. Hosted plan ₺249 per member per month, VAT included, about $7. | Per-user subscription. We do not print a figure we cannot keep current; see their pricing page. |
| What an issue holds | A workspace key taken on insert and never reused, four priorities, a numeric estimate, labels, an assignee, a due date, sub-issues by parent, and blocking and relates-to links stored once so the two sides cannot disagree. | The same fields and more, including custom fields Tuval does not have. |
| Workflow states | A fixed set of seven. You cannot add, rename or reorder them. | Workflow states you define, per team. |
| Cycles | Fixed fourteen-day cycles one after the other, with a burn-down of points closed against points taken on. The length is a constant in the source. | Configurable cycle length and a fuller planning model around it. |
| Teams and keys | One workspace, one issue prefix. There are projects, but no teams with their own prefixes, workflows or cycles. | Teams, each with its own key prefix, workflow and cycles. |
| Keyboard | j and k to move, c to create, x to select, Enter to open, a command palette, and g-then-key to jump between screens. Nothing fires while you are typing. | A deeper and more complete keyboard model, which is what the product is known for. |
| One record, several views | An issue is the same row as the page and the canvas card. Turn a sticky from the retro into a ticket in place; drop existing issues onto a board as cards that refresh their title and status. | Issues, projects and documents, with no infinite canvas. |
| Time and repeating work | Log a stint in minutes against any record and the week adds itself up. Rules create recurring issues daily, weekly or monthly, keyed on the date so asking twice makes nothing twice. | Not part of the core product; teams add it with third-party tools. |
| Importing your existing issues | There is none. The CSV importer lands rows in a database, not in the tracker, so an export does not become Tuval issues. This is the hardest thing about switching. | Importers from the common trackers. |
| Integrations | REST API with keys hashed at rest, webhooks, and an MCP server so a coding agent can read and write the workspace. No GitHub, GitLab, Slack or Figma integration; branch and pull-request linking does not exist. | Git provider, chat and design-tool integrations, including the pull-request linking most teams build their habits on. |
| Mobile | No phone or tablet layout, by decision. Desktop browser only. | Native iOS and Android apps. |
Checked 1 August 2026. Linear is a trademark of its owner; Tuval is not affiliated with, endorsed by or sponsored by them.
Why you might not
Because there is no importer, the seven workflow states are fixed and nothing talks to GitHub; switching costs you your history and your automation.
What we do better
The tracker is not in a different tab from the thinking. A sticky on the retro board becomes an issue where it stands, keeping its place in the frame and its connectors, and the issue links back to the board it came from. The same record opens as a page or as a row in a database with formulas and rollups over it. Time logging and recurring work are built in rather than bolted on.
What Linear does better
Nearly everything a tracker is judged on. Custom workflow states, teams with their own keys and cycles, configurable cycle lengths, saved views and insights: we have a fixed seven states, one prefix and a fourteen-day constant. Their keyboard model is deeper than ours and it is what the product is famous for. They have importers, so moving in takes an afternoon; we have none. They link branches and pull requests; we do not talk to GitHub at all.
Who should not switch
Any team with issue history worth keeping: there is no importer, and asking people to retype a backlog is how a migration fails. Any team whose process needs its own states, its own team prefixes, or a cycle that is not two weeks. Anyone whose review flow runs through branch and pull-request linking. Anyone who triages from a phone.