self-host-n8n-on-gcr

GitHub
592 132 较难 1 次阅读 4天前MIT开发框架Agent图像
AI 解读 由 AI 自动生成，仅供参考

self-host-n8n-on-gcr 是一份详尽的实战指南，旨在帮助用户将强大的工作流自动化平台 n8n 部署在 Google Cloud Run 上。它核心解决了两大痛点：一是让用户彻底摆脱 n8n 官方云服务的月度订阅费用，实现按需付费，闲置时几乎零成本；二是避免了传统自建服务器所需的复杂运维工作，如系统更新、安全补丁和容量规划，真正实现了“无服务器”托管。

这套方案非常适合希望掌控数据主权、拥有定制化自动化需求的技术爱好者、开发者以及中小团队。通过结合 Google Cloud Run 的弹性伸缩能力与 Cloud SQL PostgreSQL 的数据持久化存储，用户既能享受云端部署的便捷，又能确保工作流数据的安全与完整。此外，指南还深度集成了 Google OAuth 认证，方便无缝连接谷歌生态服务。

其独特的技术亮点在于提供了两种部署路径：既包含适合学习原理的手动分步教程，也支持利用 Terraform 进行一键式自动化部署，极大降低了上手门槛。无论你是否熟悉命令行操作，都能借此搭建起一个高可用、低成本且完全由自己掌控的自动化中枢，让复杂的业务流程不再受限于预算或执行次数。

使用场景

某电商初创公司的运营团队需要每日自动同步 Google Sheets 中的订单数据至内部 CRM 系统，并触发邮件通知，但受限于预算和运维能力陷入两难。

没有 self-host-n8n-on-gcr 时

  • 成本高昂：使用 n8n 官方云服务需支付昂贵的月度订阅费，对于订单量波动大的初创公司，固定支出远超实际资源消耗。
  • 数据隐私担忧：敏感的客户订单数据必须流经第三方服务器，无法满足公司对数据完全自主可控的合规要求。
  • 执行限制严格：免费或低价套餐存在严格的任务执行次数限制，促销高峰期频繁触发限额导致自动化流程中断。
  • 运维负担重：若尝试在传统虚拟机上自建，团队需耗费大量精力处理服务器维护、扩容及安全补丁更新。

使用 self-host-n8n-on-gcr 后

  • 极致成本优化：依托 Google Cloud Run 的按量付费模式，无请求时不产生费用，每月自动化成本低至几美元，真正实现了“比咖啡还便宜”。
  • 数据主权回归：所有工作流数据持久化在自有的 Cloud SQL PostgreSQL 数据库中，确保核心业务数据不出私域环境。
  • 弹性无限扩展：Serverless 架构自动应对流量洪峰，促销期间订单激增也能无缝处理，彻底告别执行次数焦虑。
  • 免运维部署：通过 Terraform 脚本一键完成部署与更新，团队无需管理底层服务器，即可享受企业级的自动扩缩容能力。

self-host-n8n-on-gcr 让中小企业能以极低的边际成本，拥有数据完全可控且具备弹性伸缩能力的私有自动化工作流平台。

运行环境要求

操作系统
  • Linux
  • macOS
  • Windows
GPU

不需要 GPU

内存

最低 2GB (Cloud Run 配置)，推荐根据工作流复杂度增加

依赖
notes该工具是基于 Google Cloud Run 的无服务器部署方案，而非本地运行。主要依赖 Docker 构建容器（若在 M1/M2 Mac 上构建自定义镜像，需指定 --platform linux/amd64），并使用 gcloud CLI 进行资源管理。数据库使用 Cloud SQL PostgreSQL，敏感信息通过 Secret Manager 管理。无需本地安装 Python 或特定深度学习库。
python未说明 (基于 Docker 镜像，内部包含 Node.js 环境)
Docker
gcloud CLI
PostgreSQL (Cloud SQL)
n8n Docker Image
self-host-n8n-on-gcr hero image

快速开始

在 Google Cloud Run 上自托管 n8n：完整指南

那么，您是否希望在无需支付月度订阅费用的情况下运行 n8n，将数据完全掌握在自己手中，并避免服务器维护的繁琐工作呢？Google Cloud Run 正好提供了这样一个理想的解决方案——无服务器部署，按使用量计费。让我们来正确地搭建这个系统吧。

本指南将引导您在 Google Cloud Run 上部署 n8n（这款强大的工作流自动化平台），并使用 PostgreSQL 数据库进行持久化存储。最终，您将拥有一个功能齐全、可自动扩展的系统，能够通过 OAuth 与 Google 服务集成，并且在空闲时不会产生高额费用。

🚀 快速入门选项：想跳过手动设置吗？请直接前往 Terraform 部署选项 部分，享受简化、自动化的部署流程。下面的逐步指南有助于您理解背后的实现原理，但 Terraform 将为您完成所有繁重的工作！

目录

概述

n8n 非常适合自动化那些您不想手动执行的繁琐任务。在此方案中：

  • 使用 Google Cloud Run 托管应用程序（仅在运行时付费）

  • 使用 Cloud SQL PostgreSQL 数据库进行持久化存储（确保您的工作流在重启后仍能继续运行）

  • 利用 Google 身份验证平台连接到 Google 服务（如 Sheets、Drive 等）

为什么要选择自托管呢？因为您可以完全掌控自己的自动化工作流和数据，不受任何执行限制，也无需担心敏感数据的存储位置。而借助 Cloud Run，您既能享受自托管的控制权，又能体验无需管理物理服务器的便利性。

前提条件

在开始之前，请确保您已具备以下条件：

  • 一个 Google Cloud 账号（新账号通常享有丰厚的免费套餐）

  • 已安装并配置好 gcloud CLI（相信我，比起在网页控制台中点击操作，命令行更高效）

  • 对 Docker 和命令行的基本熟悉程度

  • Docker（仅在使用自定义镜像时需要 - 选项 B）

  • 一个域名（可选，但建议用于生产环境）

虽然一开始可能会觉得命令行方式有些复杂，但它使我们能够编写脚本来自动化整个部署过程。当您需要更新或重新创建实例时，会感谢自己将所有内容都以可复用的形式组织起来。

社区视频教程

非常感谢 Terra Femme 制作的这份精彩的逐步视频教程，详细展示了整个部署过程！如果您是视觉型学习者，或者希望看到有人实时解决常见问题，那么这段视频绝对不容错过。

▶️ 观看部署视频，由 Terra Femme (@terra.femme) 录制。

该视频涵盖了使用 Google Cloud Shell Editor 完成的完整 Terraform 部署过程，包括修复大多数用户都会遇到的端口配置问题。它基本上就是本指南内容的现场演示，非常棒！

第一步：设置您的 Google Cloud 项目

首先，让我们准备好 Google Cloud 环境：

# 设置您的 Google Cloud 项目 ID
export PROJECT_ID="your-project-id"
export REGION="europe-west2"  # 选择您偏好的区域

# 登录 gcloud
gcloud auth login

# 设置当前活动项目
gcloud config set project $PROJECT_ID

# 启用所需 API
gcloud services enable artifactregistry.googleapis.com
gcloud services enable run.googleapis.com
gcloud services enable sqladmin.googleapis.com
gcloud services enable secretmanager.googleapis.com

这些命令将为您建立项目环境，并启用所需的 Google Cloud API。我们提前开启所有必要的服务，以避免后续出现“请先启用此 API”的错误提示。

第二步：为 n8n 的 Cloud Run 部署做准备

n8n 在连接外部数据库时需要短暂的启动延迟，以避免初始化过程中发生竞态条件。有两种方法可以处理这个问题：

选项 A：使用官方镜像（推荐）

这是最简单的方法——使用 n8n 的官方 Docker 镜像，并通过覆盖启动命令添加 5 秒的延迟。这种做法源自 n8n 自己的 Kubernetes 部署配置文件链接，并且在 Cloud Run 上同样适用。

无需额外文件！ 您将在第 7 步部署时使用命令覆盖参数。

选项 B：自定义 Docker 镜像（进阶）

如果您需要自定义启动逻辑或希望获取详细的调试信息，可以使用自定义 Docker 镜像。这种方法提供了更高的灵活性，但也需要您自行构建和维护镜像。

在您的工作目录中创建以下两个文件：

startup.sh:

#!/bin/sh

# 添加启动延迟，以便数据库初始化
sleep 5

# 如果存在 Cloud Run 的 PORT 变量，则将其映射到 N8N_PORT；
# 否则，使用显式设置的 N8N_PORT，或默认为 5678
if [ -n "$PORT" ]; then
  export N8N_PORT=$PORT
elif [ -z "$N8N_PORT" ]; then
  export N8N_PORT=5678
fi

# 打印环境变量以供调试
echo "数据库设置:"
echo "DB_TYPE: $DB_TYPE"
echo "DB_POSTGRESDB_HOST: $DB_POSTGRESDB_HOST"
echo "DB_POSTGRESDB_PORT: $DB_POSTGRESDB_PORT"
echo "N8N_PORT: $N8N_PORT"

# 使用 n8n 的原始入口点启动程序
exec /docker-entrypoint.sh

端口映射脚本为您提供更大的灵活性：您可以允许 Cloud Run 动态分配端口，也可以显式指定端口。这样做有以下几个好处：

  1. Cloud Run 会自动分配端口——如果部署时未设置 --port=5678，Cloud Run 会注入 PORT 变量。
  2. 具备未来兼容性——即使 Cloud Run 改变端口处理方式，脚本也能适应。
  3. 适用于多种环境——同一镜像既可在 Cloud Run 上运行，也可用于 Cloud Run Jobs 或其他容器平台。

相比之下，选项 A 不需要此脚本，因为它通过命令行参数明确设置了所有内容。

Dockerfile:

FROM docker.n8n.io/n8nio/n8n:latest

# 复制脚本并确保其具有正确的权限
COPY startup.sh /
USER root
RUN chmod +x /startup.sh
USER node
EXPOSE 5678

# 使用 shell 形式以避免 exec 格式问题
ENTRYPOINT ["/bin/sh", "/startup.sh"]

这种自定义设置解决了端口不匹配的问题，并有助于调试。如果没有它，你只会看到一个失败的容器，而没有任何有用的错误信息。是的，这确实像听起来那样令人沮丧。

如果你在使用选项 B 时遇到问题：

  • 检查你的 startup.sh 文件是否使用 Unix 风格的换行符（LF，而不是 CRLF）

  • 确保该文件具有正确的执行权限

你应该选择哪个选项？

  • 选择选项 A 如果你只想让 n8n 在尽量少操心的情况下可靠运行

  • 使用选项 B 如果你需要调试输出或自定义启动脚本

本指南的其余部分将针对两种方法的不同之处分别展示相应的命令。

第 3 步：设置容器仓库（可选——仅适用于自定义镜像）

如果你使用的是选项 A（官方镜像），请完全跳过此步骤，直接进入第 4 步。

如果你使用的是选项 B（自定义镜像），你需要一个地方来存储你的自定义容器镜像：

# 在 Artifact Registry 中创建一个仓库
gcloud artifacts repositories create n8n-repo \
    --repository-format=docker \
    --location=$REGION \
    --description="用于 n8n 工作流镜像的仓库"

# 配置 Docker 以使用 gcloud 作为凭据助手
gcloud auth configure-docker $REGION-docker.pkg.dev

# 构建并推送你的镜像
docker build --platform linux/amd64 -t $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest .
docker push $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest

我们明确地为 linux/amd64 架构构建镜像，因为 Cloud Run 不支持 ARM 架构。这一点尤其重要，如果你是在 M1/M2 Mac 上开发——Docker 默认会愉快地构建一个 ARM 镜像，但部署时却会莫名其妙地失败。就问我是怎么知道的吧。

第 4 步：设置 Cloud SQL PostgreSQL 实例

现在该设置数据库了。我们将使用最小的实例类型以保持合理的成本：

# 创建一个 Cloud SQL 实例（最低成本层级）
gcloud sql instances create n8n-db \
    --database-version=POSTGRES_13 \
    --tier=db-f1-micro \
    --region=$REGION \
    --root-password="supersecure-rootpassword" \
    --storage-size=10GB \
    --availability-type=ZONAL \
    --no-backup \
    --storage-type=HDD

# 创建数据库
gcloud sql databases create n8n --instance=n8n-db

# 为 n8n 创建用户
gcloud sql users create n8n-user \
    --instance=n8n-db \
    --password="supersecure-userpassword"

db-f1-micro 层级非常适合大多数个人 n8n 部署。我在这个配置上运行过数百个工作流，从未出现问题。如果需要，你随时可以升级。

第 5 步：为敏感数据创建 Secret

切勿将密码放入部署配置中。让我们改用 Secret Manager：

# 为数据库密码创建一个 Secret
echo -n "supersecure-userpassword" | \
    gcloud secrets create n8n-db-password \
    --data-file=- \
    --replication-policy="automatic"

# 为 n8n 加密密钥创建一个 Secret
echo -n "your-random-encryption-key" | \
    gcloud secrets create n8n-encryption-key \
    --data-file=- \
    --replication-policy="automatic"

这个加密密钥尤为重要——它保护了你 n8n 实例中存储的所有凭据。请确保密钥足够长、随机且妥善保管。一旦丢失，你将需要重新配置所有连接的服务。

第 6 步：为 Cloud Run 创建服务账户

现在该设置 n8n 实例将使用的身份了：

# 创建服务账户
gcloud iam service-accounts create n8n-service-account \
    --display-name="n8n Service Account"

# 授予访问 Secrets 的权限
gcloud secrets add-iam-policy-binding n8n-db-password \
    --member="serviceAccount:n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

gcloud secrets add-iam-policy-binding n8n-encryption-key \
    --member="serviceAccount:n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

# 授予 Cloud SQL Client 角色
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudsql.client"

在这里遵循最小权限原则意味着你的 n8n 服务只能访问它真正需要的内容，而不会越权。这虽是小事，却对你的安全态势有着重大影响。

第 7 步：部署到 Cloud Run

关键时刻到了——让我们部署 n8n。根据你在第 2 步中选择的方法，部署命令略有不同。

首先获取你的 Cloud SQL 连接名称：

export SQL_CONNECTION=$(gcloud sql instances describe n8n-db --format="value(connectionName)")

选项 A：使用官方镜像部署（推荐）

gcloud run deploy n8n \
    --image=docker.io/n8nio/n8n:latest \
    --command="/bin/sh" \
    --args="-c,sleep 5; n8n start" \
    --platform=managed \
    --region=$REGION \
    --allow-unauthenticated \
    --port=5678 \
    --cpu=1 \
    --memory=2Gi \
    --min-instances=0 \
    --max-instances=1 \
    --no-cpu-throttling \
    --set-env-vars="N8N_PORT=5678,N8N_PROTOCOL=https,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node/.n8n,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true" \
    --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest" \
    --add-cloudsql-instances=$SQL_CONNECTION \
    --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

选项 B：使用自定义镜像部署

# 部署到 Cloud Run
gcloud run deploy n8n \
    --image=$REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest \
    --platform=managed \
    --region=$REGION \
    --allow-unauthenticated \
    --port=5678 \
    --cpu=1 \
    --memory=2Gi \
    --min-instances=0 \
    --max-instances=1 \
    --no-cpu-throttling \
    --set-env-vars="N8N_PATH=/,N8N_PORT=443,N8N_PROTOCOL=https,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node,EXECUTIONS_PROCESS=main,EXECUTIONS_MODE=regular,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true" \
    --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest" \
    --add-cloudsql-instances=$SQL_CONNECTION \
    --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

部署完成后，Cloud Run 会提供一个指向你的 n8n 实例的 URL。请记下它——你将在后续步骤中需要用到。

关键配置说明

为什么使用 --no-cpu-throttling？ n8n 会执行一些后台处理任务（如数据库连接、定时检查等），这些任务并不依赖于 HTTP 请求。如果启用了 CPU 节流功能，这些后台任务就会被限制资源，从而导致启动问题。通过添加该标志，可以确保 n8n 获得持续的 CPU 访问权限，实际上还能节省成本，因为消除了按请求计费的费用，并且降低了 CPU 和内存的费率。感谢 Google Cloud Run 团队提供的这一见解。

其他重要设置：

  • min-instances=0 和 max-instances=1 表示服务在空闲时会缩放至零实例（节省费用），但不会同时运行多个实例（这可能会导致 n8n 的数据库冲突）。
  • CPU 和内存的分配对于大多数工作流来说已经足够，同时不会产生过高的成本。
  • 选项 A 中的 sleep 5 用于处理数据库初始化的时序问题。

选项之间的关键区别

设置 选项 A（官方） 选项 B（自定义） 为何不同？
镜像 docker.io/n8nio/n8n:latest 您的自定义镜像 直接从 n8n 官方仓库拉取 vs 您的私有仓库
命令 --command="/bin/sh" --args="-c,sleep 5; n8n start" 使用自定义入口点 通过命令添加延迟 vs 在脚本中内置延迟
N8N_PORT 5678 443 直接指定端口 vs 通过启动脚本映射
N8N_PATH 不需要 / 自定义镜像可以处理路径前缀

n8n Google Cloud Run 环境变量

以下是所有环境变量的作用：

环境变量 选项 A 值 选项 B 值 描述
N8N_PATH 不需要 / n8n 可访问的基础路径（仅适用于自定义镜像）
N8N_PORT 5678 443 端口配置（直接指定 vs 映射）
N8N_PROTOCOL https https 用于外部访问的协议
DB_TYPE postgresdb postgresdb 必须精确为 “postgresdb”（而非 “postgresql”），以正确连接数据库
N8N_USER_FOLDER /home/node/.n8n /home/node n8n 数据存储位置
EXECUTIONS_PROCESS 不需要 main（已弃用） 已弃用——在较新版本中应移除
EXECUTIONS_MODE 不需要 regular（已弃用） 已弃用——在较新版本中应移除
QUEUE_HEALTH_CHECK_ACTIVE true true 对于 Cloud Run 验证容器健康状态至关重要

请特别注意 DB_TYPE。它必须是 “postgresdb”，而不是 “postgresql”——这是一个常见的部署陷阱。此外，不要显式设置 PORT 变量，因为 Cloud Run 会自动注入该值。

第 8 步：为 n8n 配置与 Google 服务的 OAuth

现在我们需要更新部署，添加环境变量，以告知 n8n 如何正确生成 OAuth 回调 URL：

# 获取您的服务 URL（替换为您实际的 URL）
export SERVICE_URL="https://n8n-YOUR_ID.REGION.run.app"

# 更新部署，配置正确的 URL
gcloud run services update n8n \
    --region=$REGION \
    --update-env-vars="N8N_HOST=$(echo $SERVICE_URL | sed 's/https:\/\///'),N8N_WEBHOOK_URL=$SERVICE_URL,N8N_EDITOR_BASE_URL=$SERVICE_URL"

如果没有这些变量，OAuth 将会失败，并抛出毫无帮助的 “redirect_uri_mismatch” 错误，让人怀疑人生。正确设置这些变量后，n8n 就能在认证流程中构建正确的回调 URL。

对于较新的 n8n 版本，请使用 WEBHOOK_URL 而不是 N8N_WEBHOOK_URL。

第 9 步：设置 Google OAuth 凭证

最后，为了将 n8n 与 Google 服务（如 Sheets）连接起来：

  1. 访问 Google Cloud 控制台：

    • 导航到 Google Cloud 控制台
    • 选择您的项目

  2. 启用所需 API：

    • 转到“APIs & Services” > “Library”
    • 搜索并启用您需要的 API（例如，“Google Sheets API”、“Google Drive API”）

  3. 配置 OAuth 同意屏幕：

    • 转到“APIs & Services” > “OAuth consent screen”
    • 选择“External”用户类型（或“Internal”类型，如果您使用的是 Google Workspace）
    • 填写必要信息（应用名称、用户支持邮箱等）
    • 如果是 External 类型，需添加测试用户
    • 对于范围，目前请添加以下内容：
      • https://googleapis.com/auth/drive.file
      • https://googleapis.com/auth/spreadsheets

    注意：OAuth 同意屏幕的配置决定了您的应用在用户认证时的显示方式。使用 “External” 类型对于个人项目是必要的，但在开发过程中需要添加测试用户。请求的范围决定了 n8n 对 Google 服务的访问权限级别——我们只请求操作 Google Sheets 所必需的最低权限。

  4. 创建 OAuth 客户端 ID：

    • 转到“APIs & Services” > “Credentials”

    • 点击“CREATE CREDENTIALS”，选择“OAuth client ID”

    • 选择“Web application”作为应用类型

    • 将您的 n8n URL 添加到“Authorized JavaScript origins”：

      https://n8n-YOUR_ID.REGION.run.app

    • 在 n8n 中创建凭据时，系统会显示所需的重定向 URL。将其添加到“Authorized redirect URIs”：

      https://n8n-YOUR_ID.REGION.run.app/rest/oauth2-credential/callback

    • 点击“CREATE”以生成您的客户端 ID 和客户端密钥。

  5. 将凭据添加到 n8n：

    • 在您的 n8n 实例中，创建一个新的 Google Sheets 凭据
    • 选择“OAuth2”作为认证类型
    • 将您的 OAuth 客户端 ID 和客户端密钥从 Google Cloud 控制台复制过来
    • 完成认证流程

队列模式部署：扩展 n8n 以适应生产环境

以上步骤为您提供了一个稳定的单进程 n8n 部署方案。对于大多数个人和小型团队来说，这已经足够了。然而，如果您开始运行大量并发的高负载工作流，或者希望在长时间运行的工作流在后台执行时保持编辑器的响应速度，那么 队列模式 就是解决方案。

什么是队列模式？

在常规模式下，n8n 进程负责所有任务：提供 UI、处理 API 请求、接收 Webhook，以及 执行每个工作流。而队列模式则将这些职责分开：

互联网
    │
    ▼
Cloud Run — n8n 主进程       ← 提供编辑器 UI、REST API 和 Webhook
    │  将任务加入队列
    ▼
Cloud Memorystore (Redis)  ← 任务队列 / 消息代理
    │  工作进程轮询
    ▼
Cloud Run — n8n 工作进程 × N ← 执行工作流任务
    │  读取/写入
    ▼
Cloud SQL (PostgreSQL)     ← 主进程与工作进程共享的数据库

主进程不再直接运行工作流。它会将工作流放入 Redis 队列，并立即返回以处理新的请求。工作进程会持续轮询该队列，直到执行完成。这样做的结果是：即使在 CPU 密集型工作流运行时，编辑器依然保持响应；同时，执行能力可以独立进行水平扩展。

何时应使用队列模式？

如果满足以下条件，请继续使用常规模式：

  • 您在轻度至中度负载下将 n8n 用于个人自动化。
  • 成本是首要考虑因素（队列模式会增加约 £50–£70/月 的 Redis 和常驻工作进程费用）。
  • 您的工作流大多是快速的、由 Webhook 触发的任务。

如果满足以下条件，请切换到队列模式：

  • 您有许多并发的长时间运行或 CPU 密集型工作流。
  • 在大量工作流运行期间，n8n 编辑器变得无响应。
  • 您希望独立于 UI 扩展执行能力。
  • 您正在为团队使用 n8n，并需要可靠的吞吐量。

其他先决条件

队列模式需要：

  • 启用 redis.googleapis.com 和 compute.googleapis.com API。
  • 在您的项目中有一个 VPC 网络（默认的自动模式 VPC 即可）。
  • VPC 的 Private Service Access 对等范围可用（用于 Cloud Memorystore）。

Cloud Memorystore Redis 实例只能通过 私有 VPC IP 地址 访问——它们没有公共端点。Cloud Run 通过 Direct VPC Egress 连接到这些实例，该功能会将私有范围的流量（10.x.x.x、172.16.x.x、192.168.x.x）路由到 VPC，而公共互联网流量则走正常路径。

步骤 QM-1：启用额外的 API

gcloud services enable redis.googleapis.com
gcloud services enable compute.googleapis.com

步骤 QM-2：创建 Cloud Memorystore Redis 实例

export REDIS_NAME="n8n-redis"

# 创建一个 Redis 实例 — BASIC 层级，1 GB，Redis 7.2 并启用 AUTH
gcloud redis instances create $REDIS_NAME \
    --region=$REGION \
    --tier=BASIC \
    --size=1 \
    --redis-version=redis_7_2 \
    --network=default \
    --enable-auth

# 获取私有 IP、端口和 AUTH 字符串
export REDIS_HOST=$(gcloud redis instances describe $REDIS_NAME \
    --region=$REGION --format="value(host)")
export REDIS_PORT=$(gcloud redis instances describe $REDIS_NAME \
    --region=$REGION --format="value(port)")
export REDIS_AUTH=$(gcloud redis instances get-auth-string $REDIS_NAME \
    --region=$REGION --format="value(authString)")

echo "Redis 主机: $REDIS_HOST"
echo "Redis 端口: $REDIS_PORT"

层级建议：

  • BASIC — 单节点，无复制。最便宜（1 GB 大概每月 £35）。适合个人使用；如果 Redis 重启，任何正在进行的执行任务都会丢失（需要重新触发）。
  • STANDARD_HA — 主节点 + 副本，具备自动故障转移功能。适用于生产环境，可用性更高（1 GB 大概每月 £70）。

网络说明： --network=default 会将 Memorystore 实例对等接入默认 VPC。如果您不使用默认网络，请替换为您自定义的 VPC 名称。

步骤 QM-3：将 Redis AUTH 字符串存储到 Secret Manager 中

# 存储 Redis AUTH 字符串
echo -n "$REDIS_AUTH" | \
    gcloud secrets create n8n-redis-auth \
    --data-file=- \
    --replication-policy="automatic"

# 授予 n8n 服务账号访问该密钥的权限
gcloud secrets add-iam-policy-binding n8n-redis-auth \
    --member="serviceAccount:n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

步骤 QM-4：更新主 n8n 服务以支持队列模式

主服务需要添加三项内容：EXECUTIONS_MODE=queue 以激活队列模式，Redis 连接信息以告知队列位置，以及 Direct VPC Egress 以便能够实际连接到 Memorystore 的私有 IP。

gcloud run services update n8n \
    --region=$REGION \
    --vpc-egress=private-ranges-only \
    --network=default \
    --subnet=default \
    --update-env-vars="EXECUTIONS_MODE=queue,QUEUE_BULL_REDIS_HOST=$REDIS_HOST,QUEUE_BULL_REDIS_PORT=$REDIS_PORT" \
    --update-secrets="QUEUE_BULL_REDIS_PASSWORD=n8n-redis-auth:latest"

子网说明： 对于默认的自动模式 VPC，--subnet=default 会自动选择区域子网。如果您使用自定义 VPC，请指定您所在区域的确切子网名称（例如 --subnet=my-subnet）。

步骤 QM-5：部署 n8n 工作进程服务

工作进程运行的是 n8n worker 命令，而不是 n8n start。它们不提供面向公众的流量服务，而是轮询 Redis 并连接到 Cloud SQL。

gcloud run deploy n8n-worker \
    --image=docker.io/n8nio/n8n:latest \
    --command="/bin/sh" \
    --args="-c,sleep 5; n8n worker" \
    --platform=managed \
    --region=$REGION \
    --no-allow-unauthenticated \
    --ingress=internal \
    --port=5678 \
    --cpu=1 \
    --memory=2Gi \
    --min-instances=1 \
    --max-instances=3 \
    --no-cpu-throttling \
    --vpc-egress=private-ranges-only \
    --network=default \
    --subnet=default \
    --set-env-vars="EXECUTIONS_MODE=queue,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node/.n8n,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true,N8N_RUNNERS_ENABLED=true,QUEUE_BULL_REDIS_HOST=$REDIS_HOST,QUEUE_BULL_REDIS_PORT=$REDIS_PORT" \
    --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest,QUEUE_BULL_REDIS_PASSWORD=n8n-redis-auth:latest" \
    --add-cloudsql-instances=$SQL_CONNECTION \
    --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

关键工作进程设置说明：

设置 值 作用
--ingress=internal internal 工作进程不接收公共 HTTP 流量——仅限内部访问
--no-allow-unauthenticated — 工作进程不应被公开调用
--min-instances=1 1 至少需要有一个工作进程始终运行，否则排队的任务永远不会开始
--no-cpu-throttling — 工作进程会持续轮询 Redis，在“请求”之间也需要 CPU 资源
EXECUTIONS_MODE=queue queue 告诉工作进程从 Redis 中获取任务

队列模式环境变量参考

变量 主服务 工作进程 描述
EXECUTIONS_MODE queue queue 激活队列模式。没有此设置，工作进程将无法运行。
QUEUE_BULL_REDIS_HOST Redis 私有 IP Redis 私有 IP Memorystore 实例的主机地址
QUEUE_BULL_REDIS_PORT 6379 6379 Redis 端口（Memorystore 默认值）
QUEUE_BULL_REDIS_PASSWORD （来自 Secret） （来自 Secret） 存储在 Secret Manager 中的 AUTH 字符串
QUEUE_HEALTH_CHECK_ACTIVE true true 暴露 /healthz — Cloud Run 健康检查所需
N8N_RUNNERS_ENABLED 未设置 true 在工作进程中启用任务运行子系统。请勿在队列模式下的主服务上设置此选项——主进程不会执行工作流，若在此处设置会导致 n8n 在启动时崩溃，HTTP 服务器无法启动。

扩展工作进程

队列模式的主要优势之一是无需修改主服务即可增加执行容量。如果队列中的工作流开始积压：

# 提高工作进程的最大实例数
gcloud run services update n8n-worker \
    --region=$REGION \
    --max-instances=10

Cloud Run 会根据负载动态扩展工作进程数量，直至达到 max-instances 的上限。为降低工作进程层的冷启动延迟，建议将 min-instances 调整至 2。

验证队列模式是否正常运行

部署完成后，打开 n8n 编辑器，导航至 Settings → Workers（n8n ≥ 1.x）。您应能看到工作进程实例列表。若列表为空或显示工作进程已断开连接，请参阅下方的 队列模式故障排除 部分。

保持 n8n 更新：别再使用一年前的老版本了

更新您的 n8n 部署其实非常简单，而且为了获取新功能和安全补丁，您应该定期进行更新。以下是新版本发布时的更新方法：

对于方案 A（官方镜像）

最简单的方法就是更新镜像标签：

升级到最新版本：

gcloud run services update n8n \
    --image=docker.io/n8nio/n8n:latest \
    --region=$REGION

或指定特定版本：

gcloud run services update n8n \
    --image=docker.io/n8nio/n8n:latest:1.115.2 \
    --region=$REGION

Cloud Run 会自动拉取新镜像并完成部署，整个过程大约需要 1–2 分钟。

如果您使用的是队列模式，也需要更新工作进程服务：

gcloud run services update n8n-worker \
    --image=docker.io/n8nio/n8n:latest \
    --region=$REGION

确保主服务和所有工作进程运行相同版本的 n8n非常重要。队列模式下版本不一致可能导致队列协议不匹配。

对于方案 B（自定义镜像）

方法 1：重新构建并重新部署（干净的方式）

# 拉取最新的 n8n 镜像
docker pull n8nio/n8n:latest

# 重新构建您的自定义镜像
docker build --platform linux/amd64 -t $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest .

# 推送至您的制品仓库
docker push $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest

# 重新部署您的 Cloud Run 服务
gcloud run services update n8n \
    --image=$REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest \
    --region=$REGION

# 如果使用队列模式，也需更新工作进程
gcloud run services update n8n-worker \
    --image=$REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest \
    --region=$REGION

此过程通常需要 2–3 分钟，您的 n8n 实例会在 Cloud Run 切换到新容器时短暂中断。任何正在运行的工作流都会被中断，但一旦服务恢复，计划触发器将自动继续执行。

方法 2：指定版本（可控的方式）

如果您希望更谨慎地管理版本升级（推荐用于生产环境），可以指定确切的 n8n 版本：

# 拉取特定版本
docker pull n8nio/n8n:0.230.0  # 替换为您目标版本

# 更新 Dockerfile 以使用该特定版本
# FROM n8nio/n8n:0.230.0

# 然后按照上述步骤重新构建并重新部署

这种方式允许您在正式升级之前先测试新版本。升级前请查看 n8n GitHub 发布页面，了解新功能和变更内容。

数据库迁移

使用 PostgreSQL 与 n8n 结合的一大优势是自动数据库迁移。当您部署新版本时，n8n 将：

  1. 检测到数据库模式需要更新；
  2. 在启动时自动执行迁移；
  3. 仅在数据库兼容时继续运行。

因此，通常您无需担心数据库变更。不过，始终建议：

  • 在重大版本升级前备份数据库；
  • 查看发行说明，确认是否存在破坏性变更；
  • 如果有关键工作流，可在预发布环境中测试升级。

我通常会在进行重大版本跳跃前，为我的 Cloud SQL 实例创建快照，以防万一。

更新环境变量

有时您可能需要更新环境变量，而非直接更新容器：

gcloud run services update n8n \
    --region=$REGION \
    --update-env-vars="NEW_VARIABLE=value,UPDATED_VARIABLE=new_value"

这在无需重建容器的情况下更改配置时非常有用。

自动化提示

您可以编写一个简单的 Shell 脚本，将这些命令整合在一起，只需一条命令即可更新您的 n8n 实例。我会将脚本保存在私有 GitHub 仓库中，与 Dockerfile 和启动脚本一起存放，方便随时随地维护和更新。

定期更新可确保您的实例安全，并让您及时获得新节点和功能。n8n 团队通常每两周发布一次更新，因此对于大多数部署来说，每月检查一次是一个不错的频率。

成本估算：确实可以非常便宜

让我们谈谈成本。采用这种部署方式的主要原因之一就是其经济高效性。相比更为成熟的 Kubernetes 方案，这种自托管方式成本更低；即使与 n8n 最低付费层级相比，也最多只有一半的价格。以下是您每月可能需要支付的费用：

普通模式（默认）

Google Cloud SQL (db-f1-micro)：如果持续运行，每月约 £8.00。这是主要的成本驱动因素——一个基础的 PostgreSQL 实例，对于个人使用来说已经足够强大。

Google Cloud Run：对于轻量级使用而言，几乎免费，因为其提供了慷慨的免费配额：

  • 每月 200 万次请求；
  • 36 万 GB-秒内存；
  • 18 万 vCPU-秒。

通过将我们的配置设置为 min-instances=0，您的 n8n 容器在不使用时会完全关闭，在空闲期间几乎不产生任何费用。当它运行时，只会消耗您的免费配额。

Secret Manager、Artifact Registry 等：这些附加服务也都提供免费配额，您很可能不会超出。

普通模式下预计每月总成本：£2–£12

队列模式的额外成本

队列模式会添加持久性基础设施，这些基础设施不会缩放到零：

Cloud Memorystore Redis（BASIC，1 GB）：约£35–£45/月。Redis 会持续运行，是队列模式中最大的开销。

n8n 工作器（Cloud Run 服务，最小 1 个实例）：工作器通过 min-instances=1 和 --no-cpu-throttling 保持运行状态，因此会持续计费。在大多数地区，1 vCPU + 2 GiB 的配置下，费用约为£15–£25/月。

队列模式的预计每月总成本：约£55–£80

当您大量使用 n8n，额外的容量和响应速度能够证明其成本合理性时，队列模式就值得采用。对于轻量级的个人使用，常规模式无疑是更好的选择。

如何降低成本

  • 在非高峰时段安排维护：如果您有批量处理数据的工作流，请将其安排在不活跃的时间段内执行。

  • 高效使用 Webhook：尽可能设计通过 Webhook 触发而非持续轮询的工作流。

  • 监控使用情况：Google Cloud 提供了出色的使用情况仪表板——请在第一个月定期查看，以了解您的资源消耗模式。

  • 设置预算警报：在 Google Cloud 中配置预算警报，以便在支出超过阈值时收到通知。

  • 队列模式的规模调整：在队列模式下，先从 1 个工作器实例开始，只有在确实出现执行压力时才增加 max-instances。过度 provision 工作器是导致账单飙升的最快方式。

哪些因素可能会推高成本？频繁运行 CPU 密集型工作流、在 PostgreSQL 中存储大量数据，或为实例配置过多资源。

但对于大多数个人自动化需求而言，这种配置以“咖啡钱”般的成本提供了企业级功能。我已使用这一配置运行数月，即使有数十个工作流在运行，我的账单也始终低于 £5。

故障排除

注意：如果您使用 Terraform 进行部署，请参阅Terraform 故障排除部分，以获取与部署相关的具体问题。

当不可避免地出现问题时，以下是常见问题及解决方法：

  1. 容器无法启动：

    • 检查 Cloud Run 日志以获取具体的错误信息
    • 确认 DB_TYPE 已设置为 “postgresdb”（而不是 “postgresql”）
    • 确保 QUEUE_HEALTH_CHECK_ACTIVE 设置为 “true”
    • 移除 EXECUTIONS_PROCESS=main 和 EXECUTIONS_MODE=regular 环境变量，因为这些变量在较新版本中已被弃用

  2. OAuth 重定向问题：

    • 确保 N8N_HOST、N8N_PORT 和 N8N_EDITOR_BASE_URL 设置正确
    • 验证 Google Cloud 控制台中的重定向 URI 是否与 n8n 生成的完全一致
    • 确认 N8N_PORT 已设置为 443（而非 5678），以确保外部 URL 格式正确

  3. 数据库连接问题：

    • 检查 Cloud SQL 连接的 DB_POSTGRESDB_HOST 格式
    • 确保服务账户拥有 Cloud SQL Client 角色

  4. 节点触发问题：

    • 对于较新版本的 n8n，请使用 WEBHOOK_URL 而不是 N8N_WEBHOOK_URL
    • 添加代理跳转配置，通过设置 N8N_PROXY_HOPS=1 来实现，因为 Cloud Run 充当反向代理

队列模式相关问题

  1. 工作器未出现在 n8n 设置 → 工作器中：

    • 确认主服务和工作器均将 EXECUTIONS_MODE=queue 设置正确
    • 验证两个服务上的 QUEUE_BULL_REDIS_HOST 和 QUEUE_BULL_REDIS_PORT 是否正确设置——主机必须是 Memorystore 实例的私有 IP，而非主机名或公有地址
    • 检查是否已从 Secret Manager 正确注入 QUEUE_BULL_REDIS_PASSWORD——缺失或错误的 AUTH 字符串会导致连接静默失败
    • 确认两个 Cloud Run 服务均已启用 Direct VPC 出站流量（--vpc-egress=private-ranges-only），并且与 Memorystore 实例位于同一 VPC 网络中

  2. 执行任务一直停留在“等待”状态：

    • 这意味着作业已入队，但没有工作器来处理它们
    • 检查工作器 Cloud Run 服务的日志，查看是否有 Redis 连接错误
    • 确保工作器服务设置了 --min-instances=1——如果工作器缩放到了零，作业将无限期等待
    • 验证工作器正在运行 n8n worker（而非 n8n start）——检查命令覆盖设置

  3. 日志中出现“无法连接到 Redis”的错误：

    • 确认 Memorystore 实例与 Cloud Run 服务位于同一 VPC 网络中
    • 验证出错的 Cloud Run 服务是否已配置 Direct VPC 出站流量
    • 检查 redis.googleapis.com 和 compute.googleapis.com API 是否已启用
    • 尝试直接获取 Redis 主机 IP：gcloud redis instances describe n8n-redis --region=$REGION --format="value(host)"，并确认其与环境变量中的值一致

  4. VPC 出站流量导致对外连接问题：

    • private-ranges-only 出站设置仅允许 10.x.x.x、172.16.x.x 和 192.168.x.x 流量通过 VPC 路由——其他所有流量（包括来自工作流的外部 API 调用）仍会通过普通互联网路径传输，因此这通常不会影响大多数工作流。
    • 如果确实遇到与外部服务的连接问题，请再次确认您使用的是 private-ranges-only 而不是 all-traffic。

  5. 队列模式下主 n8n 服务容器在启动时崩溃（exit(1)）：

    • 当主服务（n8n start）在队列模式下设置了 N8N_RUNNERS_ENABLED=true 时，就会发生这种情况。主进程仅负责 UI、API 和 Webhook，而不执行工作流。设置该标志后，n8n 会在启动时急于启动一个任务运行程序，而该程序会在 HTTP 服务器准备就绪之前崩溃。Cloud Run 会报告健康检查失败，但真正的问题是应用程序日志中的 exit(1) 错误。
    • 解决方法：不要在主服务上设置 N8N_RUNNERS_ENABLED。工作器需要它（它们会运行代码）。主服务则不需要。
    • 要确认根本原因，请在失败的修订版上筛选 Cloud Logging 中的 run.googleapis.com/stdout 和 run.googleapis.com/stderr——n8n 的确切崩溃信息会显示在那里，比 Cloud Run 的系统事件更具有参考价值。

Terraform 部署选项

感谢社区的慷慨贡献，现在提供了一个 Terraform 配置，可自动完成本指南中描述的整个部署过程。此 Terraform 设置会预配所有必要的 Google Cloud 资源，包括 Cloud Run、Cloud SQL、Secret Manager、IAM 角色和 Artifact Registry。

使用 Terraform 可简化并加速部署，尤其适合熟悉基础设施即代码的人士。Terraform 文件和部署脚本已包含在仓库中。

Terraform 快速部署

克隆仓库并进入 terraform 目录：

git clone <your-repo-url>
cd <repo-name>/terraform

初始化 Terraform：

terraform init

查看计划中的更改：

terraform plan

[如果已创建 terraform.tfvars 文件，可使用标志 terraform plan -var-file=terraform.tfvars]

部署基础设施。

选项 A（推荐——官方镜像）：

terraform apply

[如果已创建 terraform.tfvars 文件，可使用标志 terraform apply -var-file=terraform.tfvars]

选项 B（自定义镜像）：

terraform apply -var="use_custom_image=true"

或者在 terraform.tfvars 中：

use_custom_image = true  # 仅当您希望使用自定义镜像时

Terraform 队列模式部署

Terraform 配置通过一个功能标志支持队列模式。当 enable_queue_mode = true 时，Terraform 还会额外预配以下资源：

  • 一个 Cloud Memorystore Redis 实例（私有、与 VPC 对等）
  • 一个带有内部入口且至少 1 个实例的 Cloud Run 工作器服务 (n8n-worker)
  • Secret Manager 中的一个 Redis AUTH 密钥
  • 在两个 Cloud Run 服务上启用 直接 VPC 出口
  • 启用 redis.googleapis.com 和 compute.googleapis.com API

通过 CLI 标志启用队列模式：

terraform apply -var="enable_queue_mode=true"

或者在 terraform.tfvars 中：

gcp_project_id    = "your-project-id"
enable_queue_mode = true

# 可选：调整 Redis 和工作器的规模
redis_tier           = "BASIC"       # 或 "STANDARD_HA" 用于生产环境
redis_memory_size_gb = 1
worker_min_instances = 1
worker_max_instances = 3
worker_cpu           = "1"
worker_memory        = "2Gi"

# 可选：指定 VPC 网络/子网，如果不使用默认 VPC
# vpc_network    = "default"
# vpc_subnetwork = ""   # 留空以自动选择

然后运行：

terraform plan -var-file=terraform.tfvars
terraform apply -var-file=terraform.tfvars

Terraform 将输出：

  • cloud_run_service_url — 公开的 n8n 编辑器 URL
  • cloud_run_worker_service_url — 工作器服务的内部 URL（不可公开访问）
  • redis_host — Memorystore 实例的私有 IP 地址
  • redis_port — Redis 端口
  • cloud_sql_connection_name — Cloud SQL 连接名称

关于预配时间的说明： Cloud Memorystore 实例需要 5–10 分钟才能完成预配。Terraform 会等待该实例就绪后再创建工作器服务。总体而言，队列模式部署的 terraform apply 通常需要 15–20 分钟。

将现有部署升级到队列模式

如果您已经使用 Terraform 部署了标准（非队列）配置，并希望添加队列模式，只需在 terraform.tfvars 中添加 enable_queue_mode = true，然后再次运行 terraform apply。Terraform 会逐步添加新资源，而不会影响现有资源。

# 添加到现有的 terraform.tfvars
echo 'enable_queue_mode = true' >> terraform.tfvars

terraform plan   # 检查将要添加的内容
terraform apply  # 应用更改

Terraform 故障排除

如果您在 Terraform 部署过程中遇到问题，尤其是在之前手动安装或 Terraform 运行失败之后，可能需要先清理现有资源。

常见的需要清理的情况：

  • 您在发现 Terraform 选项之前已经按照手动步骤操作过
  • 之前的 Terraform 部署在构建过程中超时或失去连接
  • 您看到“资源已存在”的错误

清理步骤：

  1. 移除 Terraform 状态文件（如果状态文件已损坏）：
cd terraform/
rm -rf terraform.tfstate*
rm -rf .terraform/
  1. 通过控制台或 CLI 删除现有的 Google Cloud 资源：

Artifact Registry：

gcloud artifacts repositories delete n8n-repo --location=$REGION

Cloud SQL 实例：

gcloud sql instances delete n8n-db

密钥：

gcloud secrets delete n8n-db-password
gcloud secrets delete n8n-encryption-key
gcloud secrets delete n8n-redis-auth  # 仅队列模式

服务账户：

gcloud iam service-accounts delete n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

Cloud Run 服务：

gcloud run services delete n8n --region=$REGION
gcloud run services delete n8n-worker --region=$REGION  # 仅队列模式

Cloud Memorystore Redis（仅队列模式）：

gcloud redis instances delete n8n-redis --region=$REGION
  1. 另一种方法：使用 Google Cloud 控制台
  • 导航到每个服务（Cloud Run、Cloud SQL、Memorystore、Secret Manager、IAM、Artifact Registry）
  • 查找并删除与 Terraform 配置匹配的资源
  • 这种可视化方式更容易识别部分创建的资源。
  1. 重新运行 Terraform：
terraform init
terraform plan # 确认没有冲突
terraform apply

实用提示： 如果您不确定哪些资源已被创建，可以查看 Terraform 配置文件，了解将要预配的资源的确切名称和类型。

非常感谢 @alliecatowo 的这一宝贵贡献！

有关更多详细信息和使用说明，请参阅此仓库中的 terraform/ 目录。

就这样，您现在拥有一个完全可用的 n8n 实例，运行在 Google Cloud Run 上。您既享受到了自托管的所有优势，又无需为服务器管理操心。您的工作流稳定可靠，数据始终掌握在您手中，而且只需按实际用量付费。

版本历史

v3.1.02026/03/25
v3.0.02025/10/07
v2.0.02025/08/04

常见问题

相似工具推荐

openclaw

OpenClaw 是一款专为个人打造的本地化 AI 助手，旨在让你在自己的设备上拥有完全可控的智能伙伴。它打破了传统 AI 助手局限于特定网页或应用的束缚，能够直接接入你日常使用的各类通讯渠道，包括微信、WhatsApp、Telegram、Discord、iMessage 等数十种平台。无论你在哪个聊天软件中发送消息，OpenClaw 都能即时响应，甚至支持在 macOS、iOS 和 Android 设备上进行语音交互，并提供实时的画布渲染功能供你操控。 这款工具主要解决了用户对数据隐私、响应速度以及“始终在线”体验的需求。通过将 AI 部署在本地，用户无需依赖云端服务即可享受快速、私密的智能辅助，真正实现了“你的数据，你做主”。其独特的技术亮点在于强大的网关架构，将控制平面与核心助手分离，确保跨平台通信的流畅性与扩展性。 OpenClaw 非常适合希望构建个性化工作流的技术爱好者、开发者，以及注重隐私保护且不愿被单一生态绑定的普通用户。只要具备基础的终端操作能力（支持 macOS、Linux 及 Windows WSL2），即可通过简单的命令行引导完成部署。如果你渴望拥有一个懂你

★ 349.3k|★★★☆☆|3天前
Agent开发框架图像

stable-diffusion-webui

stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。 无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。

★ 162.1k|★★★☆☆|4天前
开发框架图像Agent

everything-claude-code

everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。 通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。 这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上

★ 147.9k|★★☆☆☆|今天
开发框架Agent语言模型

ComfyUI

ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。 这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。 无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。

★ 108.1k|★★☆☆☆|昨天
开发框架图像Agent

markitdown

MarkItDown 是一款由微软 AutoGen 团队打造的轻量级 Python 工具，专为将各类文件高效转换为 Markdown 格式而设计。它支持 PDF、Word、Excel、PPT、图片（含 OCR）、音频（含语音转录）、HTML 乃至 YouTube 链接等多种格式的解析，能够精准提取文档中的标题、列表、表格和链接等关键结构信息。 在人工智能应用日益普及的今天，大语言模型（LLM）虽擅长处理文本，却难以直接读取复杂的二进制办公文档。MarkItDown 恰好解决了这一痛点，它将非结构化或半结构化的文件转化为模型“原生理解”且 Token 效率极高的 Markdown 格式，成为连接本地文件与 AI 分析 pipeline 的理想桥梁。此外，它还提供了 MCP（模型上下文协议）服务器，可无缝集成到 Claude Desktop 等 LLM 应用中。 这款工具特别适合开发者、数据科学家及 AI 研究人员使用，尤其是那些需要构建文档检索增强生成（RAG）系统、进行批量文本分析或希望让 AI 助手直接“阅读”本地文件的用户。虽然生成的内容也具备一定可读性，但其核心优势在于为机器

★ 93.4k|★★☆☆☆|3天前
插件开发框架

LLMs-from-scratch

LLMs-from-scratch 是一个基于 PyTorch 的开源教育项目，旨在引导用户从零开始一步步构建一个类似 ChatGPT 的大型语言模型（LLM）。它不仅是同名技术著作的官方代码库，更提供了一套完整的实践方案，涵盖模型开发、预训练及微调的全过程。 该项目主要解决了大模型领域“黑盒化”的学习痛点。许多开发者虽能调用现成模型，却难以深入理解其内部架构与训练机制。通过亲手编写每一行核心代码，用户能够透彻掌握 Transformer 架构、注意力机制等关键原理，从而真正理解大模型是如何“思考”的。此外，项目还包含了加载大型预训练权重进行微调的代码，帮助用户将理论知识延伸至实际应用。 LLMs-from-scratch 特别适合希望深入底层原理的 AI 开发者、研究人员以及计算机专业的学生。对于不满足于仅使用 API，而是渴望探究模型构建细节的技术人员而言，这是极佳的学习资源。其独特的技术亮点在于“循序渐进”的教学设计：将复杂的系统工程拆解为清晰的步骤，配合详细的图表与示例，让构建一个虽小但功能完备的大模型变得触手可及。无论你是想夯实理论基础，还是为未来研发更大规模的模型做准备

★ 90.1k|★★★☆☆|3天前
语言模型图像Agent