企业官网建设流程全解析

1. 项目概述：为什么本地 AI 工作流需要 n8n + Docker Compose 这套组合

你是不是也经历过这样的场景：想用本地大模型写小说、生成漫剧脚本、自动处理图片，结果光是装 ComfyUI、Ollama、Llama.cpp 就卡在环境依赖里一整天；好不容易跑通一个模型，又发现它和你的 Notion 笔记、飞书文档、本地文件夹完全不互通；更别提每次重启电脑后，所有服务全挂，还得手动一个个docker run启动——这根本不是“本地 AI”，这是“本地受气包”。

而《n8n self-hosted-ai-starter-kit 安装部署教程》要解决的，正是这个被大量开发者、内容创作者、独立开发者反复踩坑的核心矛盾：AI 工具链高度碎片化，但工作流需求却要求端到端自动化。n8n 不是另一个大模型，它是“AI 工具的调度中枢”；Docker Compose 不是炫技命令，它是让 7 个不同语言、不同依赖、不同端口的服务像一台精密钟表一样咬合运转的物理底盘。这套 starter-kit 的本质，不是教你“怎么装软件”，而是帮你建立一套可复用、可扩展、可离线运行的本地智能体基础设施（Local AI Infrastructure）。

我从 2022 年底开始在 Ubuntu 22.04 和 macOS Sonoma 上实测这套方案，覆盖了小说改编漫剧、AI 绘画批量生成、本地知识库问答、自动化周报生成等 11 类真实场景。最核心的体会是：90% 的失败，不是因为模型不行，而是因为工作流没打通；而 80% 的打通失败，根源在于容器编排没做对。比如很多人直接docker run -p 5173:5173启动 n8n，结果发现它根本连不上同机运行的 Ollama（默认只监听 localhost:11434，而容器内 localhost ≠ 宿主机 localhost）；再比如用--restart=always却没配 healthcheck，导致 Redis 假死、n8n 无限重连却报错“Connection refused”，日志里翻三天都找不到根因。这些细节，恰恰是官方文档不会写的，却是你能否真正把 AI 工作流“用起来”的分水岭。

这套 starter-kit 的关键词非常明确：n8n是逻辑层，负责定义“当飞书收到新文档 → 提取正文 → 调用本地 Qwen2 → 生成三版摘要 → 自动存入 Notion 数据库”这类规则；self-hosted-ai-starter-kit是工程层，它把 n8n、PostgreSQL（持久化工作流数据）、Redis（任务队列缓存）、Nginx（反向代理+HTTPS）、Ollama（模型运行时）甚至可选的 ComfyUI（图像生成）全部打包进统一配置；Docker Compose是执行层，用一份docker-compose.yml文件，就完成了网络隔离、卷挂载、启动顺序、健康检查、重启策略的声明式定义。它不替代你理解技术原理，但它把原理落地的复杂度，从“需要记住 27 条命令”压缩到“只需改 3 行 YAML”。如果你的目标是“今天下午搭好，明天就开始用本地 Qwen 写小说大纲”，那这套方案就是目前最接近开箱即用的路径。

2. 整体架构设计与方案选型逻辑：为什么不是 Kubernetes，也不是纯手动部署

2.1 为什么放弃 Kubernetes？—— 对个人开发者而言，K8s 是杀鸡用牛刀

看到“本地 AI 工作流”，很多工程师第一反应是“上 K8s”。但实测下来，在单机（16GB 内存 + 4 核 CPU）环境下，Kubernetes 的资源开销和运维成本远超收益。我用 MicroK8s 部署过一次完整栈：n8n、PostgreSQL、Redis、Ollama，总内存占用稳定在 3.2GB，其中仅 kubelet + etcd 就占掉 1.1GB；每次kubectl get pods都要等 3 秒响应；更新一个环境变量得写 ConfigMap + RollingUpdate，而 Docker Compose 只需改environment:下一行再docker compose up -d。更关键的是，K8s 的 Service DNS（如postgres.default.svc.cluster.local）在调试阶段极难排查——当你在 n8n 的 HTTP 节点里填http://postgres:5432报错时，你得先确认是否在正确 namespace、是否 Service selector 匹配、Endpoints 是否 ready，而 Docker Compose 的depends_on+ 默认 bridge 网络，让http://postgres:5432在 99% 场景下天然生效。

提示：starter-kit 选择 Docker Compose 的核心依据是“确定性”。K8s 的 declarative model 在集群规模下优势巨大，但在单机场景，它的抽象层反而引入了更多不可控变量。Compose 的 imperative + declarative 混合模式（up/down是命令，docker-compose.yml是声明）更贴合个人开发者的直觉。

2.2 为什么必须包含 PostgreSQL 而非 SQLite？—— 工作流数据的可靠性不能妥协

n8n 官方支持 SQLite 作为后端，很多教程也推荐它“轻量”。但我在实际运行 3 个月后，遭遇了两次数据损坏：一次是同时触发 5 个高频工作流（每分钟 1 次），SQLite 报database is locked；另一次是意外断电后，workflows.json文件部分写入，导致整个工作流列表无法加载。根本原因在于 SQLite 是文件锁，而 n8n 的执行器（executor）是多进程并发的——它会同时打开多个连接写入数据库。PostgreSQL 则通过 MVCC（多版本并发控制）完美解决此问题。starter-kit 中的 PostgreSQL 配置并非简单挂载一个 volume，而是做了三重加固：

1. 数据卷使用命名卷（named volume）而非绑定挂载（bind mount）：volumes: - pgdata:/var/lib/postgresql/data。命名卷由 Docker 管理权限和生命周期，避免宿主机用户权限（如chown 1001:1001）错乱导致容器启动失败；
2. 初始化脚本预置 n8n 所需 schema：在initdb阶段通过docker-entrypoint-initdb.d目录下的 SQL 脚本，创建n8n用户、n8n数据库，并赋予ALL PRIVILEGES ON DATABASE n8n，省去 n8n 首次启动时的自动建表等待；
3. 连接池显式配置：在 n8n 的environment中设置DB_POSTGRES_CONNECTION_LIMIT=20，防止高并发下连接耗尽。

实测对比：同样 100 个并发工作流请求，SQLite 平均失败率 12.7%，PostgreSQL 为 0%；恢复时间上，SQLite 损坏后需手动sqlite3 db.sqlite ".dump" | sqlite3 new.db重建，PostgreSQL 只需pg_dump备份还原，且支持 WAL 归档实现秒级 RPO。

2.3 为什么 Redis 不可省略？—— 任务队列是工作流稳定性的“减震器”

有人问：“n8n 自带内存队列，为什么还要 Redis？”答案藏在两个场景里：一是定时工作流（Cron），二是 Webhook 触发。n8n 的内存队列在容器重启时会清空，所有待执行的定时任务全部丢失；而 Webhook 接收是瞬时高并发的（比如 GitHub push 事件爆发），内存队列溢出直接 502。Redis 作为外部消息中间件，提供了可靠的“生产者-消费者”解耦。starter-kit 中的 Redis 配置有两点关键实践：

• 禁用持久化（RDB/AOF）：redis.conf中设save ""和appendonly no。理由很实在：本地 AI 工作流的任务状态（如“已发送邮件”、“已生成图片”）本就不需要磁盘级持久化，Redis 内存足够容纳数万待执行任务，且重启后 n8n 会自动重载未完成任务到新队列；
• 设置合理内存上限：--maxmemory 512mb --maxmemory-policy allkeys-lru。避免 Redis 吃光宿主机内存导致 OOM Killer 杀掉其他服务（尤其是 Ollama 这种内存大户）。

我曾把 Redis 去掉，用纯内存队列跑了一周漫剧脚本生成（每 15 分钟触发一次），第 3 天凌晨因 n8n 更新自动重启，导致 12 个待生成脚本全部丢失，重跑耗时 47 分钟。加上 Redis 后，同样的更新操作，任务在重启后 2 秒内自动恢复执行。

2.4 为什么 Nginx 是必选项？—— 不只是反向代理，更是安全与体验的守门人

很多教程教“直接访问 n8n 的 5678 端口”，这在测试阶段可行，但一旦涉及真实数据（如你的小说草稿、客户资料），风险陡增。starter-kit 强制集成 Nginx，目的有三：

1. HTTPS 强制加密：通过certbot自动生成 Let's Encrypt 证书，所有流量走https://ai.yourdomain.com。即使你在局域网使用，浏览器也会校验证书有效性，杜绝中间人窃听；
2. 路径重写与静态资源托管：n8n 前端资源（React App）默认从/加载，但若你想把它放在https://yourserver.com/n8n/下，就必须用 Nginx 的location /n8n/ { proxy_pass http://n8n:5678/; }做路径剥离，否则 CSS/JS 404；
3. 请求限流与防爆破：limit_req zone=api burst=10 nodelay;可限制单 IP 每秒最多 10 次 API 请求，有效防御暴力探测/login接口。

特别提醒：Nginx 配置中proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;这两行绝不能少。少了前者，n8n 生成的 Webhook URL 会变成http://localhost:5678/webhook/xxx；少了后者，所有日志里的 IP 都是172.20.0.1（Docker 网关地址），无法溯源真实用户。

3. 核心组件详解与实操要点：从镜像选择到卷挂载的每一处细节

3.1 n8n 镜像选型：为什么用n8nio/n8n:latest而非n8nio/n8n:latest-root？

n8n 官方提供两个基础镜像：n8nio/n8n:latest（非 root 用户运行，UID 1001）和n8nio/n8n:latest-root（root 用户）。starter-kit 严格采用前者，理由基于 Linux 容器安全最佳实践：

• 最小权限原则：n8n 本身不需要 root 权限即可监听 5678 端口（Linux 允许非 root 用户绑定 >1024 端口）；
• 规避 CVE-2022-29153 类漏洞：历史上多个容器逃逸漏洞（如 CVE-2022-29153）利用 root 权限提升，非 root 镜像天然免疫；
• Volume 权限兼容性：当挂载宿主机目录（如./n8n-data:/home/node/.n8n）时，root 镜像会以 UID 0 创建文件，而宿主机用户（如 UID 1000）无权修改，导致Permission denied错误。

实操中，你必须确保宿主机n8n-data目录的属主是 UID 1001：

mkdir -p ./n8n-data sudo chown -R 1001:1001 ./n8n-data

否则容器启动时会报mkdir: cannot create directory '/home/node/.n8n': Permission denied。这个细节，90% 的新手教程都漏掉了。

3.2 PostgreSQL 数据卷的深层配置：命名卷 vs 绑定挂载的实战取舍

starter-kit 使用命名卷pgdata而非./postgres-data:/var/lib/postgresql/data，这不仅是风格差异，更是稳定性设计：

更关键的是，命名卷在docker compose down -v时会自动清理，避免残留数据污染新部署。而绑定挂载的./postgres-data目录，若忘记清空，新容器会加载旧数据，导致 schema 版本冲突（如 n8n v1.42 要求 PostgreSQL 15，而旧数据是 v12 创建的）。

3.3 Ollama 模型服务的网络穿透：如何让 n8n 容器内正确访问宿主机 Ollama？

这是本地 AI 工作流最经典的“跨网络通信”陷阱。Ollama 默认只监听127.0.0.1:11434，而 Docker 容器有自己的网络命名空间，其localhost指向容器自身，而非宿主机。解决方案有二，starter-kit 采用更安全的host.docker.internal方案：

1. 在docker-compose.yml的 n8n service 中添加extra_hosts：

   services: n8n: extra_hosts: - "host.docker.internal:host-gateway"

   这会在容器/etc/hosts中添加172.17.0.1 host.docker.internal（Docker Desktop）或172.17.0.1 host-gateway（Linux Docker CE），使 n8n 内可通过http://host.docker.internal:11434访问宿主机 Ollama。

2. 在宿主机启动 Ollama 时，显式绑定所有接口：

   # 临时方案（不推荐） ollama serve --host 0.0.0.0:11434 # 永久方案（推荐，修改 systemd 服务） sudo systemctl edit ollama # 添加以下内容： [Service] ExecStart= ExecStart=/usr/bin/ollama serve --host 0.0.0.0:11434

   注意：--host 0.0.0.0:11434会让 Ollama 监听所有网络接口，存在安全风险。因此 starter-kit 的默认配置是extra_hosts+host.docker.internal，既保证容器内通信，又不暴露宿主机端口给外部网络。

3.4 ComfyUI 的 GPU 加速配置：如何让容器内正确调用 NVIDIA 显卡？

若你计划用 ComfyUI 生成图像，GPU 加速是刚需。starter-kit 的comfyuiservice 配置如下：

comfyui: image: comfyanonymous/comfyui:latest runtime: nvidia # 关键！指定 NVIDIA 运行时 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu, compute, utility] volumes: - ./comfyui-models:/app/models # 模型挂载 - ./comfyui-custom-nodes:/app/custom_nodes # 插件挂载

这里runtime: nvidia和deploy.resources.reservations.devices是双保险。runtime: nvidia告诉 Docker 使用nvidia-container-runtime，而devices预留确保容器独占一块 GPU（避免多个容器争抢）。实测中，若只配runtime不配devices，在多任务并发时会出现CUDA out of memory，因为显存未被硬隔离。

另外，./comfyui-models目录结构必须严格遵循 ComfyUI 规范：

comfyui-models/ ├── checkpoints/ # .safetensors 大模型 ├── loras/ # LoRA 微调模型 ├── controlnet/ # ControlNet 模型 └── embeddings/ # Textual Inversion 嵌入

若目录名错误（如写成models/），ComfyUI 启动时会报No models found in /app/models/checkpoints，但日志不提示具体原因，只能靠经验排查。

4. 完整部署流程与核心环节实现：从零开始的逐行实操记录

4.1 环境准备：Ubuntu 22.04 下的 Docker 与 Compose 安装（避坑版）

不要用apt install docker.io！Ubuntu 官方源的 Docker 版本太旧（20.10），不支持deploy.resources.reservations.devices。必须用 Docker 官方仓库：

# 卸载旧版 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update && sudo apt install -y \ ca-certificates \ curl \ gnupg \ lsb-release # 添加 Docker 官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加 stable 仓库 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装 Docker Engine sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 验证 sudo docker run hello-world # 应输出 "Hello from Docker!" docker compose version # 应输出 v2.20.0+

关键避坑：docker-compose-plugin是 Docker Compose v2 的核心插件，它将docker-compose命令整合进docker compose（注意空格）。老教程教的pip install docker-compose会安装 v1，与 v2 不兼容，且docker-compose命令已被弃用。

4.2 获取 starter-kit 代码并初始化目录结构

starter-kit 的 GitHub 仓库（假设为github.com/ai-infra/n8n-self-hosted-ai-starter-kit）结构如下：

n8n-self-hosted-ai-starter-kit/ ├── docker-compose.yml # 主编排文件 ├── .env # 环境变量（密码、域名等） ├── nginx/ │ ├── conf.d/default.conf # Nginx 配置 │ └── ssl/ # SSL 证书目录（首次为空） ├── n8n-data/ # n8n 数据卷（首次为空） ├── postgres-data/ # PostgreSQL 数据卷（首次为空） └── scripts/ └── init-ssl.sh # Let's Encrypt 证书申请脚本

克隆并初始化：

git clone https://github.com/ai-infra/n8n-self-hosted-ai-starter-kit.git cd n8n-self-hosted-ai-starter-kit # 创建必要目录 mkdir -p nginx/ssl n8n-data postgres-data # 复制示例 .env 并修改 cp .env.example .env nano .env # 修改 DOMAIN_NAME=ai.yourdomain.com, POSTGRES_PASSWORD=your_strong_password

.env文件中的DOMAIN_NAME必须是你能解析的域名（如ai.local可在/etc/hosts中配127.0.0.1 ai.local），否则 Let's Encrypt 无法验证。

4.3 配置 Nginx 与 HTTPS：Let's Encrypt 一键证书申请

starter-kit 的scripts/init-ssl.sh脚本封装了 certbot 的复杂流程：

#!/bin/bash # scripts/init-ssl.sh DOMAIN=$(grep "DOMAIN_NAME=" .env | cut -d'=' -f2) EMAIL=$(grep "SSL_EMAIL=" .env | cut -d'=' -f2) # 临时启动 Nginx，仅用于 HTTP-01 验证 docker compose up -d nginx # 等待 Nginx 就绪 sleep 5 # 申请证书（standalone 模式，不依赖 webroot） sudo certbot certonly \ --standalone \ --preferred-challenges http \ --agree-tos \ --email "$EMAIL" \ -d "$DOMAIN" \ --non-interactive \ --keep-until-expiring # 复制证书到 nginx/ssl/ sudo cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem nginx/ssl/ sudo cp /etc/letsencrypt/live/$DOMAIN/privkey.pem nginx/ssl/ # 重启 Nginx 加载证书 docker compose restart nginx

执行前确保：

• SSL_EMAIL在.env中已设置（如SSL_EMAIL=you@example.com）；
• 防火墙开放 80 和 443 端口：sudo ufw allow 80 && sudo ufw allow 443；
• 域名 DNS 解析指向本机 IP（云服务器需配置 A 记录）。

证书有效期 90 天，脚本可加入 crontab 自动续期：

# 每月 1 日凌晨 2:15 续期 15 2 1 * * /path/to/n8n-self-hosted-ai-starter-kit/scripts/init-ssl.sh >> /var/log/ssl-renew.log 2>&1

4.4 启动全栈服务与首次登录配置

一切就绪后，执行终极命令：

# 后台启动所有服务 docker compose up -d # 查看服务状态（等待所有显示 "healthy"） docker compose ps # 查看 n8n 日志，确认启动成功 docker compose logs -f n8n | grep "Server listening" # 应输出 "Server listening on port 5678" # 获取初始管理员密码（首次启动自动生成） docker compose exec n8n cat /home/node/.n8n/config # 输出类似：{"user":"admin","password":"$2b$10$..."}

此时访问https://ai.yourdomain.com，即可进入 n8n 登录页。输入上述user和password，首次登录后系统会强制你修改密码并设置邮箱。

实操心得：若页面空白或 CSS 加载失败，90% 是 Nginx 的location / { proxy_pass http://n8n:5678; }缺少proxy_set_header Host $host;。用浏览器开发者工具 Network 标签页，看main.js请求返回 502，就可定位到 Nginx 配置问题。

4.5 验证 AI 工作流：用 n8n 调用本地 Ollama 生成文本

部署完成后，必须立即验证核心能力。创建一个最简工作流：

1. 添加 HTTP Request 节点：MethodPOST，URLhttp://host.docker.internal:11434/api/chat（注意是host.docker.internal，非localhost）；
2. 设置 Body（JSON）：

   { "model": "qwen2:1.5b", "messages": [ { "role": "user", "content": "用中文写一段关于春天的 50 字描述" } ], "stream": false }

3. 添加 Set 节点：提取响应中的message.content，存入$input.item.json.message.content；
4. 添加 Debug 节点：查看输出。

点击 Execute Workflow，若返回"春光明媚，万物复苏，嫩芽破土，鸟语花香..."，则证明 n8n → Ollama 链路完全打通。这是整个本地 AI 工作流的“心脏起搏器”，必须首先验证。

5. 常见问题与排查技巧实录：那些官方文档不会告诉你的真相

5.1 “docker compose ps no configuration file provided: not found” —— 路径与上下文的致命陷阱

这个错误不是配置文件不存在，而是你执行命令时不在docker-compose.yml所在目录。Docker Compose 默认在当前工作目录查找docker-compose.yml或compose.yaml。常见错误场景：

• 你在~/projects/目录下git clone，但cd进入了~/projects/n8n-self-hosted-ai-starter-kit/src/子目录执行docker compose up；
• 你用 VS Code Remote-SSH 连接服务器，但终端默认打开在/home/user，而非项目目录。

排查步骤：

1. pwd确认当前路径；
2. ls -l docker-compose.yml确认文件存在；
3. 若路径错误，cd到正确目录，或使用-f参数指定路径：docker compose -f /full/path/to/docker-compose.yml up -d。

注意：-f参数必须在up之前，docker compose up -f ...是错误语法。

5.2 n8n 启动后白屏，Network 显示main.js404 —— Nginx 路径重写的隐形杀手

当 n8n 部署在子路径（如/n8n/）时，Nginx 配置必须精确剥离前缀。starter-kit 的nginx/conf.d/default.conf中：

location /n8n/ { proxy_pass http://n8n:5678/; # 注意末尾的 / proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # ... 其他 proxy_* 配置 }

关键在proxy_pass http://n8n:5678/;的末尾/。若写成proxy_pass http://n8n:5678;（无/），Nginx 会将/n8n/main.js原样转发给 n8n，而 n8n 只认/main.js，故返回 404。这是 Nginx 文档中极易忽略的细节。

快速验证：在浏览器访问https://ai.yourdomain.com/n8n/healthz，若返回{"status":"ok"}，说明 Nginx 到 n8n 的代理正常；若 404，则一定是proxy_pass路径配置错误。

5.3 Ollama 模型加载缓慢或超时 —— GPU 显存与模型量化格式的双重博弈

在docker compose logs ollama中看到loading model ... timeout，通常有三个原因：

1. 模型未预加载：Ollama 默认懒加载，首次ollama run qwen2:1.5b会下载并解压。解决方案：在启动前手动拉取ollama pull qwen2:1.5b；
2. GPU 显存不足：Qwen2-1.5B FP16 需约 3.2GB 显存。若你的 GPU 只有 4GB（如 GTX 1650），需改用量化版qwen2:1.5b-q4_k_m（仅需 1.1GB）；
3. CPU 模式性能瓶颈：若无 GPU，Ollama 回退到 CPU 模式，qwen2:1.5b在 4 核 CPU 上推理速度约 3 token/s，感觉“卡顿”。此时应换更小模型，如phi3:3.8b-mini（CPU 友好）。

实测模型推荐（按硬件分级）：

5.4 工作流执行失败，日志显示 “Error: connect ECONNREFUSED 172.20.0.3:5432” —— PostgreSQL 启动顺序的时序战争

这个错误表明 n8n 容器尝试连接 PostgreSQL 时，PostgreSQL 容器尚未就绪。虽然depends_on声明了依赖，但 Docker Compose 的depends_on只检查容器是否started，不检查服务是否ready（PostgreSQL 进程启动了，但数据库可能还在初始化）。

starter-kit 的终极解法：在 n8n 的docker-compose.yml中，用healthcheck+restart策略：

services: n8n: depends_on: postgres: condition: service_healthy # 关键！等待 healthcheck 成功 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:5678/healthz"] interval: 30s timeout: 10s retries: 5 start_period: 40s postgres: healthcheck: test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"] interval: 30s timeout: 10s retries: 5 start_period: 60s

pg_isready是 PostgreSQL 自带的健康检查工具，比nc -z localhost 5432更精准（后者只检测端口，不检测数据库是否可接受连接）。

5.5 如何安全地升级 n8n 版本？—— 数据迁移与兼容性红线

n8n 版本升级不是简单的image: n8nio/n8n:v1.45.0。必须遵守三步法则：

1. 查兼容性矩阵：访问 n8n 官方文档的 Breaking Changes ，确认 v1.45 是否要求 PostgreSQL 15+；
2. 备份数据：docker compose exec postgres pg_dump -U n8n n8n > backup.sql；
3. 滚动升级：先停旧版docker compose down，再改docker-compose.yml中的image，最后docker compose up -d。若启动失败，立即docker compose logs n8n查看Migration failed错误，并用备份恢复。

我的血泪教训：曾跳过兼容性检查，直接从 v1.38 升到 v1.44，导致credentials表结构变更，所有 API Key 全部失效，只能从备份中手动导出credentials表并INSERT回新库。

6. 进阶扩展与个性化定制：让 starter-kit 真正属于你

6.1 接入 ComfyUI 构建 AI 绘画工作流

starter-kit 的docker-compose.yml默认注释掉了 ComfyUI 服务。要启用它，取消注释并确保：

• COMFYUI_MODEL_PATH环境变量指向./comfyui-models；
• NVIDIA_VISIBLE_DEVICES环境变量在宿主机设置：export NVIDIA_VISIBLE_DEVICES=all（或指定 GPU ID）；
• 在 n8n 中添加 HTTP Request 节点，URL 设为http://comfyui:8188/prompt，Body 为 ComfyUI 的 workflow JSON。

一个典型漫剧分镜工作流：n8n 接收小说文本 → 调用 Ollama 提取角色、场景 → 生成 ComfyUI Prompt → 发送至 ComfyUI API → 等待status返回success→ 下载图片 → 保存到本地 NAS。

6.2 用宝塔面板管理（针对不熟悉命令行的用户）

虽然 starter-kit 基于 CLI，但可无缝接入宝塔。步骤如下：

1. 宝塔安装 Docker 插件；
2. 在宝塔“文件”中上传docker-compose.yml到/www/wwwroot/ai-starter-kit/；
3. 在宝塔“终端”中执行：

   cd /www/wwwroot/ai-starter-kit docker compose up -d

4. 在宝塔“网站”中添加站点，域名填ai.yourdomain.com，根目录选/www/wwwroot/ai-starter-kit/nginx，并开启 SSL（