项目简介
Coolify 是开源自托管平台，可在自有服务器上部署静态站点、全栈应用、数据库及 360 多种一键服务，仅需 SSH 连接。支持 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
常见问题 (5)
故障排除为什么 Coolify 一直显示 'DNS mismatch'，并且在重新检查后始终不更新 DNS 状态？
这是 Coolify 中的一个 bug（随异步 DNS 验证功能引入，提交 eb57a691c，存在于 v4.3.23 版本中）：重新运行 DNS 检查会被静默丢弃，因为 checking 状态从未写入数据库，导致 CheckDomainDnsJob 丢弃新结果，而旧的失败状态会一直保留。
临时解决方法：清除该应用程序已存储的 DNS 状态条目，即可解除新检查的阻塞，因为守卫逻辑仅在条目已存在时才会生效：
UPDATE applications SET domain_dns_statuses = NULL WHERE id = <id>;然后再次点击域名行上的刷新图标（或 "Check All DNS"）——检查将会运行，结果会被保存，徽章将变为绿色。同样的 bug 也影响服务域名（错误的逻辑同时存在于 app/Livewire/Project/Application/Domains.php 和 app/Livewire/Project/Service/Domains.php 中）。带有测试的永久修复正通过 pull request 提交——一旦发布修复版本，请升级 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() 在运行 ssh -O check 时没有使用 timeout 包裹，因此当 ControlMaster (mux) socket 卡死时，该调用会一直挂起，直到 Laravel 默认的 60 秒进程超时将其杀死。异常在任何恢复逻辑（refreshMultiplexedConnection()）运行之前就被抛出，所以卡死的 mux 永远不会被拆除，对该服务器的每一次 SSH 操作都会无限期地停滞 60 秒。
临时解决方法——在 Coolify 主机上杀死卡死的 mux master 进程并删除其残留的 socket 文件：
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 会杀死卡死的进程，但会留下 socket 文件，所以也要执行 rm。
如果问题再次出现，请在补丁发布前禁用 SSH 多路复用：在 Coolify 的环境配置（.env / docker-compose）中设置 SSH_MUX_ENABLED=false 并重启 Coolify。这样将使用非多路复用的 SSH——每次连接会略微变慢，但不会再出现 60 秒的死等。
永久修复（代码层面）：在检查命令前加上 timeout（复用现有的 SSH_MUX_HEALTH_CHECK_TIMEOUT，默认 5 秒，目前仅用于保护 isConnectionHealthy()），并将 connectionIsReusable() 调用移入 ensureMultiplexedConnection() 中的 try/catch 内部，这样超时的 master 会触发恢复逻辑而不是逃逸出去。请关注 issue #11130，并在修复发布后升级 Coolify。
故障排除为什么当实例位于 Cloudflare 之后时,Coolify 的 API IP 白名单会返回 "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，而非真实客户端 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（DNS-only，灰色云朵），使真实客户端 IP 能够到达 Coolify。
3. 临时清空 Settings → Advanced 下的 "Allowed IPs for API Access"——这会恢复 /api/v1/* 和 /mcp 的访问，但同时会移除 IP 限制，因此只能作为临时应急手段。
切勿将 Cloudflare 的 IP 段加入白名单——那会允许任何经由 Cloudflare 代理的客户端。该 issue 中已提出一个永久修复方案（新增一个可选启用的 TRUSTED_PROXIES 设置，用于显式信任 Cloudflare 公布的 CIDR）；请升级到最新的 Coolify 版本，并查看更新日志确认该修复是否已被纳入。
故障排除为什么在 Coolify 中从 Nixpacks 切换到 Railpack 后，PayloadCMS 构建会失败，并出现 'getaddrinfo ENOTFOUND' 错误或 MongoDB 连接超时？
根本原因：Coolify 的 Railpack 构建通过 docker buildx 并使用 docker-container 驱动程序运行，因此构建会在一个隔离的 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'（或以其他方式推迟数据库调用），这样 next build 在静态生成期间就不会再连接 MongoDB。随后构建即可在 Railpack 下成功完成，无需任何数据库访问。