iotlabx 第一版没有选动态博客或 CMS,而是把公开站点做成静态 Hugo 页面。

原因很直接:这台 Raspberry Pi 还要跑私有自动化和实验服务,公开博客不能成为系统里最重、最容易出问题的部分。

当前分工:

protocol trace
Hugo                 生成静态页面
Nginx                提供 /var/www/iotlabx 下的公开站点
Cloudflare Tunnel    暴露公网域名,避免直接开放入口
OpenClaw             私有自动化环境,独立于公开站点

这套方案牺牲了一些动态能力,但换来几个确定收益:

  • 静态页面资源占用低;
  • 构建产物容易备份和回滚;
  • Nginx 长时间运行稳定;
  • 公开站点与私有工具边界清楚;
  • Raspberry Pi 的 CPU 和内存留给更重要的本地任务。

发布闭环保持简单:

protocol trace
写 Markdown
运行 Hugo 构建
同步 public/ 到 /var/www/iotlabx
由 Nginx 对外提供静态文件

动态能力不放进 Hugo 本体。IoT 状态页、Office UI、实验 Demo 以后通过独立服务、子域名或反向代理接入。

这个选择不酷,但适合长期维护。对这个站点来说,稳定、可恢复、边界清楚,比一开始就做复杂系统更重要。