22 months open. $250 bounty. 46 reactions. One unexpected answer.
The Reach-Out
On March 14, 2026, I did something that felt important.
I commented on Coolify issue #2390 — the Kubernetes support request that has been sitting open since June 2024. I offered to help. I shared my background (8 years DevOps, deep K8s specialization). I asked if they were open to collaboration.
Then I took it to Discord and asked the team directly: "What do you think about this?"
The response came from Peak, a core maintainer:
"We will use our own custom solution (for v5) that integrates directly with Docker Compose and uses Docker in the background, as it is more flexible and tightly integrated into Coolify, like Swarm but better."
Kubernetes support, it seemed, was not coming to Coolify. Not in v5. Maybe not ever.
The Gap in the Answer
I read that response multiple times. Something struck me.
They never said Kubernetes was technically impossible.
They said their solution was:
- "More flexible"
- "Tightly integrated"
- "Like Swarm but better"
These are comparative advantages, not absolute constraints.
The maintainers made a product decision: "We will build X instead of Y."
They did not make a technical claim: "Y cannot be built."
The Unanswered Question
This distinction matters because of what sits behind issue #2390:
- 46 community reactions (36 hearts, 10 eyes watching)
- $250 in community bounties
- 22 months of sustained interest
- Comments from users explaining why this is the blocker preventing them from adopting Coolify
The community clearly wants native Kubernetes support.
The maintainers have chosen a different path.
And no one has investigated whether the community's request is actually possible to fulfill.
The Investigation
So I'm asking a different question than "Will you accept my PR?"
Is native Kubernetes support in Coolify actually impossible?
With 8 years of Kubernetes experience — designing clusters, integrating K8s clients into applications, debugging production deployments — I'm in a position to find out.
Here's what I'm going to do:
Phase 1: Architecture Mapping
- Clone Coolify and understand its current deployment model
- Identify where K8s integration would logically live
- Document the current "Docker-only" architecture
Phase 2: Integration Point Analysis
- Map the API boundaries where K8s could interface
- Identify potential blockers (technical, architectural, philosophical)
- Research how other PaaS platforms handle dual Docker/K8s support
Phase 3: Proof-of-Concept
- Build a minimal K8s integration for one deployment type
- Document what works, what breaks, what's hard
- Share working code or detailed failure analysis
Phase 4: Community Decision
- Publish findings: "Here's what I found when I tried"
- If it's possible: offer the solution to maintainers and community
- If it's impossible: document exactly why (valuable for future reference)
Three Possible Outcomes
I'm not approaching this with a predetermined conclusion. There are three ways this investigation ends:
Outcome 1: It's Possible
I build working K8s support that proves the architecture can accommodate it. The maintainers can choose to merge it or not — but the community will have a working solution (either in mainline or as a maintained fork).
Outcome 2: It's Impossible
I discover genuine technical blockers that make K8s integration infeasible. I document these blockers in detail. The community finally has a definitive answer instead of an open question.
Outcome 3: It's Complicated
The integration is technically possible but comes with significant trade-offs. I map these trade-offs clearly so the community and maintainers can make an informed decision.
Any of these outcomes serves the community better than the current state: an open issue with demand but no investigation.
Why I'm Doing This
Let's be honest about the risks:
- The maintainers might see this as undermining their vision
- I could invest significant time and prove it's actually impossible
- The community might not care about the findings
- I could end up maintaining a fork that no one uses
But here's what I know:
The question deserves an answer. 46 reactions and $250 in bounties suggest real demand. Someone should investigate if that demand can be met.
The investigation has value regardless of outcome. Even a documented failure teaches us something about Coolify's architecture.
Building in public creates connections. The process of investigation — sharing blockers, breakthroughs, architecture insights — is valuable content for the DevOps community.
The maintainer decision isn't the end of the story. Open source means the community can explore paths the core team chooses not to. That's not hostile — it's how open source evolves.
The Bigger Picture
This isn't just about Coolify and Kubernetes.
It's about what happens when:
- A community clearly wants a feature
- The maintainers choose a different direction
- No one investigates if the community's request is technically feasible
Someone has to ask: "Is this actually impossible? Or just not prioritized?"
I'm asking that question. And I'm documenting the answer.
Follow Along
I'll be sharing every step of this investigation:
- Architecture deep-dives
- Integration point analysis
- Blockers and breakthroughs
- Working code or documented failures
- Honest assessments of what's possible
If you're interested in:
- Kubernetes architecture
- How PaaS platforms handle deployment abstraction
- The gap between maintainer vision and community demand
- What "impossible" actually looks like in practice
Connect with me: Follow me here on Dev.to for updates. You can also find me on Twitter/X, Linkedin and Telegram
GitHub Issue: https://github.com/coollabsio/coolify/issues/2390
Questions? Drop them in the comments below.
