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再比如用--restartalways却没配 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而是做了三重加固数据卷使用命名卷named volume而非绑定挂载bind mountvolumes: - pgdata:/var/lib/postgresql/data。命名卷由 Docker 管理权限和生命周期避免宿主机用户权限如chown 1001:1001错乱导致容器启动失败初始化脚本预置 n8n 所需 schema在initdb阶段通过docker-entrypoint-initdb.d目录下的 SQL 脚本创建n8n用户、n8n数据库并赋予ALL PRIVILEGES ON DATABASE n8n省去 n8n 首次启动时的自动建表等待连接池显式配置在 n8n 的environment中设置DB_POSTGRES_CONNECTION_LIMIT20防止高并发下连接耗尽。实测对比同样 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/AOFredis.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目的有三HTTPS 强制加密通过certbot自动生成 Lets Encrypt 证书所有流量走https://ai.yourdomain.com。即使你在局域网使用浏览器也会校验证书有效性杜绝中间人窃听路径重写与静态资源托管n8n 前端资源React App默认从/加载但若你想把它放在https://yourserver.com/n8n/下就必须用 Nginx 的location /n8n/ { proxy_pass http://n8n:5678/; }做路径剥离否则 CSS/JS 404请求限流与防爆破limit_req zoneapi burst10 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.1Docker 网关地址无法溯源真实用户。3. 核心组件详解与实操要点从镜像选择到卷挂载的每一处细节3.1 n8n 镜像选型为什么用n8nio/n8n:latest而非n8nio/n8n:latest-rootn8n 官方提供两个基础镜像n8nio/n8n:latest非 root 用户运行UID 1001和n8nio/n8n:latest-rootroot 用户。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 1001mkdir -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 自动创建属主为postgres:postgresUID 999依赖宿主机目录权限常因chown错误导致容器启动失败迁移便利性docker volume inspect pgdata查看路径docker run -v pgdata:/data alpine tar -cf - -C /data . backup.tar需手动rsync -av ./postgres-data/ ./backup/易遗漏隐藏文件SELinux 兼容性默认启用z标签:z自动处理 SELinux 上下文需显式加:z或:Z否则Permission denied更关键的是命名卷在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方案在docker-compose.yml的 n8n service 中添加extra_hostsservices: n8n: extra_hosts: - host.docker.internal:host-gateway这会在容器/etc/hosts中添加172.17.0.1 host.docker.internalDocker Desktop或172.17.0.1 host-gatewayLinux Docker CE使 n8n 内可通过http://host.docker.internal:11434访问宿主机 Ollama。在宿主机启动 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_hostshost.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.ioUbuntu 官方源的 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 # Lets 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_NAMEai.yourdomain.com, POSTGRES_PASSWORDyour_strong_password.env文件中的DOMAIN_NAME必须是你能解析的域名如ai.local可在/etc/hosts中配127.0.0.1 ai.local否则 Lets Encrypt 无法验证。4.3 配置 Nginx 与 HTTPSLets 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_EMAILyouexample.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 214.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 生成文本部署完成后必须立即验证核心能力。创建一个最简工作流添加 HTTP Request 节点MethodPOSTURLhttp://host.docker.internal:11434/api/chat注意是host.docker.internal非localhost设置 BodyJSON{ model: qwen2:1.5b, messages: [ { role: user, content: 用中文写一段关于春天的 50 字描述 } ], stream: false }添加 Set 节点提取响应中的message.content存入$input.item.json.message.content添加 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而非项目目录。排查步骤pwd确认当前路径ls -l docker-compose.yml确认文件存在若路径错误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通常有三个原因模型未预加载Ollama 默认懒加载首次ollama run qwen2:1.5b会下载并解压。解决方案在启动前手动拉取ollama pull qwen2:1.5bGPU 显存不足Qwen2-1.5B FP16 需约 3.2GB 显存。若你的 GPU 只有 4GB如 GTX 1650需改用量化版qwen2:1.5b-q4_k_m仅需 1.1GBCPU 模式性能瓶颈若无 GPUOllama 回退到 CPU 模式qwen2:1.5b在 4 核 CPU 上推理速度约 3 token/s感觉“卡顿”。此时应换更小模型如phi3:3.8b-miniCPU 友好。实测模型推荐按硬件分级硬件配置推荐模型显存/内存占用推理速度token/sRTX 3090 (24GB)qwen2:7b14GB42RTX 3060 (12GB)qwen2:4b8GB28GTX 1650 (4GB)qwen2:1.5b-q4_k_m1.1GB1816GB RAM CPUphi3:3.8b-mini4.2GB85.4 工作流执行失败日志显示 “Error: connect ECONNREFUSED 172.20.0.3:5432” —— PostgreSQL 启动顺序的时序战争这个错误表明 n8n 容器尝试连接 PostgreSQL 时PostgreSQL 容器尚未就绪。虽然depends_on声明了依赖但 Docker Compose 的depends_on只检查容器是否started不检查服务是否readyPostgreSQL 进程启动了但数据库可能还在初始化。starter-kit 的终极解法在 n8n 的docker-compose.yml中用healthcheckrestart策略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: 60spg_isready是 PostgreSQL 自带的健康检查工具比nc -z localhost 5432更精准后者只检测端口不检测数据库是否可接受连接。5.5 如何安全地升级 n8n 版本—— 数据迁移与兼容性红线n8n 版本升级不是简单的image: n8nio/n8n:v1.45.0。必须遵守三步法则查兼容性矩阵访问 n8n 官方文档的 Breaking Changes 确认 v1.45 是否要求 PostgreSQL 15备份数据docker compose exec postgres pg_dump -U n8n n8n backup.sql滚动升级先停旧版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-modelsNVIDIA_VISIBLE_DEVICES环境变量在宿主机设置export NVIDIA_VISIBLE_DEVICESall或指定 GPU ID在 n8n 中添加 HTTP Request 节点URL 设为http://comfyui:8188/promptBody 为 ComfyUI 的 workflow JSON。一个典型漫剧分镜工作流n8n 接收小说文本 → 调用 Ollama 提取角色、场景 → 生成 ComfyUI Prompt → 发送至 ComfyUI API → 等待status返回success→ 下载图片 → 保存到本地 NAS。6.2 用宝塔面板管理针对不熟悉命令行的用户虽然 starter-kit 基于 CLI但可无缝接入宝塔。步骤如下宝塔安装 Docker 插件在宝塔“文件”中上传docker-compose.yml到/www/wwwroot/ai-starter-kit/在宝塔“终端”中执行cd /www/wwwroot/ai-starter-kit docker compose up -d在宝塔“网站”中添加站点域名填ai.yourdomain.com根目录选/www/wwwroot/ai-starter-kit/nginx并开启 SSL
