beginning
Building the canoe was fun. A clean, minimal Kanban board. Self-hosted. open source. No tracking, no subscriptions, no nonsense.
I shipped v1, posted it on Reddit, got some stars on Github. People really used it. That feeling when someone tells you they’re using something you created? Incredible.
then i learned that Shipping is just the beginning.
documentation challenge
I spent hours writing documentation. Setup guide, configuration examples, troubleshooting section. Tried to make it clear and comprehensive.
But the thing is: People come from different backgrounds. What is obvious to me after construction may not be obvious to someone installing it for the first time.
Someone opens an issue: “How do I install this?”
My first reaction was disappointment. It’s in the readme! But then I realized – maybe the readme assumes too much. Maybe they are new to Docker. Perhaps they are coming from Windows and Linux is foreign.
So I improved the docs:
- More examples added
- Created a troubleshooting guide
- made a video walkthrough
- Added a “General Issues” section
This is a continuous process. Documentation is never “complete”.
support product development
Maintaining Kenio means helping people debug their setup. And honestly? It has taught me more than I expected.
People run canoes on setups I never imagined:
- behind corporate proxy
- on raspberry pi cluster
- In Kubernetes with custom networking
- On NAS devices with limited resources
Every support request reveals an assumption of mine. Every “it doesn’t work” issue (even without description) points to a failure mode I didn’t consider.
The challenge is to balance the time. I want to help everyone. But I also have a day job. And new features to build. And to fix bugs.
I’m still learning how to set boundaries while still being supportive.
Feature requests are polite
People want Keno to do more. And it’s amazing! This means they are actually using it. They care enough to imagine what it could be.
But Every feature request is a decision:
- Does it fit the vision?
- Can I maintain this long term?
- Will this complicate the codebase?
- If I make this, what else won’t be made?
It’s hard to say no. Especially when the request is thoughtful and reasonable. Especially when someone offers help in implementing it.
I’ve learned to be transparent: “I like this idea, but it’s outside the scope of Kenio. The reason is…”
Most people understand. Nothing. He is alright.
migration is scary
The database schema needed a refactor. The current design was limited. The new design will enable the features people wanted.
But more than 200 people were using Kenio in production. Their actual work data. The workflow of their team.
If I break the migration, they will lose trust. Data may be lost. Definitely loses sleep.
So I:
- Wrote migration script
- Tested it on every version going back to v1
- Write detailed upgrade notes
- tested edge cases
- Edge Cases Tested Edge Cases
- Added validation checks
- Dry-run mode added
Released it. Took my breath away.
Most of the migration went smoothly. Some did not. Not because people didn’t read the notes – but because they had setups I couldn’t predict:
- modified database
- custom patch
- an environment I’ve never seen before
We debugged together. He was patient. I was grateful.
Each migration taught me something new about defensive programming.
Contributors are a gift
When someone submits a PR, it’s incredible. Someone cared enough to spend their time improving the canoe.
But integrating contributions is more difficult than I expected:
- different coding styles
- Different views about architecture
- Different ideas about what Keno should be
Sometimes a PR is perfect. Sometimes it needs work. Sometimes it is solving a problem in a way that creates more problems later.
Here’s what I learned:
- always appreciate effort
- Explain your reasoning when requesting changes
- It’s okay to say “It doesn’t fit, but I appreciate you”
- Sometimes if it’s close you can fix it yourself
Contributors who stick around? They are amazing. They’ve made Kenoe much better than I could have made it alone.
environmental diversity
Self-hosting means people run Keno Everywhere:
# docker on their laptops
docker compose up -d
# kubernetes clusters at work
kubectl apply -f kaneo.yaml
# raspberry pi in their home lab
# (with 1GB of RAM and dreams)
# bare metal on old servers
# (that have been running since 2015)
# nas devices with arm processors
# (that i've never even heard of)
Every environment teaches me something. Every “this doesn’t work on my setup” issue reveals an assumption I made about how the system works.
I can’t test every environment. But I can make Kenio more flexible:
- better error messages
- clear log
- more beautiful failures
People playing keno on a weird setup? They are often the most helpful. They understand their environment. They provide detailed logs. They test improvements.
We solve it together.
keeping documentation alive
Documentation never ends. Documentation is required for each facility. Documentation may be required for each bug fix. Each question reveals a gap in the documents.
Here’s what I learned:
- Update docs in same PR when code changes
- Treat “documents are incorrect” issues as high priority
- Appreciate when people submit document corrections
- Accept that documents will never be perfect
The goal is not to have accurate documentation. It is documentation that helps most people most of the time.
And when it doesn’t happen? That is the reaction. That’s how it gets better.
comparison question
“Why not just use Trello/Notion/Linear?”
This is a fair question. Those tools are great. They have teams of engineers, designers, product managers. They are polished. They are fast. They are well off.
Keno is different:
| Them | Keno |
|---|---|
| cloud-hosted | Self-hosted (your data, your server) |
| closed source | Open source (you can read every line) |
| well equipped | Minimal (does one thing well) |
| Membership | free (as in freedom and beer) |
It is not better. Its apart. For some people, that difference matters.
And honestly? Building Kenio taught me much more than just how to use those tools.
emotional reality
Maintaining open source is a rollercoaster:
Someone stars your repo → feels good
Someone opens a detailed bug report with logs and reproduction steps → sounds great
Someone says “Kenio saved our team” → sounds unbelievable
Someone opened an issue titled “This is Trash” → It hurts more than it should.
You spend a weekend implementing a requested feature → Cricket
You fixed a small bug → thanks to three people
You realize you haven’t worked on your own roadmap in months → exhaustion
Someone has presented a thoughtful PR → You’re not alone
The heights are high. The lowest are the lowest. But for the people who use Keno, who contribute, who cares? They make it worth it.
what i learned
1. Scope is everything
Keno does One thing: Kanban board. Not project management. No time tracking. No team chat.
Every feature you add is a feature you keep forever.
Being clear about scope isn’t limiting – it’s liberating. It lets you concentrate. This gives you the flexibility to say no without guilt.
2. Automate everything you can
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
test:
- run: npm test
security:
- run: npm audit
release:
- run: semantic-release
Automation isn’t lazy. It is durable:
- Automated tests catch bugs before users do
- Automatic release means less manual work
- Automated security scans give peace of mind
- Automatic dependency updates keep things up to date
This frees you up to focus on things that matter.
3. Good issue templates help everyone
Github issue templates help people:
- system info
- error log
- Steps to reproduce
It’s not about gatekeeping. It’s about making debugging possible. Most people want to help you, help them. Templates make it easy.
4. Saying no is an act of respect
You can’t create everything. Saying yes to everything means doing nothing well.
Being honest about what you can and can’t do respects everyone’s time. Which includes you too.
5. Users are collaborative
People using Kenio are not the only users. they are:
- beta testers looking for bugs
- Documentation editor finding bugs
- Feature designers sharing ideas
- community builders helping each other
They are not demanding. He is engaged. That’s a gift.
When someone opens an issue, they are investing time into improving Keno. Even if the issue is unclear, the intention is good.
Patience and kindness aren’t just nice-to-haves. They are necessary.
honest truth
Maintaining an open source, self-hosted project is:
- more work than making it
- different fun than making it
- more profitable than you expect
- harder than you expect
- worth it
you learn:
- Technical skills (migration, security, scalability)
- People skills (communication, patience, boundaries)
- Product Skills (Priority, Scope, Vision)
- How to Appreciate Every Contribution
- How to create something people really want
My setup (the original one)
┌─────────────────────────────────────┐
│ kaneo infrastructure │
├─────────────────────────────────────┤
│ github │
│ ├─ code + issues │
│ ├─ actions (ci/cd) │
│ └─ container registry │
│ │
│ hetzner ($7/month) │
│ └─ cloud instance │
│ │
│ cloudflare (free) │
│ └─ dns + ddos protection │
│ │
│ plausible │
│ └─ privacy-friendly analytics │
│ │
│ coffee (priceless) │
│ └─ way too much │
└─────────────────────────────────────┘
what will i tell my past
1. Invest early in documentation – Good documentation reduces support burden and helps people succeed. It has been time well spent.
2. Automate from day one – Test, Release, Security Scan. Automation scales. Not you.
3. Be clear about scope – Explain what your project is and what it is not. It helps everyone.
4. The stay is worth the extra effort – Test thoroughly. Add rollback. Write clear upgrade notes. Your users trust you with their data.
5. It’s okay to slow down – You are not a company. You are a human being. Set expectations. Take a break. Conserve your energy.
6. Celebrate your users – Everyone who uses Keno is amazing. They chose to trust something you created. This is unbelievable.
7. Community is the product – Code matters, but people matter more. Invest in both.
conclusion
Would I do it again?
Absolutely.
Kenio exists because I wanted a simple Kanban board that I controlled. But it became something else: a community of people who value privacy, simplicity, and owning their own devices.
Maintenance is real work. Migration is stressful. Support takes time.
But people are using Kenio to:
- run your own business
- Manage their side projects
- organize their teams
- Learn about self-hosting
They send thank you messages. They submit thoughtful bug reports. They contribute code. They help each other in discussions.
It’s just not good. That’s why I do this.
Kenio is open source and free forever. Check it out: github.com/usekaneo/kaneo
If you are using it, thank you. If you’re contributing, you’re amazing. If you’re thinking about it, the docs are great.
And if you find any bugs? I will fix it. Maybe 11 o’clock at night. But I will fix it.
<a href