Self-Hosted Kanban Boards: Own Your Data Without Losing Features
By Sebastiaan Jansen · · 7 min read
A self hosted kanban board is a kanban tool you install on hardware you control, so cards, comments, and attachments stay in your own database. The columns, the WIP limits, and the path from "to do" to "done" work the same way. What changes is who holds the data and who patches the software.
Teams look for one when a contract bars another SaaS tenant, a security review blocks a vendor login, or the board is the system of record and a later export looks painful. The server still has to work as a delivery system.
What a self hosted kanban board is for
The board is the view. The database is what you protect, on a rack VM, a private cloud account, or one office machine. If you cannot point at the file and name who may copy it, you do not have a self hosted kanban board yet.
Self-hosting is about deployment, and open source is about the license. A proprietary installer can run on your machine, and open source code on a shared platform can still give the data away. Read the license first, then find the SQLite or Postgres files.
Three jobs get mixed up. A personal list is one person's work. A team board is shared work with owners, states, and a definition of done. A delivery system tracks that work against a repo, a cycle, and a forecast. A server is wasted on the first, and the third needs history, not only the current column. For columns, WIP, and pull, read what a kanban board is before you pick a host.
Self hosted kanban vs a hosted account
A hosted account starts faster because someone else runs backups, TLS, and upgrades. You pay a subscription, sign a data-processing agreement, and take whatever export you get on the way out.
Self hosted kanban takes longer, and the disk, the auth, the upgrades, and the restore are yours.
| Decision | Hosted board | Your own server |
|---|---|---|
| Where cards live | Vendor database | Your disk or database |
| Time to first column | Minutes | Hours, sometimes a day |
| Backup owner | Vendor, plus your exports | You |
| Auth | Vendor SSO | Whatever you wire up |
| Upgrades | Vendor picks the window | You pick it, and the rollback |
| Leaving | Export, then rebuild views | You already have the files |
Trello is easy to teach but weak once work needs repo context, WIP, and a record of why a card moved. Jira can model almost any workflow and is heavy to administer, hosted or not. Atlassian's kanban overview covers the method. A tool that fits badly still fits badly on your own hardware.
Open source kanban is a license, not a feature list
Open source means you can read, run, and change the code. It does not promise triage, roadmaps, forecasts, or anyone answering on a Friday night.
Before you adopt a kanban tool open source communities maintain, check the license and the last year of releases. Restore a dump and confirm that attachments and comments survive. A quiet repo can hold columns, and a busy one is wrong if every report is a plugin you would maintain. An open source kanban project is a start. Running it, the auth, and the backup drill are the job.
Features you should not trade away
Each ticket type needs its own stages, because bugs, client requests, and chores take different paths. "Waiting on customer" belongs off the engineering board and out of cycle time.
Triage assigns an owner and a decision: accept, reject, or ask for a better repro. Skip it and the left column becomes a landfill, and WIP limits mean nothing.
Review rollover when a cycle ends. Silent copies hide a team that pulled in more than it finished.
Count the roadmap from tickets. A slide goes stale within a week, while a filter stays current, including work nobody has started.
Cumulative flow shows arrivals against departures. Percentiles survive one long ticket, and a Monte Carlo forecast on finished work beats a date picked in a meeting. Two thousand runs settles a percentile. Publish the range and the history window. How work should move still applies, because nobody else sees a column that only grows.
Keep one database you can copy: SQLite, or a single Postgres database with a known schema. Week one can be columns only, but an export that drops comments or created dates does not count as a success.
A worked example: one team, one week of intake
Northwind has eight people, 140 open cards, a client who wants data kept in one region, and a git host they already run.
- 46 defects have a repo and a stack trace or error link.
- 31 client requests came from Slack or a call and have no owner.
- 22 chores are unfinished.
- 41 cards are older than 90 days and have been silent for 60. Close each one, or rewrite it in a sentence.
Leave those 41 out. They would look new and behave like the old landfill. A few columns work better than one column per status, and these board examples show why.
| Column | WIP | Rule |
|---|---|---|
| Triage | 10 | Accept, reject, or ask for a repro in two working days |
| Ready | 8 | Acceptance written; not started |
| Building | 4 | Sized to who can review as well as build |
| Review | 4 | Three days here is the team's problem |
| Done | none | Merged or shipped, and the card says which |
Client work is its own type, with a waiting stage that does not count as engineering cycle time. A file or paste becomes a ticket only after review. Seven cards are open at cycle end: four stay, with a reason, and three return to Ready or close. Forecasts use only cards finished in the new system, so the first range is wide. Access requests live on a second board in the same database, outside product WIP.
What you still have to operate
Once a quarter, restore onto a spare machine, open a card, and check an attachment. A nightly copy nobody has opened is not a backup.
Use the same sign-on as git, since shared passwords break when someone leaves. Upgrade on a calendar: take a snapshot, read the changelog, then upgrade. Keep secrets in the password store, not on a card. Name an operator. If the team will not run it, stay hosted and negotiate the data terms instead.
When the board was never the whole job
Slack threads, call notes, and production errors stall before they become cards, and a server of your own does not change that.
Falrow runs on one SQLite database for that gap. Slack, client calls, and Sentry errors can become tickets. Claude Code and Codex plan from the git repo through 135 MCP tools, under team workflow rules, with version-checked writes. Ticket types have custom stages and triage, cycles recur with reviewed rollover, and the roadmap counts tickets. A client CRM turns Granola notes, a file, or a paste into tickets that a person still reviews. Cumulative flow, cycle-time percentiles, and Monte Carlo forecasts (2,000 runs) share that data, and operations has its own boards. Private beta, with access and pricing on request.
That is a delivery loop, and a poor fit for a personal list. Read how the delivery loop runs and how tickets and triage work. If a hosted tool already meets the contract, keep it.
Then run one week of real intake. A new person should be able to see what is in progress, what is blocked, and what "done" means without a tour.
FAQ
Is a self hosted kanban board the same as open source?
No. Self-hosted means you run it and hold the data. Open source is the license to read, run, and modify. Closed source can be self-hosted, and open source can sit on someone else's platform. Decide the two separately.
What should I check before leaving Trello or Jira?
Count the cards worth keeping. Restore a sample and check comments, attachments, and created dates. Map stages to a short set of columns with WIP limits, and name who handles sign-on, backups, and upgrades. If history goes missing, you are starting a new board.
Can client work and internal work share one install?
Yes, as long as they have different types and permissions. Client requests need a waiting stage, and clients must not see each other's notes. Engineering and operations boards in one database keep access requests and invoice chores out of cycle time. Using one column set for every kind of work makes the numbers useless.
Does hosting the board yourself cost less?
The per-seat fee goes away, but hardware, backup storage, upgrade time, and an operator replace it. Columns-only teams often pay less hosted. Teams that already run servers and must keep client data in one place should price the hours first.