Simon Høiberg · 14:59 · 发布 2026-06-29 · 1.6万次观看(截至抓取) · 观看原视频
主旨
视频讲述作者如何把自己的 SaaS 产品组合从 AWS 迁移到自托管的裸金属服务器,并逐层拆解了计算编排、数据库、文件存储、公网入口安全这四层基础设施的具体选型与取舍。
核心论点
- 用 Kubernetes(K3s)+ Docker + Helm 把多个 SaaS 产品统一成标准化的自动化部署流程,复制了托管平台的部署体验,但跑在自己固定成本的服务器上。(→ 详解1)
- 关系型数据库(Postgres)比早期选的 DynamoDB 更贴合 SaaS 的实际数据结构,配合 CloudNativePG 这个 Kubernetes operator,备份、故障转移都收敛成几行配置。(→ 详解2)
- MinIO 能胜任 S3 兼容的自托管文件存储,但其社区版已进入维护模式,是一个值得警惕的信号,不适合存放敏感或不可替代的客户数据。(→ 详解3)
- 用一台廉价 VPS 做公网边缘节点、通过 WireGuard 隧道连回私有基础设施,能实现”源站隔离”——真实服务器不直接暴露在公网上,同时不必依赖 Cloudflare 这类托管层。(→ 详解4)
- AI agent 的只读诊断能力大幅降低了自托管的学习门槛,过去靠翻文档、蹲论坛才能排查的问题,现在能被 agent 快速定位根因。(→ 详解5)
知识点详解
1. 三服务器 + K3s + Helm 的标准化部署 01:08
作者的整套基础设施跑在三台 Hetzner 服务器上——一台主力专用服务器加两台更便宜的竞拍服务器分担负载。在这三台机器之上运行的是 K3s,一个轻量版的 Kubernetes 发行版。每个服务(应用、API、后台 worker)都被打包成独立的 Docker 镜像,而不是在服务器上直接装 Node、Postgres 客户端这些零散工具和脚本。
部署流程完全自动化:代码推送到自建的 Git 服务后,流水线构建新镜像、推到镜像仓库,再由 Helm 自动化部署 通知 Kubernetes 滚动发布——启动新容器、等待健康检查通过,才下线旧容器。这套”推代码→建镜像→滚动发布→健康检查→切换”的体验和托管平台一样顺滑,区别只是跑在自己的固定成本服务器上。
作者特别澄清:用 Kubernetes 不是因为业务需要超大规模,而是因为他同时运营多个产品,想让它们都用同一套标准化方式部署,避免每个产品各自搞一套临时脚本和补丁。
2. 从 DynamoDB 到 Postgres:数据库选型的教训 04:36
作者最早出于”看起来很酷”选了 DynamoDB,还研究了单表设计这类专属模式,但事后承认这是个错误决策——他实际上是把 DynamoDB 当成关系型数据库在用,却要为按次计费的读写付出额外的心智负担,复杂度很高但收益很小。
后来他把几乎所有东西迁回 PostgreSQL。Postgres 成熟、生态支持好,而且天然贴合大多数 SaaS 的数据结构(用户属于工作区、工作区有订阅)。在他的集群里,Postgres 通过 CloudNativePG 运行——这是一个 Kubernetes operator,把数据库的运维细节(故障转移、备份、恢复)收敛成声明式配置,备份策略基本就是”告诉它存哪里、多久备一次、保留多久”这几行配置。
除 Postgres 外,他还用 Redis 做缓存和队列类工作负载,以及 pgvector 这个 Postgres 扩展做 RAG 和向量搜索,认为它足够快、没必要单独引入专门的向量数据库。
3. MinIO 做文件存储,但社区版是个黄色警示 06:47
产品数据放数据库,文件类的东西(用户上传的图片视频、导出文件、生成资产)则走对象存储。作者用的是 MinIO,一个 S3 兼容、可以自建在自己基础设施里的对象存储,产品代码可以用跟 AWS S3 几乎一样的方式跟它对接。
但作者明确提醒:MinIO 曾经是自托管对象存储的默认选择,现在处境变差了——开源仓库被官方标记为维护模式,不再接受新功能和新 PR,安全修复只是”个案评估”,仓库本身也被归档为只读,而官方精力被推向企业版产品 AI Store。他把这称为”黄色警示”,不是软件突然变差,而是产品方向的信号。
对他自己的场景(社交媒体图片视频这类”重要但非敏感”的资产)他认为现在还能接受;但如果存的是法律文件、医疗记录、财务数据这类真正关键的客户数据,他建议改用托管服务商,或至少在加密、复制、访问控制上投入更多精力。
4. 公网边缘 VPS + WireGuard:源站隔离而非依赖 Cloudflare 09:51/10:31
自托管产品必须有东西暴露在公网上接收用户请求和 webhook,但真实的服务器不必完全裸露。作者过去用 CloudFront 挡在前面,现在换成一台廉价 VPS 作为公网入口,由它把流量转发给背后的真实基础设施。
实现方式有两级:简单版是 IP 白名单,集群只接受来自这台 VPS 的流量;更好的版本是 WireGuard 隧道,公网 VPS 通过加密隧道连接到私有基础设施,真实的 ingress 只监听这条私有连接,VPS 本身没有任何开放的入站连接,可以随时替换而不动背后的基础设施。作者把这套模式的核心称为 源站隔离(Origin Isolation)——真实服务器不裸露在公网上,公网边缘节点廉价、无状态、可随时丢弃。
他也坦承这不能防真正的 DoS 攻击,如果需要更强的防护,Cloudflare 是最简单的”认真版”公网边缘选择,Tailscale 则是最简单的私有网络方案——但两者都意味着新增一层对第三方控制面的依赖,不是”完全 cloudless”。这是一个权衡而非非黑即白的选择。
5. AI 把自托管的学习曲线拉平了 12:38
作者承认过去自托管很痛苦:出问题就得翻文档、刷 GitHub issue、蹲论坛帖子,照抄一条自己都看不懂的命令。他认为这种恐惧正在过时,因为 AI 在基础设施排查上已经非常擅长——尤其是当你给它对系统的真实访问权限时。
他建议给 agent 只读权限去查看 Kubernetes 集群的日志和监控,agent 能在几秒内查看 pod、事件、ingress、Helm values 和指标,常常能在你打开终端之前就指出问题所在:pod 崩溃能解释日志、流量不通能追溯路径、备份失败能定位到具体哪一行配置有问题。
他的结论是:基础设施不再是创始人学不会的”那一个特例”,而是和广告、销售、SEO 一样,都是创业者本该掌握的技能之一。如果一切关键层面都跑在别人的托管平台上,你的业务本质上被那些公司拥有——你真正拥有的可能只是一个品牌名而已。
可执行步骤
- 盘点自己的 SaaS/产品线目前依赖了哪几层托管服务(计算、数据库、文件存储、CDN/边缘),逐层列出退出成本。
- 若已在用关系型数据结构却选了 NoSQL,评估迁回 Postgres 之类关系型数据库的收益。
- 给 AI agent 开一个只读权限,连到自己现有服务器/集群的日志和监控,试着让它帮你排查一次真实故障。
- 如果文件存储涉及敏感或不可替代的客户数据,先确认当前方案(尤其 MinIO 社区版)的维护状态是否可接受。
关联
- 印证:VPS 自托管 的”用按月租的云服务器替代托管平台,换取更低成本与更强控制权”逻辑,在本视频里延伸到公网边缘节点这个更细的角色——VPS 不再是承载核心应用,而是作为可随时丢弃的”源站隔离”边缘。
- 印证:数据主权 提出”在自有域名上自主决定内容排布、不受平台裁剪”的掌控权主张,本视频把同一逻辑从内容层延伸到基础设施层——若计算、数据库、存储都托管在他人平台,创始人真正拥有的可能只剩品牌名。
- 复现:数据科学家转型AI工程师路线图 把 pgvector 列为 AI 应用生产后端里 Postgres 的向量检索扩展,是本片”自托管盒子管数据库”栈里 Postgres 用于向量场景的具体延伸。
术语
- K3s(轻量版 Kubernetes 发行版,适合中小规模自托管集群)
- Helm(Kubernetes 的包管理与发布工具,本视频用来驱动滚动发布)
- CloudNativePG(Postgres 的 Kubernetes operator,把数据库运维收敛为声明式配置)
- MinIO(S3 兼容的自托管对象存储)
- pgvector(Postgres 的向量搜索扩展,替代独立向量数据库)
- WireGuard(轻量级 VPN 协议,用于搭建加密隧道)
- Origin Isolation(源站隔离:真实服务器不直接暴露公网,只经边缘节点转发流量)
立场与利益
作者本人经营多款 SaaS 产品(视频中提到的 Feedhive 即其一),内容基于他自己实际运营的基础设施决策,不是在推销某个课程或工具。视频里提到的 Hetzner、K3s、CloudNativePG、MinIO、WireGuard、Cloudflare、Tailscale 均为第三方开源/商业工具,视频未展示具体联盟或推广链接,但反复推荐 Hetzner 作为服务器供应商这一点,读者可留意其是否存在推广关系(本篇原料未见明确联盟标注)。
价值定位
适合已经运营 SaaS 产品、对云账单或平台锁定感到困扰、想了解”自托管一整套基础设施长什么样”的技术型创始人,尤其是同时运营多个产品、需要标准化部署方式的人。
视频给出的是一套完整的架构全景(计算编排、数据库、文件存储、公网安全四层各自的工具选型与取舍理由),但不包含具体的部署命令、YAML 配置或分步教程,拿来即用的实操价值有限,更多是帮助判断”自托管值不值得、该选哪类工具”的认知层面参考。
自检问题
- 作者为什么选择 Kubernetes(K3s)而不是更简单的单 VPS + Docker Compose 方案? 答案:不是因为业务需要超大规模,而是因为他同时运营多个 SaaS 产品,想让它们都用同一套标准化的部署方式,避免每个产品各搞一套临时脚本。见「详解1」。01:08
- CloudNativePG 在这套架构里解决了什么问题? 答案:作为 Postgres 的 Kubernetes operator,把数据库的故障转移、备份、恢复这些运维细节收敛成声明式配置,备份策略只需几行配置(存哪里、多久备一次、保留多久)。见「详解2」。05:07
- 作者为什么把 MinIO 的社区版称为”黄色警示”? 答案:MinIO 开源仓库已被官方标记为维护模式,不再接受新功能和新 PR,安全修复只做个案评估,仓库也被归档为只读,官方精力转向企业版 AI Store。见「详解3」。08:28
- “源站隔离(Origin Isolation)“具体是怎么实现的,它能防住什么、防不住什么? 答案:用一台廉价公网 VPS 作为边缘节点,通过 WireGuard 隧道连回私有基础设施,真实服务器的 ingress 只监听这条私有连接、没有任何公网入站连接。它能让真实服务器不裸露在公网、可随时替换边缘节点,但防不住真正的大规模 DoS 攻击,那仍需专门的 DoS 防护。见「详解4」。10:31
- 为什么作者认为”基础设施能力”在 2026 年对创始人变得比以前更可及? 答案:因为 AI agent 只需只读访问权限就能快速查看集群日志、事件、监控并定位问题根因,把过去”翻文档、蹲论坛”式的痛苦排查变成边做边学,大幅拉平了学习曲线。见「详解5」。12:38
💬 热门评论 top-14 主 + 6 回(抓取 2026-07-07)
[2] @zdrux:作为一个大型企业的 Kubernetes/Openshift 运维人员，你的设置正是我如果 SaaS 栈里有超过 2-3 个组件时会搭建的（你很快就达到了那个数量）。人们以为安装 K8s 是为了某些疯狂的功能列表……但实际上是为了它的模块化和长期扩展潜力，这让以后的事情变得 SOOOOO 容易，无论你选择哪个技术栈方向。它需要 1-2 天的设置，但换来的是多年的无痛编排、弹性、备份以及你提到的所有其他好处。 👍 33 ↪ @SimonHoiberg(UP):这个 👏 👍 4 ↪ @philippezevenberg1332:兄弟，我刚刚在一家大型制药公司搭建了 ML 平台，kubes rancher helm 救了我 😭🙏 👍 1 [3] @ThePlodger:我决定走这条路已经有一段时间了，从未后悔。我更喜欢 xcp-ng——它非常稳定可靠，能很好地管理多个集群，同时既有高级控制平面，也有更适合自建的低级访问。在一台机器上运行几十个虚拟机完全可行，而且非常稳定。我在这上面运行过 Kubernetes，效果不错，但我不是特别喜欢。虽然我很喜欢 Kubernetes 管理计算的方式，但我不太喜欢它处理共享存储和其他共享资源的方式。我觉得有点奇怪。 👍 4 [6] @FractureCLinic47:非常有趣，很多人可以从这种方法中学到东西。没有评判，但好奇为什么选 K3S 而不是 Talos？也就是说，你是否考虑过这两个选项？ 👍 1 [8] @LiviuCMunteanu:嘿 Simon！好视频！我不确定我是否错过了，但有成本分解吗？如果没有，也许你可以做一个关于你使用的规格和成本的视频。另外，你用什么做认证？是自己管理 IdP 还是用 aaS？ 👍 3 ↪ @_romeopeter:没有成本分解，但即使没有，我也可以告诉你云解决方案的方向会贵得多。 [9] @tananga_studio:在 1:59 你说的“helm 告诉 kubernetes 部署新版本”是什么意思？我用 ArgoCD 来做。你那边是怎么工作的？ 👍 1 [10] @dustsucker4704:Minio 不错，但我缺少一些工具。我会推荐 Garage。除此之外 100% 👍 1 [12] @Fledermaus-20:首先，好视频，我不确定这是否与你的用例相关，但既然你提到了 MinIO 的问题，RustFS 可能值得评估作为替代方案。它是一个兼容 S3 的对象存储系统，在我的用例中，它覆盖了与 MinIO 相同的核心需求，同时使用了更宽松的 Apache 2.0 许可证。 [13] @mikeeomega:好视频，Simon。非常有趣的架构决策，我之前不知道 k3s 以及 Minio 处于维护模式的事实。🤔 👍 2 ↪ @SimonHoiberg(UP):太棒了！很高兴你觉得有趣 🙌 ——其他 5 条:感谢/夸赞([4]@RuddyOrtizCom、[5]@AlfredNutile、[7]@jeremydudet、[11]@dragongoswami、[14]@sownaby3935);1 条 spam 已略
英文原文
[1] @SimonHoiberg(UP):Hope you enjoyed watching! I put together all resources here: https://simonl.ink/infra Get get yourself set up 💪 👍 8
[2] @zdrux:As a Kubernetes/Openshift operator for a large Enterprise, your setup is exactly what I would build if I had more than 2-3 components in a SaaS stack (you hit that number very quickly). People think K8s is installed for some crazy list of features.. but it's actually installed for its modularity and long-term scaling potential which makes things SOOOOO much easier down the road no matter which direction you take your tech stack. It is 1-2 days of setup, but years of headache-free orchestration, resiliency, backup, and everything else you mentioned. 👍 33
↪ @SimonHoiberg(UP):This 👏 👍 4
↪ @philippezevenberg1332:Bro I just built the ML plateform at a big pharma and kubes rancher helm saved me 😭🙏 👍 1
[3] @ThePlodger:I decided to go this route some time ago and have not regretted it. My preference is for xcp-ng -- it's very solid and reliable and handles multiple clusters well, whilst also having both a high-level control plane and low level access that's more suited to rolling-your-own. Running dozens of VMs on a single box definitely works and is rock solid. I have run Kubernetes on top of this, and it works fine, but I'm not a huge fan. Though I quite like the way Kubernetes manages compute, I'm less keen on the way it handles shared storage and other shared resources. I find it weird. 👍 4
[4] @RuddyOrtizCom:Being a Sales & Marketing guy, this is probably the most exciting, nerdiest video I've watched in a while! 🤣. THANK YOU for breaking down your setup. I'm actually looking fwd to setting up something like this for my stack. 👍 3
↪ @SimonHoiberg(UP):Appreciate it, glad you liked it 😁
[5] @AlfredNutile:Great call on Wireguard
[6] @FractureCLinic47:Really interesting, approach a lot of people could learn from. No judgement, but interested in why K3S over Talos? That is if you considered both options? 👍 1
[7] @jeremydudet:great stuff, simon
[8] @LiviuCMunteanu:Hey Simon! Great video! I'm not sure if I missed it but was there a cost breakdown? If not, maybe you could make a video about specs and costs for what you are using. Also, what are you using for authentication? Are you managing your IdP or leverage aaS? 👍 3
↪ @_romeopeter:There wasn’t a cost breakdown, but even without, I can get you the cloud solution direction would cost way more.
[9] @tananga_studio:In 1:59 what do you mean by "helm tells kubernetes to deploy new version". Im using ArgoCD for it. How it works in your case? 👍 1
[10] @dustsucker4704:Minio ist fine, but I miss some tools. I would recommend Garage. Other than that 100% 👍 1
[11] @dragongoswami:Make a full indepth video on this 👍 5
[12] @Fledermaus-20:First of all, great Video, I’m not sure whether this is relevant to your use case, but since you mentioned the MinIO issue, RustFS might be worth evaluating as an alternative. It’s an S3-compatible object storage system and, in my use cases, it covered the same core requirements as MinIO while using the more permissive Apache 2.0 license.
[13] @mikeeomega:Great video, Simon. Super interesting infrastructure decisions, and I didn't know about k3s or the fact that Minio is in maintenance mode. 🤔 👍 2
↪ @SimonHoiberg(UP):Awesome! Glad you found it interesting 🙌
[14] @sownaby3935:this is a Mio$ content! thank you for sharing! 💛
↪ @SimonHoiberg(UP):I'm glad you enjoyed it! 😁