coolify
アプリケーションcoollabsio/coolify
オープンソースのセルフホスト型 PaaS プラットフォームで、Vercel と Heroku の代替となります。
概要
Coolify はオープンソースのセルフホスト型プラットフォームで、SSH 接続のみで、自社サーバー上に静的サイト、フルスタックアプリケーション、データベース、360 種類以上のワンクリックサービスをデプロイできます。Git プッシュによる自動デプロイ、プレビュー環境、ロールバック、Webhook、自動 HTTPS 証明書、リバースプロキシをサポートし、ログ閲覧とリソースモニタリングも提供します。ダッシュボード、API、CLI、チーム権限でリソースを管理でき、自らのインフラストラクチャを完全にコントロールできます。
README プレビュー
\n\n\n\n# Coolify\n\n**An open-source platform to deploy applications, databases, and services on your own servers.**\n\nOpen source & free forever, backed by our [philosophy](https://coolify.io/philosophy).\n\n\n\n[Website](https://coolify.io) · [Documentation](https://coolify.io/docs) · [Cloud](https://app.coolify.io) · [Discord](https://coollabs.io/discord) · [Community](https://github.com/coollabsio/coolify/discussions)\n\n\n\n## What is Coolify?\n\nCoolify is an open-source and self-hostable alternative to Heroku, Netlify, and Vercel. It helps you manage servers, applications, and databases on your own hardware. You only need an SSH connection.\n\nYou can use a VPS, a bare-metal server, a Raspberry Pi, or any other server that accepts SSH connections. Coolify gives you the convenience of a cloud platform while you keep control of your infrastructure.\n\nYour configurations stay on your servers. If you stop using Coolify, your running resources continue to work and remain manageable.\n\n## What can Coolify do?\n\n- **Deploy any application:** Build from GitHub, GitLab, Bitbucket, or Gitea with Nixpacks, Railpack, Dockerfile, Docker Compose, or a prebuilt Docker image.\n- **Run databases and services:** Deploy managed databases and more than 360 one-click services with persistent storage and generated credentials.\n- **Automate deployments:** Deploy on every Git push, create pull-request previews, call deployment webhooks, and roll back to retained application images.\n- **Manage networking:** Configure custom domains, automatic HTTPS certificates, reverse proxies, health checks, and container networks.\n- **Operate your infrastructure:** Manage multiple servers, inspect deployment and runtime logs, open container terminals, and monitor resource status.\n- **Protect your workloads:** Configure database and storage backups, scheduled tasks, environment variables, secrets, and notifications.\n- **Integrate with your workflow:** Manage resources through the dashboar
FAQ (5)
トラブル対応Coolifyが「DNS mismatch」を表示し続け、再チェックしてもDNSステータスが更新されないのはなぜですか？
これは Coolify のバグです（非同期 DNS 検証機能で導入され、コミット eb57a691c、v4.3.23 に存在します）：DNS チェックを再実行しても暗黙的に破棄されます。これは checking 状態がデータベースに書き込まれないためで、CheckDomainDnsJob が新しい結果を破棄し、古い失敗ステータスが永遠に残り続けます。回避策：アプリケーションに保存されている DNS ステータスエントリをクリアします。ガードはエントリが既に存在する場合にのみ適用されるため、これにより新しいチェックが実行可能になります：
UPDATE applications SET domain_dns_statuses = NULL WHERE id = <id>;その後、ドメイン行の更新アイコン（または 'Check All DNS'）を再度クリックしてください。チェックが実行され、結果が保存され、バッジが緑色に変わります。同じバグはサービスドメインにも影響します（この欠陥のあるロジックは app/Livewire/Project/Application/Domains.php と app/Livewire/Project/Service/Domains.php の両方に存在します）。テストを含む永続的な修正がプルリクエストで提出されています。修正済みのリリースが利用可能になったら Coolify をアップグレードしてください。
トラブル対応なぜ Coolify v4.5.0 の Docker イメージには、既知のセキュリティアドバイザリが存在する古いバージョンの Nginx が含まれているのでしょうか？また、それを修正するにはどうすればよいでしょうか？
Coolify v4.5.0 は、本番用および開発用の Dockerfile において NGINX_VERSION を 1.31.2-r1 に固定していますが、このバージョンは公開されている Nginx のセキュリティアドバイザリに記載されています。イメージ内にインストールされているバージョンは、次のコマンドを実行することで確認できます。
docker run --rm --entrypoint sh coollabsio/coolify:v4.5.0 -c 'nginx -v; apk --no-network info -a nginx'**修正方法:** Coolify v4.5.1 以降にアップグレードしてください。メンテナーは両方の Dockerfile でピンを 1.31.8-r1 に更新し（コミット 57d75d85d47d2720823b43a700025323774450ad）、再ビルドされたリリースイメージにはパッチ適用済みの Nginx パッケージが含まれています。新しいイメージをプルした後に手動での変更は必要ありません。
注：Coolify チームは、脆弱性のある Nginx の機能がデフォルト設定では一切使用されていないことを確認しており、v4.5.0 は初期状態のままでは悪用できません。ただし、公開されたセキュリティ修正を取り込むため、アップグレードは引き続き推奨されます。
トラブル対応Coolifyの「SSH multiplexing failed, falling back to non-multiplexed connection」と「ssh -O check exceeded the timeout of 60 seconds」のエラーを修正する方法は？
原因（Coolify ≤4.1.2）：SshMultiplexingHelper::masterConnectionExists() は timeout ラッパーなしで ssh -O check を実行するため、ControlMaster（mux）ソケットが固まると、Laravel のデフォルトの60秒プロセスタイムアウトによって強制終了されるまで呼び出しがハングしたままになります。この例外はリカバリロジック（refreshMultiplexedConnection()）が実行される前にスローされるため、固まった mux は破棄されず、そのサーバーへのすべての SSH 操作が無期限に60秒ずつ停止し続けます。
即時の回避策 — Coolify ホスト上で固まった mux マスターを kill し、残った古いソケットを削除します：
docker exec coolify pkill -f 'ControlPath=/var/www/html/storage/app/ssh/mux'
docker exec coolify rm -f /var/www/html/storage/app/ssh/mux/mux_*その後、デプロイを再試行してください。単純な
docker restart coolify では固まったプロセスは kill されますが、ソケットファイルは残るため、rm も実行してください。
問題が再発する場合は、パッチが提供されるまで SSH 多重化を無効にしてください。Coolify の環境（.env / docker-compose）で SSH_MUX_ENABLED=false を設定し、Coolify を再起動します。多重化なしの SSH が使用されるため、接続ごとにわずかに遅くなりますが、60秒間の無駄な待機は発生しなくなります。
恒久的な修正（コードレベル）：チェックコマンドの先頭に timeout を付け（既存の SSH_MUX_HEALTH_CHECK_TIMEOUT（デフォルト5秒。現在は isConnectionHealthy() のみを保護している）を再利用）、ensureMultiplexedConnection() 内で connectionIsReusable() の呼び出しを try/catch の内側に移動し、タイムアウトしたマスターが例外として外に抜けるのではなくリカバリをトリガーするようにします。issue #11130 を追跡し、修正がリリースされたら Coolify をアップグレードしてください。
トラブル対応インスタンスがCloudflareの背後にある場合に、CoolifyのAPI IP allowlistが「You are not allowed to access the API」を返すのはなぜですか？
根本原因：CoolifyのTrustProxiesミドルウェアは$proxies = '*'をハードコードしており、Laravelではこれは直接の接続（組み込みのTraefik/coolify-proxy）のみを信頼します。TraefikはCloudflareのエッジIPをX-Forwarded-Forに追加するため、request()->ip()は実際のクライアントではなくCloudflareのエッジIPに解決されます。そのため、許可リストのエントリ（例：Anthropicの160.79.104.0/21）は決してマッチせず、監査ログにもエッジIPが記録されます。回避策：
1. Cloudflareをバイパスしてオリジンに直接クエリを実行する：curl -s --resolve your-domain.com:443:<origin-ip> https://your-domain.com/api/v1/version -H "Authorization: Bearer <token>"
2. CloudflareでインスタンスのドメインをDNS-only（グレークラウド）に設定し、実際のクライアントIPがCoolifyに届くようにする。
3. Settings → Advancedにある「Allowed IPs for API Access」を一時的にクリアする — これにより/api/v1/*および/mcpへのアクセスは復旧しますが、IP制限が解除されるため、応急処置としてのみ使用してください。
CloudflareのIPレンジをホワイトリストに追加しないでください — それではCloudflare経由のすべてのクライアントを許可することになります。恒久的な修正（Cloudflareが公開しているCIDRを明示的に信頼するためのオプトインのTRUSTED_PROXIES設定）がissueで提案されています。最新のCoolifyリリースにアップグレードし、変更履歴でその搭載の有無を確認してください。
トラブル対応Coolify で Nixpacks から Railpack に切り替えた後、PayloadCMS のビルドが 'getaddrinfo ENOTFOUND' または MongoDB 接続タイムアウトで失敗するのはなぜですか?
根本原因: Coolify の Railpack ビルドは docker-container ドライバーを指定した docker buildx 経由で実行されるため、ビルドは分離された BuildKit ビルダーコンテナ内で実行されます。そのビルダーは Coolify の内部 Docker ネットワーク (10.0.1.x) に接続されておらず、--network host は Docker ホストではなくビルダーコンテナのネームスペースにのみ適用されます。そのため、--add-host のエントリーは MongoDB コンテナに到達できず、MongooseServerSelectionError: getaddrinfo ENOTFOUND <hostname> が発生するか、コンテナ IP (例: 10.0.1.6) を直接使用した場合は 30 秒の接続タイムアウトが発生します。
回避策:
1. 簡単な修正: Coolify のサービス設定で、Build Pack を Nixpacks に戻します。従来の docker build は実際のホストネットワーキングで実行されるため、ビルド時に Coolify の内部ネットワークやデータベースコンテナに到達できます。
2. 推奨される修正: ビルド時のデータベース依存を完全に取り除きます。PayloadCMS/Next.js は実行時にのみ MongoDB を必要とするはずです。Payload にクエリを実行するページやレイアウトに export const dynamic = 'force-dynamic' を追加する (または DB 呼び出しを遅延させる) ことで、next build が静的生成中に MongoDB へ接続しなくなります。これにより、データベースへのアクセスなしで Railpack によるビルドが成功します。