Coolify v4.5アップデート：DockerデプロイとセルフホストPaaSの変化

クラウドサービスのコスト負担を軽減し、単一サーバー上でコンテナベースのサービスを直接制御したい開発者の間で、Coolifyは代表的なオープンソースPaaS（Platform as a Service）としての地位を確立しました。最近公開されたCoolify v4.5リリースは、Dockerデプロイパイプラインの安定性を向上させ、コンテナ管理やセルフホスト開発環境を補完するいくつかの実質的な変更を含んでいます。

今回のアップデートで最も注目すべきポリシー変更は、Docker Composeのレプリカ設定に対する制限です。また、独立したリポジトリ環境を好む開発者のためにGiteaの公式連携が追加され、コンテナビルドシステムやAPIトークンのセキュリティ体制もより厳格化されました。

Docker Composeの多重レプリカ禁止とコンテナロールバック

Coolify v4.5からは、Docker Composeファイル内の「scale」や「replicas」設定が1を超える場合、デプロイが拒否されます。これは単一ホストのインフラにおいてプロキシルーティングやポート競合の問題を引き起こしていたマルチコンテナ構成を根本から排除し、単一コンテナインスタンス中心の安定性を確保するための措置です。

これに合わせ、レジストリに保存された直近のデプロイ用Dockerイメージへ即座に戻せるロールバック機能が正式に導入されました。デプロイ直後にランタイムエラーが発生した場合、以前のビルドを再実行することなく、直前のイメージタグを参照して迅速にサービスを復旧できます。コンテナターミナルには対話型コンソールモードである「docker attach」機能が追加され、実行中のコンテナ内部の状態をリアルタイムで確認しやすくなりました。

Gitea連携とビルドパックのデフォルト切り替え

プライベートリポジトリのサポート範囲も拡大されました。従来のGitHubやGitLab中心のWebフック連携に加え、公式のGiteaアプリソースを登録することで、個人サーバーにインストールされたGiteaリポジトリからもソースコードを自動取得してデプロイできます。クラウド外部の閉域網や、完全に独立した自社サーバーインフラを構築したいチームにとって有益な変更です。

コンテナイメージビルドツールのエコシステムにも変化が適用されました。長年使用されてきたNixpacksビルドパックはサポート終了のプロセスに入り、公式の推奨ツールとしてRailpackが指定されました。プロジェクトを初登録する際にDockerfileと環境変数を自動スキャンして解析するスマートスキャン機能も追加され、プロジェクト作成プロセスが簡素化されました。

厳格化されたAPI権限とサーバーセキュリティ

自動化スクリプトやCIパイプラインからCoolifyを制御する際に使用するAPIトークンの権限体系が細分化されました。以前はデフォルトのトークンでも広範囲な制御が可能でしたが、今後はデプロイ権限が明示的に付与されたトークンのみが、スケジュールされたタスクの実行、プロキシ変更、リソース削除といったサーバーに影響を及ぼす操作を行えます。バックアップ実行メッセージや機密情報も、基本照会権限だけでは確認できないよう分離されました。

サーバー運用面では、OSのセキュリティパッチを自動適用し、危険なパッケージや再起動の必要性をサーバー一覧で警告してくれるサーバーパッチ機能がベータ版として搭載されました。Coolify自体のアップデートを実行する前に内部データベースを自動バックアップするロジックも基本適用され、アップデート失敗によるデータ損失のリスクが低減されました。

どのような環境に適しており、いつ避けるべきか

Coolify v4.5は、個人のVPSや単一の物理サーバー上でWebアプリケーション、データベース、バックアップを簡単に統合管理したいフルスタック開発者に適しています。Dockerfileの作成に慣れていなくても、Railpackベースの自動ビルド、SSL証明書の自動発行、直感的なコンテナロールバックのメリットをすぐに享受できます。

複数のサーバーにまたがってコンテナを分散配置する必要がある場合や、Docker SwarmやKubernetesレベルの精緻なオーケストレーションが必要な大規模プロダクション環境には向いていない可能性があります。Docker Composeファイルにscale設定を適用して負荷分散を行っていた既存プロジェクトを移行する際、デプロイ拒否エラーが発生する可能性があるため、事前にCompose構造を点検する必要があります。