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 以后通过独立服务、子域名或反向代理接入。
这个选择不酷,但适合长期维护。对这个站点来说,稳定、可恢复、边界清楚,比一开始就做复杂系统更重要。
回复 / 留言