Coolify

SSHで接続できる自分のserverを、application/database/serviceの配備先としてまとめて管理する

READMEではCoolifyをHeroku・Netlify・Vercel等のself-hostable alternativeと位置付け、VPS、bare metal、Raspberry PiなどSSH接続可能なserverを管理対象にできます。

repository metadataはstatic site、database、full-stack application、280+ one-click serviceの配備を掲げています。設定と実行resourceは自分のserver側に残るため、Coolifyを停止してもresourceそのものが即消える設計ではありません。

出典：[2][1]

Dockerを土台に、Laravel・Node.js・Next.js・Svelte・PostgreSQLなど幅広いstackを扱う

GitHub Topicsにはdocker、docker-compose、laravel、nodejs、nextjs、postgres、redis、svelteなどが登録され、repositoryの主要言語はPHPです。

OSS探訪のBuilt withではGitHub metadataからPHP、Docker、Laravel、Next.js、Node.js、PostgreSQL、Svelteを表示できます。Coolify自身の実装stackと、Coolifyが配備できるapplication stackは分けて理解するのが適切です。

出典：[1]

1行installerでself-hostでき、managed Cloudも同じprojectから提供される

READMEのinstallationは curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash を案内しています。Cloud版も提供され、self-host運用を避けたい場合はCoolify serverの保守をmanaged serviceへ寄せられます。

READMEはCoolify用serverと配備resource用serverを分ける構成を推奨し、Cloud版では高可用性、通知、support、maintenance負荷低減を利点として挙げています。

出典：[2]

VPSを持っているが、毎回Docker Compose・reverse proxy・deploy automationを手作業したくないteamに

小〜中規模のWeb serviceや個人開発で、自分のVPSを使い続けながらGit pushからのdeploy、database、service管理を一つのUIへ寄せたいケースに向きます。PaaSの操作性とinfrastructure ownershipの両方を残したい場合に比較しやすい選択肢です。

self-hostを選ぶと、Coolify本体だけでなくhost OS・network・backupの運用責任も自分に残る

Coolifyはdeploymentを自動化しますが、基盤serverのpatch、SSH hardening、firewall、storage容量、backup、障害時復旧までmanaged cloudのように自動で引き受けるわけではありません。

databaseやvolumeを載せる場合は、Coolifyのbackup機能の有無だけでなくrestore test、off-site copy、server failure時の復旧手順まで別途設計する必要があります。

出典：[2]

remote install scriptは便利だが、production導入ではversionと実行内容を確認する

公式Quick Startはcurlしたscriptをroot権限を含むserver setupへ使うため、productionではinstaller source、対象version、必要port、既存reverse proxyやDocker環境との競合を確認してから実行するのが安全です。

v4.3.21ではrestart limitやTraefik supportなど運用に関わる変更も含まれているため、継続運用ではrelease noteを確認してupdateします。

出典：[2][3]