Coolify的GitHub上有個issue掛了22個月，46個人點了贊，還有人懸賞250美元。問題是：什么時候支持Kubernetes？維護者的回答很干脆——我們要做自己的方案。但等等，他們從沒說過K8s技術上不可行。

一位8年經(jīng)驗的DevOps工程師決定親自驗證。不是問"你們要不要我的代碼"，而是問"這事到底能不能成"。

一場持續(xù)22個月的拉鋸戰(zhàn)

時間回到2024年6月，Coolify的GitHub倉庫里誕生了issue #2390。標題很直接：請求原生Kubernetes支持。

開源社區(qū)的反應說明了一切。46個reaction，這是社區(qū)用鼠標投票的結果。有人甚至掏出真金白銀——250美元的bounty（賞金），掛在平臺上等人認領。

但issue的狀態(tài)始終是open。沒有關閉，沒有解決，就這么懸著。

2026年3月14日，一位叫writer-tech-9的開發(fā)者終于忍不住了。他在issue下留言，亮出底牌：8年DevOps經(jīng)驗，Kubernetes深度 specialization（專業(yè)化）。然后拋出問題：我能幫忙嗎？

Discord上的對話更直接。他找到核心維護者Peak，把話挑明。

Peak的回復成了關鍵轉折點：

「我們將在v5版本使用自己的定制方案，直接與Docker Compose集成，后臺使用Docker。它更靈活，與Coolify結合更緊密，類似Swarm但更好。」

翻譯一下：Kubernetes支持不在v5的計劃里。不是"暫時不做"，是明確選擇了另一條路。

writer-tech-9把這段話讀了好幾遍。然后發(fā)現(xiàn)了一個被忽略的細節(jié)。

產(chǎn)品決策 vs 技術邊界

Peak說的是"我們的方案更靈活、集成更緊密"。

他沒說的是"Kubernetes技術上無法實現(xiàn)"。

這是兩個完全不同的命題。前者是產(chǎn)品路線選擇，后者是工程可行性判定。但22個月來，所有人似乎都默認了后者——既然官方不做，那一定是做不了。

writer-tech-9的疑問由此而生：社區(qū)想要K8s支持，維護者選了另一條路，但從來沒人驗證過第一條路到底能不能走通。

這個gap（缺口）里藏著太多未解之謎。K8s的生態(tài)系統(tǒng)成熟度、企業(yè)級部署的剛需、多云策略的靈活性——這些需求真實存在，卻被一句"我們要做自己的方案"輕輕帶過。

更微妙的是Coolify的定位。它把自己定義為"Heroku/Netlify/Vercel的開源替代品"，主打自托管、無廠商鎖定、成本可控。這個定位天然吸引兩類人：想省錢的小團隊，和想掌控基礎設施的技術人。

第二類人往往已經(jīng)在用K8s。他們想要Coolify的簡潔，又不想放棄現(xiàn)有的集群投資。issue #2390的46個贊，大概率來自這個群體。

維護者的選擇也有道理。Docker Compose的學習曲線更平緩，與Coolify的代碼庫耦合更緊，v5的架構可以圍繞它深度優(yōu)化。這是一條更可控的路。

但"更可控"不等于"唯一可行"。

一個工程師的驗證計劃

writer-tech-9沒有接受現(xiàn)狀。他宣布啟動一項獨立調(diào)查，目標只有一個：用技術證據(jù)回答"Coolify能否原生支持K8s"。

他的方法論很清晰。三種可能結局，每種都有價值：

第一，跑通K8s集成，證明架構可以容納。維護者可以選擇合并或拒絕，但社區(qū)終于有了一個working solution（可用方案），無論是主線還是fork。

第二，發(fā)現(xiàn)真正的技術blocker（阻塞點），詳細記錄。社區(qū)從"懸而未決"變成"確知不可為"，issue可以堂堂正正關閉。

第三，技術上可行但代價高昂。把trade-off（權衡）攤開來講，讓社區(qū)和維護者基于信息做決策，而非基于假設。

這三種結局都比現(xiàn)狀好。22個月的open issue，本質(zhì)是信息真空。有人在等，有人在猜，沒人去驗證。

他的背景給了這個計劃可信度。8年不是隨便說的數(shù)字——設計集群、把K8s客戶端集成進應用、調(diào)試生產(chǎn)故障，這些經(jīng)歷意味著他知道坑在哪里，也知道怎么繞過去。

風險他也清楚列出來了。時間投入可能打水漂，維護者可能始終不接納，社區(qū)期待可能被抬高然后落空。但最后一句話很關鍵：

「這個問題值得一個答案。」

250美元賞金和46個贊是信號，不是噪音。開源社區(qū)里，持續(xù)的關注本身就是一種需求表達。有人愿意站出來驗證，比永遠在issue里+1更有建設性。

為什么這事值得技術人關注

Coolify的K8s之爭，縮影了開源世界里一個反復出現(xiàn)的張力：維護者的產(chǎn)品判斷，與社區(qū)的功能需求，怎么平衡？

維護者不是客服。他們有權決定項目往哪走，有權說"不"。但"不"有兩種給法：一種是"我們不做這個"，一種是"這個技術上不可行"。前者是選擇，后者是斷言。當社區(qū)把選擇聽成斷言，信息就扭曲了。

writer-tech-9的介入，是在還原信息的本來面目。他不挑戰(zhàn)維護者的決策權，只挑戰(zhàn)決策的信息基礎。如果K8s確實做不了，文檔化blocker是對社區(qū)的尊重；如果能做，社區(qū)多了一個選項。

更深一層，這事關乎開源項目的治理透明度。當核心團隊說"我們要做自己的方案"，他們有沒有義務解釋為什么K8s被排除？技術上不排除，只是產(chǎn)品上不優(yōu)先——這個區(qū)分，維護者沒說，社區(qū)沒問，就這么模糊地過了22個月。

不是每個開源項目都需要民主決策。但信息對稱是健康社區(qū)的基礎。writer-tech-9的調(diào)查，無論結果如何，都在填補這個信息gap。

對25-40歲的技術從業(yè)者來說，這個案例還有一層實用價值：K8s和Docker Compose的選型困境，正在無數(shù)團隊里上演。

Compose簡單，但鎖定在單節(jié)點或Swarm模式。K8s復雜，但生態(tài)系統(tǒng)龐大、多云遷移靈活。Coolify的選擇是Compose路線，但社區(qū)里有大量K8s存量投資。這個張力不是Coolify獨有的。

writer-tech-9的驗證過程——如果公開分享——可能成為一份鮮活的架構決策參考。他怎么評估集成點，怎么處理狀態(tài)管理，怎么權衡控制平面與數(shù)據(jù)平面的分離，這些細節(jié)比任何文檔都真實。

開源協(xié)作的另一種可能

最有趣的部分可能是writer-tech-9的姿態(tài)。他不是帶著PR來求合并的，而是帶著問題來求答案的。

這種"調(diào)查優(yōu)先"的做法，在開源貢獻里并不常見。更多人選擇直接開干：fork、修改、提PR，然后等維護者反應。writer-tech-9反過來了：先聲明意圖，再公開過程，最后才談代碼。

這降低了對抗性。維護者不用擔心突然冒出一個巨型PR要 review，社區(qū)可以圍觀學習，writer-tech-9自己也能在過程中調(diào)整方向。Building in public（公開構建）的價值就在這里——過程本身成為產(chǎn)出。

Peak的回應也值得關注。他會不會參與討論？會不會開放某些內(nèi)部架構文檔？維護者與社區(qū)調(diào)查者的互動模式，往往比技術結論更能說明項目的健康度。

最壞的情況是沉默。writer-tech-9調(diào)查他的，維護者做他們的，兩條平行線。但即便這樣，社區(qū)仍能從調(diào)查產(chǎn)出中受益——一份關于Coolify架構邊界的技術文檔，目前還不存在。

更好的情況是協(xié)作。維護者可能不愿意主倉支持K8s，但愿意指點集成點；或者看到可行性后，重新評估產(chǎn)品路線。開源的妙處就在于，信息流動可以改變初始立場。

22個月的open issue，250美元懸賞，一位8年經(jīng)驗的工程師決定親手驗證。這個故事的戲劇性不在于沖突，而在于一個簡單的問題被忽視了太久：當我們說"不做"，我們是在說"不想"還是"不能"？

writer-tech-9的調(diào)查才剛剛開始。三種結局都在等待：技術可行、技術不可行、可行但有代價。無論哪一種，都比懸而未決強。

對于在K8s和Compose之間做選型的團隊，對于關心開源治理模式的開發(fā)者，對于單純好奇"這事到底能不能成"的技術人——這個案例值得跟蹤。不是因為它一定有驚天動地的結論，而是因為它示范了一種處理分歧的方式：不是爭論誰對誰錯，而是用工程方法求一個確定的答案。

Peak說v5會用"類似Swarm但更好"的方案。writer-tech-9要去驗證K8s的可能性。兩條路線，一個目標：讓部署基礎設施這件事，對開發(fā)者更友好。

如果K8s集成最終被證明可行，Coolify會因此分裂成兩個陣營，還是維護者會重新考慮產(chǎn)品路線？如果不可行，那些已經(jīng)用K8s的團隊，會放棄Coolify還是接受混合架構的復雜性？