Coolify、Vercelの外側で自分のサーバーを使う開発者向けPaaSの設計

Vercelの外側にある問い

self-hosted PaaSのCoolifyは、クラウドの便利さを捨てずに、実行環境を自分のサーバーへ戻す選択肢として設計された。出典

冒頭から重要なのは、Coolifyの創業者 Sébastien Chopin が「自分のサーバーで動かせるdeployment platform」という方向性を示していることだ。出典

創業のきっかけ

CoolifyはDocker、Git、VPSという既存の道具を、ひとつの管理体験へまとめる。

利用者は新しい専用インフラを学ぶのではなく、自分が選んだサーバーにアプリを配置する。出典

転機・苦労

ただし、self-hostingは自由の代わりに責任を要求する。

インストール、SSH、DNS、TLS、バックアップなど、managed PaaSが隠していた仕事が残る。出典

Coolifyの挑戦は、機能を増やすこと以上に、この複雑さをUIとドキュメントで包むことだった。

成長・成功

GitHubでコードを公開し、documentationとdiscussionを入口にしたことで、導入前に仕組みを検証できる。

OSSの透明性とCloudの選択肢を並べる構成は、ロックインを嫌う開発者にとって合理的だ。出典

結び

Coolifyの示唆は、PaaSを「どこかのクラウドを借りること」から「自分の計算資源を使いやすくすること」へ再定義した点にある。

便利さとcontrolは二者択一ではなく、どの責任を誰が持つかを設計できる。

Coolifyは、VercelやHerokuの手軽さを求めつつ、クラウドベンダーへのロックイン、データ所在地、従量課金を避けたい開発者に刺さる。

Docker ComposeやGit連携を自分のVPSへ寄せ、deployの認知負荷を下げる。出典

self-hostingは自由度と運用責任を同時に引き受ける選択だ。

Coolifyはその境界をUIと自動化で埋めるポジションにある。出典

強みは独自の基盤技術より、Docker・サーバー・Gitをつなぐworkflowと、そこで蓄積される運用知識にある。

OSSとしてコードと導入手順が公開されるため、採用前の検証障壁も低い。出典

ネットワーク効果は弱い。

利用者が増えるほど直接的なデータネットワークが強くなる製品ではない。

一方、OSSのissue、discussion、導入事例が改善速度を押し上げるコミュニティ効果は期待できる。出典

主対象は、個人開発者、小規模チーム、agency、そしてクラウド費用やデータ管理を自分で制御したい開発者だ。

大規模組織で完全managedなSRE体制を求める場合は、導入前に責任分界を確認したい。

第一に、Docker・Git・既存サーバーという開発者の既知の部品を使うこと。

第二に、OSSとCloudの入口を分け、試すコストを下げたこと。出典

結果として、抽象的な「新しいPaaS」ではなく、既に持っているVPSをdeploy platformへ変える具体性がある。出典

self-hostedである以上、OS更新、バックアップ、ネットワーク、秘密情報の管理は利用者に残る。

公式ドキュメントが手順を提供しても、managed PaaSと同じ運用負担にはならない。出典

また、公式に開示されたARRや顧客数は確認できず、成長規模は要確認。

OSSの採用と事業の成長を同一視しない必要がある。

獲得の中心はOSS、GitHub、ドキュメント、既存のVPSユーザーからの口コミだと考えられる。

無料でself-hostできることが導入の摩擦を下げ、必要な利用者にはCloudを提示できる。出典

この戦略のトレードオフは、OSS利用がそのまま有料転換になるとは限らないこと。

Cloudの差分価値を、運用代行・チーム機能・信頼性で明確にする必要がある。

主要チャネル: github, documentation, community, content

「managedでなければ簡単にできない」という前提を疑い、既存のDockerとVPSを組み合わせれば、別のPaaS体験を作れる。重要なのは機能の多さより、deployまでの手順を一つのmental modelにまとめることだ。

日本では、データ所在地やクラウド費用を気にする中小企業、受託開発会社、社内サーバーを持つ組織に余地がある。

一方、保守担当者が限られるため、日本語ドキュメント、バックアップ、障害時の責任範囲が普及の条件になる。