每个频道每月五美元。这就是我在续费页面上反复盯着的数字，因为它悄悄决定了我被允许在多少个地方发布内容。四个频道就是五乘以四。以后再加一个品牌，账单还会再涨一次——而这些定时发布的内容本来就是我自己写的。
我本来就在一台 VPS 上跑着 n8n，用于两个不相干的自动化任务，于是给自己一个周末，看看能不能把它改造成面向 X、LinkedIn、Instagram 和 Facebook 的 n8n 社交媒体排期工具。到现在已经跑了四个月。下面是这次切换真正花掉我多少成本、出过哪些问题，以及我至今仍不推荐的场景。
简短版本
- 我让 X、LinkedIn、Facebook 和 Instagram 都从同一个工作流发布，但这四条分支的工作量并不一样。
- 问题出在 Instagram：专业账号的强制要求、媒体格式规则、发布上限和令牌生命周期，全都带来了我在 Buffer 上从未有过的维护负担。
- 我把 TikTok 排除在外，因为 n8n 的内置应用节点目录里没有它，而我不愿意让自定义节点或社区集成成为发布排期的一部分。
- Community Edition 免掉的是软件费用，而不是成本。托管费我照付，更新、凭据、备份、监控和失败发布的补救也都归我。
- 我的结论是：这次切换值得，因为我想把撰稿和发布放进同一条流水线。如果我要的只是一个可视化日历和稳定的发布队列，我就不会走。
我到底在为什么付费，以及最终让我下定决心的原因
Buffer 的当前定价 显示 Essentials 按年付费时为每个频道每月 5 $，免费方案则最多支持三个频道、每个频道十条定时发布。因此我的四个付费频道按年付费是每月 20 $。作为一款打磨得不错的排期工具，这个定价方式并不过分，但它偏偏是按我最想扩展的那件事收费：把同一个想法同时改写成适配多个平台的版本。
最终让我下决心的并不是价格。我本来就在另一个窗口里用模型起草帖子，然后手动粘贴进排期工具。两个工具其实在做同一条显而易见的流水线。当我看清自己想要的工作流之后，为了让撰稿和发布继续分成两半而付订阅费，对我来说就说不通了。
我的工作流做了什么
我的工作流刻意做得很无聊。Schedule Trigger 每天触发几次，从我的 Google Sheet 读取下一条已批准的行，为每个平台改写文案，把每个版本送进各自的发布分支，然后记录结果。人工审批状态放在表格里，我只发布自己批准过的行。失败的分支会在 n8n 之外触发告警，这样失效的凭据就不会淹没在执行日志里。
起草步骤调用的是托管模型的 API。我短暂考虑过在同一台机器上跑模型，但在每月几十条帖子的量级下， 自托管模型的成本因素 要高于我的 API 账单。用量、隐私或延迟都可能改变这个判断，但我没有理由只为了改写社交文案就多运维一套基础设施。这个工作流并不聪明，而这正是我信任它的部分原因。
逐个平台的真实情况（问题出在 Instagram）
我的四条分支里有三条基本波澜不惊。只有 Instagram 吃掉的时间比项目其余部分加起来还多，也是漏发帖子后我最难视而不见的平台。下表列出我用过或评估过的路径，表下的细节才是真正影响我这套配置的部分。
| 平台 | n8n 路径 | 主要限制 | 结论 |
|---|---|---|---|
| X | 内置 X 节点 | 端点限额取决于 X 的开发者方案 | 有 API 权限即可用 |
| 内置 LinkedIn 节点 | 以组织身份发布需通过 LinkedIn 应用审核 | 审核通过后可用 | |
| Facebook Graph API 节点 | 主页权限、令牌与 Graph API 版本 | 配置好即可用 | |
| Meta Graph API | 专业账号、媒体规则、配额、令牌生命周期 | 需要持续维护才能用 | |
| TikTok | 目录中没有内置应用节点 | 需要 HTTP、自定义或社区集成 | 若非有不可，就用排期工具 |
在 LinkedIn 这边， LinkedIn 节点文档 涵盖了以个人和组织身份发布内容，而 n8n 的 LinkedIn 凭据指南 则说明，以组织身份发布意味着要让你的应用走一遍 LinkedIn 的 Community Management App Review。这已经满足我的需求。 X 凭据文档 写明 X 会按开发者访问方案的等级，对每个端点施加基于时间的速率限制。以我的发布量还没碰到上限，但我依然把它当作 X 随时可以调整的限制，而不是 n8n 给出的承诺。
Meta 的内容发布指南 写明 JPEG 是唯一受支持的图片格式，并且在所述路径下，滚动的 24 小时窗口内通过 API 发布的帖子上限为 100 条。JPEG 这条规则害我搭进去一个晚上，因为我的导出默认是 PNG，而这个失败在 n8n 里并不明显。我把这个发布上限视为绑定当前 API 路径和版本的数字，而不是永久不变的。
四个月里坏了两次，两次都是 Instagram。长期访问令牌并非永久有效， Meta 的令牌刷新参考文档 写明令牌只有在尚未过期且已存在至少 24 小时的情况下才能刷新。错过这个窗口，刷新就不再是恢复手段。我的错误在于把认证当成一次性的搭建工作，而不是持续的运维。发布类工作流需要过期监控、提前刷新，以及续期失败时的告警。
TikTok 根本就不在我这次替换的范围内。 内置应用节点目录 里没有它。我本可以用 HTTP Request 节点、自定义节点或社区节点，但那样我就要承担更多凭据管理和故障。我是在替换一个排期工具，而不是主动接下再维护一个平台集成的活。
把我的时间也算进去的成本账
我以四个频道的 Buffer Essentials 作为基准。下表中公布的价格均为按年付费，并已于 2026 年 8 月核实。美元和欧元金额我按各自公布的币种原样保留，没有假装它们可以直接划等号。
| 选项 | 公布的月费 | 包含什么 | 你要自己运维什么 |
|---|---|---|---|
| Buffer Essentials，4 个频道 | $20, billed yearly | 排期界面与不限量的定时发布 | 无需基础设施 |
| n8n Cloud Starter | 20 €，按年付费 | 2,500 次工作流执行 | 工作流与凭据 |
| n8n Cloud Pro | 50 €，按年付费 | 10,000 次工作流执行 | 工作流与凭据 |
| n8n Community Edition | 软件免费 | 自托管的工作流引擎 | 服务器、更新、数据、备份、监控 |
n8n 的云端定价 把 Starter 放在了跟我那四个 Buffer Essentials 频道差不多的入门价位。这就让托管方案在我的场景里出局了：我要为一个工作流引擎付差不多的月费，还得丢掉更好用的发布界面。 Community Edition 的对比说明 确认了我可以在不付软件费用的前提下继续用基础的自托管版本，但这并没有让服务器和我的时间变成免费。
我也不会把自己这台机器的规格拔高成 4 GB 内存、2 vCPU 的通用生产环境下限。 n8n 的部署先决条件 给出的是一个相当宽的资源区间。我的负载很小，但换一套配置，情况可能因并发执行、媒体载荷、代码步骤、数据库压力和更长的执行历史而迅速改变。诚实的答案是：从实际负载出发，盯住内存和 CPU。
SQLite 是 n8n 的默认数据库 ，对于单实例、低流量的部署完全够用。不过一旦执行历史开始重要，或者预计部署规模会增长，我还是更倾向 PostgreSQL。分布式的 队列模式部署 同样需要它，因为 n8n 不支持在 SQLite 上跑这种架构。与其等工作流变重要之后再迁移数据库，我宁愿在搭建阶段就把这个决定做掉。
贵的从来不是 VPS，而是我的那个周末。之后又搭进去一个被 JPEG 毁掉的晚上、几次令牌故障，以及反复确认帖子到底有没有发出去。只要我给自己的工时定个价，省下来的钱就会迅速缩水，甚至变成负数。这正是 自托管不再便宜的分界点。我仍然认为这次切换值得，但在第一周我可说不出这句话。
出了什么问题，我又改了什么
两次能看见的故障都是 Instagram 令牌失效，但更深层的问题是沉默。订阅制排期工具有一套专门用来暴露账号问题的产品界面。而我最初的工作流可以在 n8n 内部失败，外部呈现出来的症状只是那天没有发帖。这让我明白：自托管的发布系统必须大声失败，并且在恢复时不产生重复。
- 我把失败告警发到 n8n 之外的一个频道，并附上平台返回的响应和工作流执行 ID，这样就不必依赖同一个系统来告诉我它已经坏了。
- 我会跟踪令牌的过期时间和应用审核状态，并且足够早地测试续期，好在某条定时发布变成第一声警报之前完成重新授权。
- 我会在发布前记录一个唯一的内容 ID，这样失败的平台分支可以重试，而不会往已经成功的分支上重复发一遍。
- 我会备份 n8n 的数据卷和数据库，并把恢复演练当成备份的一部分，而不是想当然地认为拷贝出来的文件就能救我。
- 在服务商允许的地方我会锁定 API 版本，会看更新日志，并在 n8n 或服务商侧发生变动后逐条测试每个平台分支。
- 我会按自己真正需要的保留期清理执行历史和媒体文件，因为社交素材能把一个很小的自动化变成一份不必要的大备份。
我不会把这套东西跑在家里的机器上。定在上午 9 点的帖子，要求工作流在 9 点必须活着，而居民电力、网络连通性、NAT 和入站回调，都会往内容日历里塞进我不想要的变量。VPS 消除了这些家庭网络变量，但没有消除我在 TLS、备份、监控、更新和恢复上的责任。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐哪些人不该这么折腾
如果你要的就是一个排期工具，那就留在付费排期工具上。这不是安慰奖。如果日历、预览、简单审批、广泛的渠道覆盖和极低的维护量，对你来说值这笔订阅费，那么买下它就是正确决定。在不需要定制自动化的前提下，把那套界面换成工作流画布，只是多绕几步的倒退。
如果你想要一个形态像 Buffer、但归自己所有的产品，我会先看看 Postiz Postiz，再考虑 n8n。它的开源版本可以跑在你自己的服务器上，支持的三十多个渠道里也包含 TikTok。它是一个发布日历而不是工作流画布，所以对很多离开付费排期工具的人来说，是更自然的落脚点。
我会再来一次，唯一的理由是我想把调研、撰稿、审批、发布和日志都放进同一条流水线。这就是我接受的交换：不是免费的排期，而是用注意力换来的掌控权。如果我需要的只是排期，我会回去订阅。
如果你想走同样的自托管路线， 我们的一键 n8n 部署 可以省掉最初的服务器安装步骤。但它省不掉我认为更重要的那部分工作：工作流凭据、平台审核、更新、备份、监控，以及失败发布的补救。
常见问题
Buffer 上的授权能沿用到 n8n 吗？
不能。我此前授权给 Buffer 的平台连接，属于 Buffer 自己的应用和授权流程。我的 n8n 工作流需要自己的凭据、令牌、权限范围，以及该账号或发布路径所要求的任何平台审核。
每个社交平台都该有自己的分支吗？
多数情况下该分。我用独立分支，是为了能按平台分别调整文案、媒体、凭据和错误处理。这样一来，Instagram 请求失败后可以单独重试，而不会把已经在 X 或 LinkedIn 发成功的内容再发一遍。
一个 n8n 工作流能同时服务多个客户吗？
可以，但我会按客户隔离凭据、内容来源、审批状态和日志。平台的权限和配额仍然是绑在对应的应用和账号上的，所以一次成功的连接绝不能当成通用访问权。
工作流该如何补上漏发的帖子？
我会查询那些已批准、且计划时间已过的帖子，然后只发布尚无成功结果的记录。唯一内容 ID 加上保存下来的平台响应，可以确保重启或重试不会把已经发出去的帖子再发一遍。
