Coolify：在自有服务器部署应用、数据库与360+服务
一个把Vercel式部署带到自有服务器的PaaS，应用、数据库和360+服务都能集中管理。
GitHub coollabsio/coolify 更新 2026-10-26 分支 main 星标 64.4K 分叉 5.8K
PHP 自托管PaaS Docker Compose VPS与裸金属服务器

🧭 决策指南

为什么现在热： 材料显示Coolify在2026-10-26日新增152颗星、总星数64,387，并发布到v4.5.0；README同时突出自有服务器部署、360+一键服务、Git push自动部署和API/CLI/MCP。材料无法证明单一原因，但这些新版本与高覆盖功能可能解释了当日关注度。

适合，如果你

  • 你希望在VPS、裸金属服务器或Raspberry Pi上运行自托管PaaS。
    README“ What is Coolify?”写明支持VPS、bare-metal server、Raspberry Pi及可接受SSH连接的服务器。
  • 你的团队需要从GitHub、GitLab或Gitea部署，并使用Docker Compose或Dockerfile。
    README“ What can Coolify do?”的“Deploy any application”列出GitHub、GitLab、Gitea、Docker Compose和Dockerfile。
  • 你要同时部署数据库和360+一键服务，并保留持久化存储。
    README“Run databases and services”写明支持managed databases、360+ one-click services和persistent storage。
  • 你需要Git push自动部署、pull-request previews或保留镜像回滚。
    README“Automate deployments”列出Git push、pull-request previews、deployment webhooks和retained application images。

不适合，如果你

  • 你不想维护Coolify服务器，只想使用托管控制平面。
    README“Self-hosted or Cloud”写明自托管需要控制和维护完整平台，并建议不想维护时使用Coolify Cloud。
  • 你的部署环境无法提供SSH连接。
    README“ What is Coolify?”写明使用Coolify只需要一个SSH connection，并要求服务器接受SSH连接。
  • 你要求完全不付费的托管服务，而不是自建开源平台。
    README“Self-hosted or Cloud”区分了免费开源的Self-hosted和付费的Coolify Cloud。

前置条件

  • 需要一个接受SSH连接的服务器；README列举VPS、bare-metal server和Raspberry Pi。
  • 需要在supported server上安装Coolify，具体requirements由installation guide提供。
  • 自托管推荐使用一台服务器运行Coolify，另使用一台或多台服务器运行deployed resources。
  • 安装前可检查README中的installation script：./scripts/install.sh。

第一步命令（README 原文）

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

要注意

  • 默认安装命令会执行远程cdn.coollabs.io脚本。
    README“Quick start”直接给出curl ... install.sh | bash，并提示运行前可查看./scripts/install.sh。
  • 自托管架构至少涉及Coolify服务器和资源服务器。
    README“Self-hosted or Cloud”推荐一台服务器运行Coolify，另一台或多台运行deployed resources。
  • Coolify停止使用后资源仍运行，但仍可管理。
    README“ What is Coolify?”说明停止使用Coolify后，running resources continue to work and remain manageable。

替代方案

  • Coolify Cloud：不想维护Coolify服务器，且接受使用付费托管实例时更合适。
    README“Self-hosted or Cloud”
  • Vercel：需要Vercel托管平台而不是在自有服务器上维护Coolify时更合适。
    README“ What is Coolify?”
  • Heroku：需要Heroku托管平台而不是自行管理服务器、应用和数据库时更合适。
    README“ What is Coolify?”
  • Netlify：需要Netlify托管平台而不是在自有硬件上部署时更合适。
    README“ What is Coolify?”

材料未说明

  • README未说明支持的操作系统、CPU、内存和磁盘最低要求。
  • README未说明360+一键服务的完整清单、版本和维护责任。
  • README未说明自动HTTPS证书使用的证书发行机构及续期失败处理。
  • README未说明数据库备份的存储位置、保留策略和恢复流程。
  • README未说明v4.5.0的具体变更内容及与现有部署的兼容性。
  • README未说明API、CLI和MCP的权限边界、认证方式及稳定性。
  • README未说明Coolify Cloud当前价格，只有价格链接。

💡 深度解析

6
视情况 我不想把配置和数据锁定在 Heroku、Netlify 或 Vercel，但团队没有专职 SRE；我能接受维护 SSH、Docker、域名、TLS 和备份，Coolify 是否比托管 PaaS 更合适？
适合读者： 关注数据自主权、但没有专职 SRE 的独立软件开发者，正在比较自托管 Coolify 与 Heroku、Netlify、Vercel

视情况：如果数据控制和可迁移性优先，Coolify 更合适；如果团队无法持续维护服务器和平台，托管 PaaS 更合适。

  • README 将 Coolify 定义为 Heroku、Netlify 和 Vercel 的开源、自托管替代方案，配置留在用户服务器上，停止使用平台后运行资源仍可继续工作。
  • 自托管版本免费且开源，用户可以控制完整平台；这满足对基础设施自主权和迁移能力的要求。
  • 代价是你必须维护 Coolify 所在服务器、资源服务器以及 SSH、Docker、域名、HTTPS、存储和备份相关条件。README 的对比表明确写出自托管需要用户“Control and maintain the complete platform”。
  • README 同时提供 Coolify Cloud，并将其定位为由项目方维护、具备高可用且维护更少的付费服务。

因此，若团队确实能承担底层运维，选择自托管；若没有持续的服务器维护能力，Cloud 或其他托管 PaaS 更符合约束。README 没有给出两种方案的完整 SLA、价格和迁移工具细节。

  • What is Coolify?: “Coolify is an open-source and self-hostable alternative to Heroku, Netlify, and Vercel.”
  • What is Coolify?: “Your configurations stay on your servers. If you stop using Coolify, your running resources continue to work and remain manageable.”
  • Self-hosted or Cloud：自托管为 “Free and open source” 以及 “Control and maintain the complete platform.”
  • Self-hosted or Cloud：Coolify Cloud 为 “Get high availability and less maintenance.”
材料未说明：README 没有给出 Coolify Cloud 当前价格、具体 SLA 或高可用架构说明。；README 没有说明从 Heroku、Netlify 或 Vercel 迁移应用和数据的自动化工具。；README 没有明确自托管平台升级、故障恢复和安全响应的责任边界。
适合 我只有一台接受 SSH 连接的 Raspberry Pi 或 VPS，想部署 Next.js、静态站点和数据库，同时保留服务器与数据控制权，Coolify 是否适合替代 Vercel？
适合读者： 在 Raspberry Pi 或 VPS 上维护个人项目、希望替代 Vercel 部署 Next.js 或静态站点的独立开发者

适合，因为 README 明确把 Coolify 定义为可部署静态站点、数据库和应用的自托管 PaaS，并且只要求服务器可通过 SSH 连接。

  • 支持 VPS、裸机服务器和 Raspberry Pi，不绑定特定云厂商。
  • 应用可以从 GitHub、GitLab、Bitbucket 或 Gitea 构建，并支持 Nixpacks、Railpack、Dockerfile、Docker Compose 和预构建镜像；项目数据也列出了 Next.js、Node.js 和 Svelte5 等主题。
  • 配置保留在自己的服务器上，即使停止使用 Coolify，正在运行的资源仍可继续工作。

不过，这不是由 Vercel 承担运维的托管服务：域名、HTTPS、磁盘、备份、服务器安全和资源容量仍由你负责。README 还建议把 Coolify 管理服务器与资源服务器分开；单台 Raspberry Pi 是否足以同时运行控制面、应用和数据库，README 没有给出容量要求。

  • What is Coolify?: “You only need an SSH connection.”
  • What is Coolify?: “You can use a VPS, a bare-metal server, a Raspberry Pi”
  • What can Coolify do?: 支持 GitHub、GitLab、Bitbucket、Gitea，以及 Nixpacks、Railpack、Dockerfile、Docker Compose 和预构建镜像
  • What is Coolify?: “Your configurations stay on your servers.”
  • Self-hosted or Cloud: “The recommended self-hosted setup uses one server for Coolify and one or more servers for deployed resources.”
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
材料未说明：README 没有说明 Raspberry Pi 的最低 CPU、内存、磁盘或具体支持的系统版本。；README 没有给出 Next.js、数据库和 Coolify 同机运行时的容量或性能上限。
适合 我们已经把 Next.js、Node.js 和 PHP 应用放在 GitHub 中，并用 Docker Compose 描述运行环境；我希望每次 Git push 自动部署、为 Pull Request 创建预览，并能回滚到旧版本，Coolify 是否适合？
适合读者： 使用 GitHub 和 Docker Compose 管理 Next.js、Node.js 与 PHP 应用、需要 PR 预览和回滚的小型开发团队

适合，因为 README 直接覆盖了 Git 推送自动部署、Pull Request 预览和基于保留镜像的回滚，与你们已有的 GitHub 和 Docker Compose 工作流匹配。

  • Coolify 能从 GitHub 获取代码，并把 Docker Compose 作为构建与运行方式之一；这比要求团队迁移到某个单一语言运行时更贴合现有仓库。
  • README 列出了“Deploy on every Git push”“create pull-request previews”以及“roll back to retained application images”，因此发布、预览和回退都有对应能力。
  • 团队可以通过 Dashboard、API、CLI 或 MCP 管理资源，并使用 team-based access controls；项目采用 Apache License 2.0。

但 README 没有说明预览环境如何清理、是否有资源上限、回滚是否包含数据库 schema 和持久化数据，也没有说明 GitHub 权限模型的细节。因此它适合承载应用交付流程，不等于已经提供完整的发布治理方案。

  • What can Coolify do?: “Build from GitHub, GitLab, Bitbucket, or Gitea with Nixpacks, Railpack, Dockerfile, Docker Compose, or a prebuilt Docker image.”
  • What can Coolify do?: “Deploy on every Git push, create pull-request previews, call deployment webhooks, and roll back to retained application images.”
  • What can Coolify do?: “Manage resources through the dashboard, API, CLI, MCP, and team-based access controls.”
  • 项目数据：topics 包含 nextjs、nodejs、php、docker-compose；许可证为 Apache License 2.0
材料未说明：README 没有说明 Pull Request 预览环境的生命周期、清理机制和资源配额。；README 没有说明回滚是否覆盖数据库迁移、持久化卷和外部服务状态。；README 没有展开 GitHub 集成所需的令牌权限和团队角色映射。
适合 我维护 PHP/Laravel 应用，生产配置依赖 Dockerfile、Docker Compose、自定义网络和持久化存储；还需要自动 HTTPS、反向代理与健康检查，Coolify 是否能减少手工服务器配置？
适合读者： 已经维护 Dockerfile 和 Docker Compose 的 PHP/Laravel 团队，要求自定义网络、域名、自动 HTTPS 和健康检查

适合，因为 Coolify 把你需要手工拼接的容器运行、网络入口和基础运维配置放进同一个自托管平台，同时保留 Dockerfile 与 Docker Compose 的控制力。

  • README 支持 Dockerfile、Docker Compose 和预构建 Docker 镜像，因此 PHP/Laravel 团队可以继续使用版本化的容器定义，而不是改写成平台专用格式；项目数据也明确列出 PHP、Laravel 和 Docker 相关生态。
  • 网络能力覆盖自定义域名、自动 HTTPS 证书、反向代理、健康检查和容器网络。
  • 平台还提供持久化存储、环境变量、密钥、日志、容器终端与备份配置，覆盖应用上线后的常见管理面。

限制是“减少配置”不等于“隐藏配置”：域名解析、端口、卷、应用启动命令、数据库迁移和服务器资源仍需要团队理解。README 没有说明 Laravel 的专门运行时适配、队列进程编排或具体健康检查语法。

  • What can Coolify do?: 支持 “Dockerfile, Docker Compose, or a prebuilt Docker image”
  • What can Coolify do?: “Configure custom domains, automatic HTTPS certificates, reverse proxies, health checks, and container networks.”
  • What can Coolify do?: 支持持久化存储、环境变量、密钥、日志、容器终端和备份
  • 项目数据：main_language 为 PHP；topics 包含 laravel、docker、docker-compose
材料未说明：README 没有说明 Laravel 的专用部署模板、队列和定时任务的具体配置方式。；README 没有给出健康检查支持的协议、字段或失败重启行为。；README 没有说明 Docker Compose 版本兼容范围和自定义网络限制。
视情况 我需要管理多台 VPS 上的数据库和 360+ 一键服务，并让团队查看部署日志、运行时日志、容器终端和备份配置；Coolify 能否成为统一运维入口？
适合读者： 负责多个 VPS 和数据库服务的小型运维团队，想用一个控制台管理 360+ 一键服务、日志、备份与团队权限

视情况：Coolify 能覆盖统一入口所需的大部分操作，但它不会替团队承担 VPS、数据库和灾备基础设施的责任。

  • README 明确支持部署数据库和超过 360 种一键服务，并提供持久化存储和生成凭据。
  • 平台可以管理多个服务器，查看部署日志与运行时日志、打开容器终端，并配置数据库和存储备份、定时任务、环境变量、密钥及通知。
  • Dashboard、API、CLI、MCP 和团队级访问控制适合把人工操作与脚本化管理放到同一平台。
  • 推荐拓扑是独立的 Coolify 管理服务器加一个或多个资源服务器，这有利于把控制面和工作负载分开。

如果你需要供应商提供高可用、完整 SLA 或合规责任，仅部署 Coolify 不够；README 的对照表明确把自托管定位为由用户控制并维护完整平台。高可用、备份恢复目标、服务升级兼容性和跨服务器故障切换细节仍需单独确认。

  • What can Coolify do?: “Deploy managed databases and more than 360 one-click services with persistent storage and generated credentials.”
  • What can Coolify do?: “Manage multiple servers, inspect deployment and runtime logs, open container terminals, and monitor resource status.”
  • What can Coolify do?: “Configure database and storage backups, scheduled tasks, environment variables, secrets, and notifications.”
  • What can Coolify do?: “Manage resources through the dashboard, API, CLI, MCP, and team-based access controls.”
  • Self-hosted or Cloud：自托管模式为“Control and maintain the complete platform.”
材料未说明：README 没有给出 360+ 服务的具体清单、版本维护策略或生产支持范围。；README 没有定义备份保留周期、备份目标、恢复时间目标或恢复点目标。；README 没有说明多服务器故障切换、集群高可用或跨节点调度能力。
适合 我负责多个服务器，代码来源包括 GitLab 和 Gitea；团队希望通过 API、CLI 或 MCP 管理部署，并限制不同成员的资源访问，Coolify 是否能满足这种平台入口要求？
适合读者： 需要通过 API、CLI 或 MCP 管理 GitLab/Gitea 部署、并按团队权限操作多个服务器的平台工程师

适合，因为 README 同时列出了 GitLab、Gitea、多服务器管理、API、CLI、MCP 和团队级访问控制，与你描述的平台工程入口直接对应。

  • 应用可从 GitLab 或 Gitea 获取，并使用 Nixpacks、Railpack、Dockerfile、Docker Compose 或预构建镜像构建。
  • Coolify 支持管理多个服务器，因此可以把应用资源分布到不同的 SSH 可访问主机，而不是把所有工作负载绑定到单台机器。
  • 管理入口不只有 Web Dashboard，还包括 API、CLI 和 MCP；README 也明确提供 team-based access controls。
  • 推荐的自托管拓扑将一个服务器用于 Coolify，另一个或多个服务器用于部署资源，适合把平台控制面与运行资源分开。

但 README 没有描述 API 版本策略、CLI 命令覆盖范围、MCP 的具体能力，或团队权限能细分到服务器、项目还是单个资源。因此它满足入口层面的需求，是否满足严格的平台治理仍取决于未公开的权限与接口细节。

  • What can Coolify do?: “Build from GitHub, GitLab, Bitbucket, or Gitea”
  • What can Coolify do?: “Manage multiple servers”
  • What can Coolify do?: “Manage resources through the dashboard, API, CLI, MCP, and team-based access controls.”
  • What is Coolify?: “You only need an SSH connection.”
  • Self-hosted or Cloud：推荐一个 Coolify 服务器和一个或多个资源服务器
材料未说明：README 没有说明 API 的版本兼容策略、认证方式和速率限制。；README 没有列出 CLI 和 MCP 的具体命令、覆盖范围或自动化示例。；README 没有说明团队权限的资源粒度，以及是否支持审计日志。

✨ 核心亮点

  • 支持360+一键服务与持久化存储
  • 兼容GitHub、GitLab与Gitea部署
  • 提供API、CLI、MCP和团队权限
  • 自托管模式需要维护Coolify服务器

🔧 工程化

  • 用Nixpacks、Railpack或Dockerfile构建应用
  • 管理数据库、持久化存储和360+一键服务
  • 支持Git push部署、PR预览与镜像回滚
  • 配置HTTPS、反向代理、健康检查与容器网络

⚠️ 风险

  • 自托管表格明确要求维护完整平台
  • README未列出服务器硬件与系统版本要求
  • 安装命令会直接执行远程install.sh脚本

👥 适合谁？

  • 需要在VPS或裸金属服务器部署应用的团队
  • 同时管理应用、数据库和容器网络的运维者
  • 使用GitHub或GitLab并需要PR预览的开发团队