自托管 AI 工作流基础设施清单：NAS、VPS、Docker、Tailscale

这篇文章解决什么问题

自托管 AI 工作流最容易被写成“买一台 NAS，再跑个 n8n”。真正落地时，问题要复杂得多：公网 Webhook 怎么进来，内网数据库怎么不裸露，证书和反向代理怎么维护，Postgres 日志怎么清理，容器重启后工作流怎么恢复。

我的判断是：个人开发者前期不应该追求“大而全的私有云”，而是先搭一套边界清楚、能恢复、能备份、能观察的基础设施。NAS、VPS、Docker、Tailscale 和 n8n 各自只做自己擅长的事。

一句话架构

NAS：放数据、备份、内网数据库、对象存储和本地模型服务。
VPS：只做公网入口、反向代理、Webhook 接收和轻量转发。
Docker Compose：固定服务版本、端口、卷挂载和启动顺序。
Tailscale：连接 VPS 与 NAS，让内网服务不用直接暴露到公网。
n8n：作为工作流编排层，负责触发器、节点、任务状态和失败重试。

这个结构的核心不是“省钱”，而是把风险切开。公网机器可以被重建，NAS 数据不能丢；工作流可以失败重跑，凭证和数据库不能乱放。

NAS：别把它只当网盘

NAS 在这套架构里承担三个角色。

第一是数据资产中心。n8n 的二进制文件、导出的工作流、Postgres 备份、日志归档，都应该有清楚的目录结构。不要把所有东西都塞进一个 docker 文件夹，后面排查会很痛苦。

第二是内网计算节点。如果 NAS 是 x86 平台，可以承担轻量 OCR、文件转换、向量索引、本地模型测试。这里要注意，不要把所有 AI 服务都塞在 NAS 上跑，N100 这类机器适合稳定后台任务，不适合长期高并发推理。

第三是备份终点。VPS 上能重装的东西不要长期存，真正需要保留的是数据库 dump、配置文件、密钥备份和工作流导出。

VPS：只暴露必要入口

VPS 的职责应该克制。

它适合做公网入口，例如：

接收 Stripe、GitHub、Gmail、Slack、飞书等 Webhook。
跑 Nginx、Caddy 或 Traefik 做反向代理。
放轻量健康检查和状态页。
作为 Tailscale 节点访问 NAS 内网服务。

它不适合存长期数据，也不适合直接放完整工作流数据库。个人开发者最常见的风险是：为了方便，把 Postgres、Redis、n8n 管理后台全部暴露到公网。短期能跑，长期就是安全债。

Docker Compose：重点不是能启动，而是能恢复

一份能用的 Compose 文件，至少要明确四件事。

services:
  n8n:
    image: n8nio/n8n:stable
    restart: unless-stopped
    environment:
      - N8N_HOST=automation.example.com
      - WEBHOOK_URL=https://automation.example.com/
      - DB_TYPE=postgresdb
    volumes:
      - ./data/n8n:/home/node/.n8n
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - ./data/postgres:/var/lib/postgresql/data

这里只是结构示意，不建议直接复制上线。真正部署时，密钥要放 .env，数据库密码要定期轮换，卷挂载目录要确认权限，备份目录要单独规划。

Tailscale：把公网入口和私有服务隔开

Tailscale 的价值不是“魔法穿透”，而是让 VPS 访问 NAS 时不必把 NAS 的数据库端口暴露到公网。

我更推荐这样的边界：

外部请求先进 VPS。
VPS 通过反向代理或工作流节点访问 Tailnet 内的 NAS 服务。
NAS 上的 Postgres、MinIO、Ollama、内部 API 只监听内网或 Tailnet IP。
n8n 的管理后台开启登录、二次验证、IP 限制或额外网关保护。

这套边界可以降低一个现实风险：VPS 被扫到端口时，攻击面主要在入口层，而不是直接打到你的家庭数据中心。

常见报错和排查顺序

Permission denied

Permission denied: /home/node/.n8n/binaryData

先查宿主机目录权限，再查容器内运行用户。n8n 容器常见 UID/GID 是 1000:1000，不要直接用 chmod 777 图省事。

Webhook 访问 404 或 502

先看三件事：WEBHOOK_URL 是否是公网完整地址，反向代理是否转发正确，n8n 是否知道自己跑在代理后面。很多 404 不是工作流问题，而是入口层路径不一致。

Postgres 越跑越大

如果开启了完整 execution 保存，n8n 的执行记录会持续膨胀。至少要配置保留时间、定期 vacuum、备份策略和告警阈值。

自托管 vs SaaS：别只看价格

维度	自托管 NAS + VPS	Make / Zapier / 托管 n8n
数据控制	数据留在自己机器或指定 VPS	依赖平台托管
维护成本	需要维护系统、备份、安全	基本由平台负责
扩展能力	可写代码、可接内网服务	受平台节点和额度限制
稳定性	取决于你的运维能力	取决于平台 SLA
适合人群	懂 Docker、愿意维护的开发者	想快速交付业务的人

我的建议很简单：如果只是跑几个轻量自动化，用 SaaS 更省心；如果你已经有 NAS、需要接内网数据、对成本和数据边界敏感，再考虑自托管。

上线前检查清单

n8n 管理后台不裸奔。
Webhook 域名、证书、反向代理路径都经过测试。
Postgres 有自动备份和恢复演练。
.env 不进 Git。
Tailscale ACL 不给全网段过大权限。
execution 日志有保留策略。
关键工作流有失败通知。
VPS 和 NAS 都有重启后的自恢复策略。

小白 / Xiaobai

自托管 AI 工作流基础设施清单：NAS、VPS、Docker、Tailscale 与 n8n 部署方案