速评：那篇自托管 n8n 的教程拿 gem，我认。
9 月 25 日发在 dev.to 上，作者挂着 AWS Community Builders 的身份，配了 GitHub 仓库，六条置顶评论。事情本身不复杂：他按 n8n 的 AWS 自托管文档在 Amazon Linux 2023 的 EC2 上走，Docker 装完，执行 docker compose up -d，docker 回他一句 compose 不是它的子命令。
Compose 早就不发独立二进制了，改成了 CLI 插件，而 dnf 那条路只装引擎不装插件。docker run 照常能用，断的只有这一条。他修得也利落：往插件目录手工放一个 Compose v2.29.7 的二进制，给执行权限，重启，收工。
gem 我认。但这个坑的成因值得多嚼一句——它不是 AWS 特殊，是写这类教程的人几乎都在 Ubuntu 或者随手一台 VPS 上把命令跑通了才发出去，而 Ubuntu 上装 docker.io 加 compose 插件根本不会撞上这事。换个发行版，同样的命令，不同的结果。说这是 AWS 的坑，不如说是教程写手的宿主环境偏见，这回刚好撞在 AL2023 上。
然后我看到了更该被截图的那句。
作者写了：新 n8n 实例上第一个创建的账户就是 owner，所以设置向导里那个账户要马上建。他还写了安全组的事——首次私有测试，5678 只对自己的 IP 开放，绝不能开给 0.0.0.0/0，不然公网上谁都能抢先占了你的编辑器。他知道自己在写什么。
n8n 是什么东西，这行的人不用我解释。它是凭据聚合器，一个实例里同时躺着 Stripe 密钥、数据库密码、Slack token、Google OAuth。抢注一个博客，换台机器重来就完了，这不是那种东西。谁先在你那台机器上点完设置向导，谁就拿到保险箱的第一把钥匙，连带着里面连出去的所有东西。这是身份问题，不是数据问题。
问题不在他写没写，在他写在哪儿。这几句落在正文偏后的位置，和 TLS、Caddy、Secrets Manager、最小权限 IAM 挤在同一张"上线前加固清单"里。"上线前"三个字是带催眠的，读到它的人会自动翻译成"以后有空再弄"。把致命的东西排进"上线前"清单，等于告诉所有人可以以后再弄。
而一台 n8n 开始暴露的时间，不是从"上线"那一刻算的，是从 docker compose up -d 跑通那一秒算的。作者连规格都替读者挑了——t3.small 起，n8n 加 Postgres 大概要两个 G 内存，t2.micro、t3.micro 会被 OOM 杀掉。这种地方他细得很，可顺序还是那个顺序。
要说这不公平，也有一点。他管不了读者怎么读。该列的列了，镜像也没图省事写 latest，钉死在 1.123.64，为的是一个凭据以自定义标头形式传进 LLM 子节点时会漏进执行记录的漏洞。这个细节其实最说明问题——你搭的那个所谓自动化工作流工具，日常动作就是把各种 token 递给模型。它天生是个装密钥的盒子。
我去翻了留言。摆在上面的两条，一条问能不能直接 dnf 装 compose 插件，一条建议用 get.docker.com 的脚本顺手把插件带上。作者回得都实在：那个包不在 Amazon 仓库里，走 CE 那条路等于把 AL2023 自带的 docker 换掉，AWS 不支持这么干，所以他宁可手工放一个二进制。两条都在聊怎么把 compose 装上。六条置顶我没翻完，但摆出来的重心在这儿。"第一个账户就是 owner"那句，没人接。
说到这个有点尴尬，这类教程文我上个月还说过不值得逐条看，今天自己倒好，评论区都翻了一遍。嘴上一套，手上一套。
还有个更没劲的原因。填坑类的文章好打分，有 before 有 after，命令贴出来谁都能验一遍，gem 给得理直气壮。而"哪一步必须排在最前面"这种判断，没有 before 也没有 after，做对了什么都不会发生。所以前者一遍遍拿 gem，一遍遍被收藏；后者就挂在正文里，等人跳过。
作者预告了续集，一篇讲加固，关掉编辑器端口、前置 TLS、密钥进 Secrets Manager；再一篇讲把同一个 n8n 接到 Bedrock，模型跑在自己账户里。立个 flag：这两篇发出来之后，被转得最多的还是某段能直接粘的配置，而不是"先把 5678 关掉"。我赌还会有一批人照做完、跑起来、在裸 IP 上把 owner 账户建了，然后就这么放着——直到某天早上，发现自己的 Slack token 在别的地方说话。