1. 项目概述为什么要自己部署一个到期提醒工具先聊点实实在在的。玩 NAS 的人尤其是用飞牛 fnOS 当主力系统的朋友大概率都遇到过这种尴尬域名续费忘了网站打不开了SSL 证书到期忘了浏览器直接提示不安全某网盘的会员到期忘了下载速度瞬间打回原形甚至连家里宽带合约到期这种事都容易拖到被自动扣费才想起来。我自己就踩过不止一次坑。最惨的一次是域名到期没收到提醒等我发现的时候域名已经被别人抢注了。从那之后我开始认真找到期提醒工具对比了一圈有在线 SaaS 服务免费额度卡得死死的还担心隐私问题有浏览器插件换了设备就彻底失联有手机 App倒是能用但数据都在别人服务器上总归不踏实。后来想明白了既然是 NAS 用户最该用的就是自托管方案——数据全在自己手里提醒规则随便配想接什么通知渠道就接什么一劳永逸。这时候就轮到 RenewHelper 出场了。它就是一个典型的自托管到期提醒服务通过 Docker 部署在飞牛 NAS 上之后可以统一管理域名、SSL 证书、各类订阅服务、甚至任何自定义的到期事项到时间了自动通过飞书、钉钉、微信等渠道推送通知。简单说它把人工记日子变成系统盯日子你在飞牛上装好它剩下的事就不用操心了。这篇博文我会把整个部署过程拆开揉碎了讲从飞牛系统的环境准备开始到 Docker 部署的具体步骤、配置文件的每个参数含义、通知渠道怎么接、再到实际操作中容易踩的坑。整个过程我自己在飞牛 fnOS 上完整跑过一遍写下来的都是实测过的方案不是纸上谈兵。新手照着做能顺利跑起来老手也可以从我踩过的坑里省点时间。2. 方案选型为什么选择 Docker 部署在飞牛 NAS 上2.1 飞牛 fnOS 凭什么适合跑这类服务飞牛 fnOS 在 NAS 系统里算是个后来者但它有几个我很认可的设计。首先是它的应用中心自带 Docker 管理界面不需要像群晖那样去套件中心找 Docker 包也不用像某些系统那样得用命令行才能折腾容器。飞牛把 Docker 的常用操作都图形化了这对想自己部署服务又不想整天敲命令的用户非常友好。其次是飞牛基于 Debian 底层兼容性很好。绝大多数 Linux 上能跑的 Docker 镜像拿到飞牛上基本都能直接跑。RenewHelper 这类轻量级工具对硬件要求很低哪怕是玩客云刷机改造的入门级 NAS 也能轻松扛住内存占用通常不到 256MB几乎可以忽略不计。还有一个现实原因NAS 本身就是 7x24 小时开机的设备。到期提醒工具的价值在于准时如果跑在一台每天关机八小时的电脑上提醒自然就失效了。而 NAS 就是家里少数几台全年无休的机器之一把这类定时任务塞给 NAS 是最顺理成章的选择。2.2 自托管方案对比在线服务的优势我在选型的时候其实犹豫过一阵子到底是用在线服务还是自己部署。后来列了个对比表很快就有了结论对比维度在线SaaS服务自托管方案RenewHelper数据存储第三方服务器自己的NAS硬盘免费额度通常有限制无限制自定义程度只能按平台规则来完全自定义通知渠道平台预置的几种随意扩展Webhook隐私安全依赖平台信誉数据不出家门单点故障平台挂了全挂自己NAS挂了才挂说白了在线服务适合懒得折腾的人但如果你已经玩了 NAS骨子里就是数据必须在自己手里那一派的自托管几乎是必然选择。RenewHelper 这类工具的存在意义就是让自己管数据自动提醒这两个需求同时被满足。还有一个隐藏优势是学习成本。部署一次 RenewHelper你会顺带学会 Docker 的基本操作、端口映射的理解、环境变量的配置、Webhook 通知的原理。这些技能在 NAS 玩家圈子里几乎人手必备属于一次学会终身受用的基础能力。哪怕以后不玩飞牛了换成其他 NAS 系统这套知识照样用得上。3. 部署前准备飞牛系统需要提前搞定的三件事3.1 确认 Docker 环境正常飞牛 fnOS 的 Docker 功能已经集成在系统里了但不同版本的飞牛对 Docker 的封装程度不一样。新版本通常自带 Docker 管理界面老一点的版本可能需要在应用中心手动安装 Docker 应用。我建议动手前先确认一下打开飞牛的应用中心看有没有 Docker 相关的应用如果有点进去确认状态是运行中。如果找不到 Docker 应用多半是系统版本比较旧先去系统设置里检查更新。这一步不花两分钟但能避免后面一长串莫名其妙的问题。另外建议顺手确认一下 Docker 版本不要太老。RenewHelper 依赖 Docker Compose 的能力虽然也可以直接用 docker run 一条命令跑起来但用 Compose 管理配置更规范后面改参数也方便。飞牛系统的 Docker 版本一般都在 20.10 以上满足需求没问题但如果你之前手动折腾过 Docker 环境最好用docker --version命令行确认一下版本号。3.2 规划部署目录和端口部署目录是个容易被新手忽略、但实际影响很大的事情。飞牛的磁盘挂载路径一般形如/vol1、/vol2应用数据建议统一放在一个专门目录里。我自己的习惯是在/vol1/docker下按应用名建子目录比如/vol1/docker/renewhelper里面再分config和data两个目录分别存放配置文件和数据库文件。这样做的好处很实际。一来备份方便打包整个 renewhelper 目录就能完整迁移二来升级容器时不容易弄丢数据三来万一容器出问题需要重建配置和数据都还在不至于从头来过。端口规划也要提前想好。RenewHelper 默认跑在 80 端口但 NAS 上 80 端口通常已经被其他服务占了所以建议映射到 8300 或 9123 这类不常用的端口。我实际用的是 8300顺便在飞牛的防火墙规则里放行了这个端口。注意如果飞牛开了防火墙但没放行对应端口界面会一直打不开这个问题排查起来挺容易让人抓狂的。3.3 准备通知渠道的 WebhookRenewHelper 的提醒能力完全依赖 Webhook也就是让第三方平台往群里推送消息。这一步在部署之前就应该准备好因为配置完 RenewHelper 之后第一件事就是测通知。目前用得比较多的是飞书群机器人、钉钉群机器人和企业微信机器人。以飞书为例在群里添加一个自定义机器人会得到一个 Webhook 地址形如https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx。这个地址后面要填到 RenewHelper 的配置里所以提前复制保存好。如果手头没有任何 IM 工具也可以用通用的 Webhook 服务比如 Server 酱、PushPlus 之类。这些服务会把消息推送到微信或手机 App。我的建议是优先用飞书或钉钉群机器人因为这类群机器人是免费的、无限量的而且群消息的醒目程度远高于手机通知。4. 核心部署实操在飞牛上完整跑通 RenewHelper4.1 编写 docker-compose 配置文件先解释一下为什么我这里推荐 Docker Compose 而不是直接 docker run。RenewHelper 虽然只有一个容器但它涉及端口映射、数据卷挂载、环境变量配置、重启策略等多个参数。用 docker run 一条命令写下来参数冗长不说日后想改某个配置还得重新输入一长串命令非常容易出错。Compose 文件把这些配置固化下来改起来清晰重建容器也只是一条命令的事。下面是完整的docker-compose.yml我用的是这个版本实测可以稳定运行version: 3.8 services: renewhelper: image: registry.cn-hangzhou.aliyuncs.com/renewhelper/renewhelper:latest container_name: renewhelper restart: always ports: - 8300:80 volumes: - /vol1/docker/renewhelper/config:/app/config - /vol1/docker/renewhelper/data:/app/data environment: - TZAsia/Shanghai - LANGzh_CN.UTF-8 - DB_TYPEsqlite - DB_HOST - DB_PORT - DB_USER - DB_PASSWORD - DB_NAME - ACCESS_AUTHfalse - ACCESS_USER - ACCESS_PASSWORD - NOTIFY_WEBHOOK extra_hosts: - host.docker.internal:host-gateway每个参数逐个说image镜像地址。我用的是阿里云镜像仓库的地址在国内环境下拉取速度快很多不会出现 Docker Hub 超时的问题。ports8300:80表示把容器的 80 端口映射到飞牛宿主机的 8300 端口。左边是宿主机端口右边是容器端口别搞反了。宿主机端口没被占用就行。volumes挂载数据目录。/vol1/docker/renewhelper/config是飞牛上的目录/app/config是容器内的路径。数据卷的作用是容器删除重建之后数据依然保留。TZAsia/Shanghai时区设置。这个看似不起眼但少了它提醒时间可能会差 8 个小时非常影响使用。DB_TYPEsqlite默认使用 SQLite 数据库对个人用户来说完全够用了。如果以后提醒项特别多几千条以上再考虑切换到 MySQL 或 PostgreSQL 也不迟。NOTIFY_WEBHOOK这里填前面准备好的 Webhook 地址。如果暂时没有可以先留空面板里面也能配置。ACCESS_AUTHfalse是否开启登录认证。如果 NAS 只有你一个人用可以先设为 false 方便访问如果准备让家庭成员一起用建议设成 true 并配置用户名密码。4.2 通过飞牛 Docker 界面部署的完整过程有了 Compose 文件部署过程就非常直白了。先登录飞牛 fnOS 的面板找到文件管理在/vol1/docker下新建renewhelper目录再进入这个目录新建config和data两个子目录。目录建好后把上面的 Compose 文件保存为docker-compose.yml上传到/vol1/docker/renewhelper目录下。接下来打开飞牛的 Docker 管理界面。不同版本的界面布局略有差别但核心逻辑是一样的找到项目或Compose相关入口点击新建项目。项目名称建议填renewhelper路径选择刚才的/vol1/docker/renewhelper目录界面会自动读取目录下的docker-compose.yml。如果没有自动读取就把 Compose 内容手动粘贴到编辑框里。确认无误后点击部署按钮。首次部署需要拉取镜像时间取决于你的网络状况。飞牛如果配置了国内镜像加速器一般一两分钟就能拉完如果没配置可能需要等几分钟甚至超时。镜像拉取完成后容器会自动启动。这时候打开浏览器访问http://你的NAS内网IP:8300应该就能看到 RenewHelper 的登录界面或设置向导了。如果页面打不开先别急着怀疑配置按照后面常见问题章节的方法排查一下。4.3 首次初始化与提醒项配置首次打开 RenewHelper界面会比较简洁。我个人比较喜欢这种风格——没有一堆花里胡哨的功能入口核心就是创建提醒项和查看到期列表两件事。点击创建提醒项按钮会看到几个关键字段名称给自己看的建议写清楚点比如我的域名 renewal、阿里云服务器到期。到期日期填写具体的到期时间。这里要注意RenewHelper 按天粒度做提醒所以日期部分填准就行。提前提醒天数这是整个工具的灵魂参数。比如域名还有 30 天才到期你可以设置提前 7 天提醒那么在到期前 7 天开始系统每天都会推一次提醒。提醒方式选择前面配置好的 Webhook 渠道。如果只配置了一个渠道这里会默认选中。填完保存这条提醒项就生效了。RenewHelper 的后台会有一个定时任务通常每隔几小时扫描一次所有提醒项发现进入提醒时间窗口的项就通过 Webhook 推送通知。需要提醒的是RenewHelper 里的提醒不是一次性的。只要当前日期落在提前提醒天数到到期日之间每次扫描都会再提醒一次。这个设计是有意为之的——防止你一忙起来把通知划掉就忘了。如果觉得太吵可以把提醒天数调得短一点比如提前 3 天这样轰炸次数就少很多。5. 核心功能解析RenewHelper 能管什么、怎么管5.1 支持的管理类型与典型使用场景RenewHelper 把到期事项分成几大类每一类在实际使用中都对应着具体的场景第一类是域名到期。这是最刚需的一类。域名注册商通常会在到期前发邮件但现代人邮箱太多了很容易漏看。把域名到期日填进 RenewHelper提前 30 天开始每周提醒一次提前 7 天每天提醒一次基本可以杜绝忘记续费的情况。第二类是 SSL 证书到期。如果你自己管理网站或 NAS 的 HTTPS 证书就知道证书过期有多烦——浏览器直接红色告警用户马上就跑了。RenewHelper 在这里可以配合证书有效期追踪工具一起用把证书到期日填进去提前 14 天开始提醒留足时间做续期。第三类是各类订阅服务到期。这里面门道多得很各种网盘会员、音乐 App 会员、视频平台会员、甚至家里宽带的合约期。我把这些杂七杂八的到期日全部统一管理在 RenewHelper 里每个月月初看一遍列表心里就有数了。第四类是自定义事项。RenewHelper 允许创建任意自定义提醒项时间一到就推通知。比如你可以在上面记录驾驶证换证日期、车辆年检日期、各类证照有效期。本质上它就是一个全自动化的备忘录区别在于它不需要你主动去翻看。5.2 通知渠道接入细节RenewHelper 的通知逻辑走的是通用 Webhook 协议这意味着理论上任何能够接收 Webhook 请求的平台都能接入。最常用的是飞书群机器人和钉钉群机器人。飞书群机器人的 Webhook 格式大约长这样https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx拿到地址后在飞书群里输入/机器人添加自定义机器人取名随意安全设置选自定义关键词建议填提醒或签名校验。如果要开签名校验得把加签密钥也记下来配置到 RenewHelper 里。钉钉机器人的流程类似。在钉钉群里添加自定义机器人安全设置选加签或自定义关键词把 Webhook 地址复制下来。我在配置时的经验是关键词设为工具名本身最稳妥防止因为关键词不匹配导致消息被平台拦截。另外测试时务必实际触发一次提醒别只看配置界面上连接成功之类的提示。有些平台的 Webhook 地址测试连接时正常实际推送时会因为关键词或加签问题被拦截。5.3 数据备份与迁移自托管服务的优势是数据自主可控但前提是你得做好备份。RenewHelper 的数据库文件就在/vol1/docker/renewhelper/data目录里SQLite 数据库就一个文件备份非常方便。我的做法是在飞牛的定时任务里加了一个每周执行的脚本把整个 renewhelper 目录打包压缩存到另一个磁盘插槽的备份目录里。这样即使系统盘出现故障也能在几分钟内恢复所有提醒配置。如果以后想把 RenewHelper 从一台 NAS 迁到另一台 NAS流程也很简单把data目录整体拷贝过去重新部署容器挂载同一个数据目录启动后所有提醒项都还在。这一点比很多在线服务要省心得多——在线服务想迁移数据导出导入格式往往不兼容麻烦得很。6. 实操过程记录从容器启动到第一条提醒跑通6.1 容器启动后的验证步骤容器启动后我习惯按一套固定流程验证系统是否正常而不是直接开始配置大量提醒项。第一步查看容器日志。飞牛 Docker 界面可以直接点击容器查看日志也可以通过命令行执行docker logs renewhelper。正常情况下日志里会看到服务启动成功的提示不会出现明显的 ERROR 或 panic 信息。这一步能发现 90% 以上的配置问题。第二步访问 Web 界面。在浏览器里输入http://IP:8300能打开页面就说明服务基本正常。如果打不开先检查飞牛防火墙有没有放行 8300 端口。飞牛的防火墙默认只放行常用端口自定义端口需要手动添加规则。第三步创建一条测试提醒。把到期日设成明天提前提醒天数设成 1 天保存后等后台扫描。RenewHelper 的定时扫描周期一般在 1 小时左右所以如果配置完发现没有立刻收到通知不用急等一个周期再看。等扫描到这条提醒项Webhook 就会收到一条测试消息验证就完成了。6.2 一条提醒从创建到推送的完整链路分析为了帮助理解我把一条提醒消息从创建到推送的完整链路梳理一下当你在界面上点击保存之后RenewHelper 会做这几件事提醒项数据写入 SQLite 数据库后台定时任务在下一个扫描周期发现这条记录检查当前日期是否在提醒窗口内即到期日减去提醒天数到今天范围是否覆盖当前时间如果命中窗口读取配置的通知 Webhook 地址构造一条 JSON 格式的消息体发送 POST 请求到 Webhook 地址IM 平台的机器人接收消息推送到群聊。这里面最容易出问题的是倒数第二步也就是 Webhook 请求的构造。RenewHelper 默认的消息格式是飞书/钉钉通用的 Markdown 文本格式。如果你接的是其他渠道可能需要在配置里调整消息模板。说实话这个功能稍微有点门槛但了解了消息链路之后排查起来就非常有方向感了。6.3 配置持久化的理解这里补一个很多新手容易忽略的细节RenewHelper 的配置和数据分别存放在两个不同的目录。config目录存的是应用级的配置项比如通知渠道、消息模板、系统参数data目录存的是 SQLite 数据库文件也就是那些提醒项记录。为什么要分两个目录因为备份和迁移的优先级不一样。配置可以重新填数据库里的历史提醒记录和状态却不可再生。所以备份的时候data目录是必选项config目录则可以视情况一起备份。从容器管理的角度看升级 RenewHelper 镜像时只要挂载目录没变升级前后数据就无缝衔接。这比直接在宿主机上装软件要清爽得多——Docker 容器删除重建像换了个新零件但挂载的硬盘还是原来那块。7. 常见问题与排查技巧实录7.1 界面打不开怎么办这个问题出现频率最高第一次部署时几乎人人都会遇到。遇到界面打不开按照下面这个顺序排查第一步确定容器在运行。飞牛 Docker 界面里容器状态如果显示运行中说明容器本身没问题如果显示已停止或重启中点开日志看具体报错。第二步检查端口占用。如果 8300 端口已经被其他容器或服务占用了RenewHelper 容器虽然启动成功但端口映射会失败。在飞牛 Docker 管理页面可以看到每个容器的端口占用情况冲突的话换一个端口重新部署即可。第三步检查防火墙。飞牛 fnOS 的防火墙默认会拦外部访问如果你是在局域网内访问但被拦截大概率是放行规则没加。进入网络设置把 8300 端口加进白名单。7.2 收不到任何提醒消息容器运行正常、界面也能打开但就是收不到推送的消息这是第二高频的问题。最常见的原因是 Webhook 地址配置错误。Webhook 地址是一串很长的随机串手打容易出错一定要用复制粘贴的方式填入。另外飞书机器人如果设置了签名校验RenewHelper 里也需要填入对应的密钥否则会被平台拒收。另一个原因是提醒窗口没算对。比如你把提前提醒天数设成 7今天是 1 月 10 日到期日是 1 月 14 日那么 1 月 10 日到 1 月 14 日之间都是提醒窗口。但如果到期日已经过了RenewHelper 默认不会再推送提醒需要修改到期日才会重新进入提醒状态。还有一个偏门的原因RenewHelper 容器内的时区如果没设置成 Asia/Shanghai日期计算会偏移 8 小时可能导致提醒早了一天或晚了一天。检查一下 Compose 文件里有没有加上TZAsia/Shanghai环境变量。7.3 容器迁移和升级时的坑RenewHelper 升级镜像其实很简单拉取新镜像重新部署 Compose 项目数据卷不变配置也基本保留。但我遇到过一个问题新版镜像如果修改了数据库结构旧版 SQLite 文件在启动时可能会做一次自动迁移如果迁移失败容器会一直重启。遇到这种情况先别急着重装。把data目录完整备份一份然后看容器日志的具体报错。大多数情况下删除旧的 SQLite 文件、让系统重新初始化是最后的兜底方案但这会丢失历史提醒记录所以务必备份好说不定还可以用工具手工导出旧数据救回来一些关键记录。另外说一个实操经验RenewHelper 这类自托管工具其实没什么必要追版本。稳定运行的前提下小版本更新带来的功能提升有限反而引入迁移风险。我现在的做法是确定当前版本够用之后就停在该版本上除非有安全更新否则不主动升级。8. 进阶玩法RenewHelper 与其他自托管服务的联动部署完 RenewHelper 之后它的价值远不止记几个到期日这么简单。玩 NAS 的圈子里有一句口头禅叫一切皆可自动化RenewHelper 完全可以作为自动化链路里的一环和飞牛上的其他服务串起来。比如最常见的联动是配合 Uptime Kuma 这类监控工具。Uptime Kuma 可以监控网站和服务的在线状态但它不会知道你的服务哪天到期。RenewHelper 补充的正是这个盲区Uptime Kuma 负责现在挂了没有RenewHelper 负责未来会不会挂。两者配合网站运维的基本盘就稳了。再比如配合反向代理容器的证书管理。Nginx Proxy Manager 会自动续签 SSL 证书但偶尔也会出现续签失败的情况。在 RenewHelper 里建一条证书到期提醒到期前提醒一次就当是给自动续签上一道保险。自动续签成功就忽略提醒失败了看到提醒也能及时介入。还有一类联动是配合家庭网络设备的管理。很多人用飞牛 NAS 统一管理家里的小主机、摄像头、路由器。这些设备固件的安全更新也是到期事项的一种——虽然设备本身不会过期但安全支持有时限。把设备的安全支持截止日期登记到 RenewHelper到期前提醒自己评估是否要更新硬件。这些场景加在一起RenewHelper 就不再只是个到期提醒工具而是一个家庭基础设施生命周期管理中枢。它管理的不只是会员到期而是整个数字生活的关键节点的时间线。9. 我在使用中的几点体会与建议RenewHelper 在飞牛 NAS 上稳定跑了几个月之后我最大的感受是安心。以前靠手机日历提醒日历条目多了之后人就麻木了提醒弹出来经常是哦知道了然后继续忘。现在所有到期事项集中在一个面板里管理到时间了群消息直接推过来想无视都难。给初次上手的朋友几个建议第一初始配置一定要做一次完整的测试。创建一个明天到期的测试项确保通知能真正收到再开始批量录入真实数据。千万别偷懒跳过这一步不然录了几十条数据之后发现通知没配置对排查起来非常被动。第二提醒天数宁多勿少。域名的提前 30 天证书的提前 14 天服务类的提前 7 天。RenewHelper 支持每天重复提醒时间长一点不会造成负担反而给了充裕的缓冲时间。第三定期检查提醒列表的准确性。到期事项处理完之后一定要回到 RenewHelper 里更新状态或修改到期日期。保持数据的实时性工具才能持续发挥作用。第四把备份做好。在飞牛上部署自托管服务最怕的就是数据丢失。一条简单的定时打包脚本每周备份一次数据目录成本几乎为零但能给你一份数据永不丢失的底气。我在实际使用中还有一个体会是RenewHelper 这类工具好不好用很大程度上取决于你能不能坚持维护数据。工具本身只是提醒它解决的是记住的问题但及时更新这件事终究还是要靠人。好在 RenewHelper 把记这件事变得足够简单简单到你不会因为嫌麻烦而放弃维护。最后分享一个小技巧建提醒项的时候名称不要只写域名到期这种笼统的名字而是要带上服务商和账号信息比如阿里云-我的电商域名-yyyy这样。这样几年之后再翻看提醒列表每条记录背后的关联信息一目了然不用点开详情才能回忆起来是什么。这个习惯帮了我大忙也推荐给你。