域名一年付一次，VPS 有月付也有年付，软件试用结束后又开始自动续费。费用分散在不同平台，单看某个月账单，容易漏掉下一周到期的项目，也难判断一个已经不用的工具是否还在扣费。
Wallos 是可以自托管的订阅记录工具。适合把自己已经确认的费用、周期和续费日期集中整理，再通过通知提醒。它不会因为你删除了一条记录，就替你取消服务商的订阅或自动扣费授权。
先用几条虚构项目走通部署和提醒，然后逐步补入真实账单。比起直接导入一大堆名称，先核对金额、计费周期和到期日期。
一条订阅记录至少要解释清楚什么
项目名称只负责识别，真正决定费用含义的是金额、币种、周期、下次付款日期和用途。一个标价十美元的服务，月付与年付差别很大；首年优惠也不能直接当作未来每年的固定成本。
站点维护者可以先整理域名、服务器、邮件发送、对象存储与协作软件。域名续费是否与注册价相同，服务器优惠是否限制首期，应查对应账户中的实际条款与订单，不凭旧截图录入。
按用处分组有助于发现重复。比如两个都只服务于停用站点的工具，下一次付款前需要决定是否保留；测试服务器和正式服务器也应能区分。不要只按服务商名称分类，让所有用途混在一起。
Wallos 项目提供周期费用、分类、多币种与通知等能力。本文围绕人工确认的订阅记录，不接银行账户，也不引入自动执行付款或退订的流程。
Docker 配置只需要应用与持久化目录
VPS 上已有 Docker 和 Compose，建立独立目录：
mkdir -p ~/wallos/db ~/wallos/logos
cd ~/wallos
按照官方 Compose 示例，数据库和上传标志图片分别保存：
services:
wallos:
image: bellamy/wallos:latest
ports:
- "127.0.0.1:8282:80"
environment:
TZ: Asia/Shanghai
volumes:
- ./db:/var/www/html/db
- ./logos:/var/www/html/images/uploads/logos
restart: unless-stopped
当前官方示例使用 bellamy/wallos 镜像，不要因为项目名相同就换成未知发布者的构建。第一次验证后，记录并固定核实过的版本或镜像摘要，方便以后恢复相同环境。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 wallos
ssh -L 18282:127.0.0.1:8282 user@your-server
浏览器打开本机 http://127.0.0.1:18282，在私人入口完成初始账户设置。第一次运行时数据库与目录需要应用账户可写，出现权限错误先检查日志和具体挂载，不要把整个工作目录设为任意用户可写。
镜像内的部署方式与裸机安装不同。官方裸机说明列出了 cron 工作，而 Docker 方案应按镜像的实际运行机制核对；不要照抄裸机计划再到宿主机重复执行同一任务。
先录入三条不会发生真实扣费的样本
可以用“测试域名年费”“测试 VPS 月费”“测试软件季费”三条虚构记录。分别设置不同周期和日期，查看列表、统计与提醒设置。名称里保留“测试”，避免以后当成真实支出。
其中一条用不同币种，帮助理解汇总。换算后的数字只是依据所用汇率计算的展示，不一定等于付款平台结算、税费和银行卡费用。使用汇率服务时按当前配置确认来源与更新，不把汇总页面当成已核对账单。
试用完成后再录入真实项目，依据账户订单或发票逐条确认。金额中是否含税、是否包含折扣、周期起点与付款日期是否相同，都可能影响解释。模糊地方先写备注，别为了让统计整齐而猜一个数字。
对于按量计费的服务，固定周期记录可能只能表示预估或提醒。把估算与真实发生的费用分开，实际账单仍从原平台核对。不能因为软件支持订阅周期，就把所有云资源费用都改写成固定月费。
提醒提前量，应能留出处理时间
域名和重要服务器适合留出检查、续费与付款失败处理的时间。临到最后一分钟提醒，即使消息正常送达，也不一定有足够时间解决问题。具体提前量根据服务用途决定，不需要所有项目相同。
Wallos 支持多种通知方式，先选择自己已经使用且能维护的一种。填入邮件或其他渠道配置后，测试渠道，再为演示记录安排实际触发，确认定时处理与日期逻辑都正常。
检查服务器时区与记录日期。容器环境设置 Asia/Shanghai，不代表旧记录自动解释成期望日期；跨时区服务的扣费时间，还应在备注里写清。触发时间与服务商到期时间不是同一事件。
通知内容包含订阅名称和金额时，也会进入相应通知平台。只保留处理需要的信息，渠道令牌按秘密管理。需要分享记录截图时，隐藏账号、订单编号和私人备注。
续费成功与取消服务要分别更新
收到提醒后先去原服务平台核对是否已经扣费。自动续费已完成的项目，应确认下一次日期和费用；没有付款的项目，按实际状态处理。不要因为面板自动推进了日期，就把它当成支付成功证据。
取消服务时先完成服务商提供的取消或关闭自动续费操作，保存必要结果，再调整 Wallos 记录。仅在记录工具删除条目，不会撤销原平台授权，提醒消失反而可能掩盖后续扣费。
服务器不再续费之前，还要迁出需要的内容、备份与域名指向。费用决定和数据清理是不同步骤，不能为了减少列表项目就先删除重要记录。对于仍需保留订单信息的服务，可以按实际功能与自己的归档方式处理。
首期价格发生变化时，记录下一期真实报价与条件，而不是保留优惠金额等待提醒。每次续费确认都可以顺手更新用途、负责人和最近一次核对日期，避免半年后不知道为什么还保留某个工具。
域名访问以私人账本为前提
需要固定入口时，用现有反向代理把独立 HTTPS 域名指向本机8282端口。确认自己的账号和访问范围以后，再开放所需路径。不要把个人费用记录作为公共演示，演示数据也不要混进真实实例。
已有其他账号体系时，可以研究项目支持的 OIDC 配置，但这不是首次安装的必要条件。先确保普通登录、提醒与恢复可用，再决定是否引入额外认证依赖。
手机上打开列表与单条记录，检查金额、日期和备注是否能看清。真正使用时不需要每次进桌面后台：续费提醒到来后，能快速找到原平台与记录，才适合长期维护。
两个数据目录一起备份
示例中的 db 保存数据库相关文件，logos 保存上传图标。备份时暂停应用写入，归档两者，再启动：
umask 077
docker compose stop wallos
tar -czf wallos-data.tar.gz db logos
docker compose start wallos
检查命令结果，把归档复制到独立受限存储，并另存 Compose、镜像标识和恢复需要的配置。账本含服务名称、费用与私人备注，不适合放公开目录。
恢复演练使用隔离实例，关闭真实通知，以免测试环境发出重复提醒。恢复以后核对账户、三条测试记录、正式记录数量与图标，再检查提醒设置。能打开登录页只证明应用启动，不能证明数据完整。
若配置了外部汇率或其他服务凭据，也将其列入受控恢复材料。数据备份和凭据保存需要一起计划，不能恢复后才临时重新找一遍账号。
一个年付 VPS，怎样避免录成十二笔月费
假设订单明确显示一年付一次，录入时应使用该周期和真实年付金额。统计界面为了比较而折算成月度金额，是展示方式，不代表服务商每个月都会扣款。下次支付日期应与订单到期条件一致，不能依据折算数字重建计划。
如果第一年用了优惠券，把首期订单与下一期报价分别记录。续费前核对后台实际应付金额，再更新条目；不能把一年前的活动页面当作当前报价。没有确认续费价格时，在备注说明待核对，不要用猜测掩盖不确定信息。
套餐规格变化后，费用也可能变化。用途、周期和服务商链接都值得重新检查，尤其是测试实例升级成正式服务器时，负责人和保留原因往往已不同。记录的目的，是让下一次付款有足够上下文。
域名也有类似问题：转入优惠、首年注册和普通续费可能不是同一种费用。录入时看自己账户的实际订单，不需要在账本里给所有域名套一个统一价格。
提醒重复，先找有几套任务在工作
迁移后旧实例没有停用通知，新实例又启用了同一渠道，可能收到两次相似消息。先检查实际运行实例与触发记录，再决定哪边保留。不要因为重复就把两个渠道都关闭，之后忘记重新启用。
恢复演练也应关闭真实通知。测试数据的日期接近当天时，可能触发正常逻辑，造成业务负责人误以为真的需要付款。给演练实例单独命名、隔离出站通知，有助于分清来源。
通知失败时检查渠道凭据与日志，提醒日期不符合预期时再核对时区和条目周期。消息送达与计算日期是不同阶段，分开排查能避免反复重填所有费用。
每月留十分钟维护，比首次录入更重要
清单维护可以从最近付款和即将到期两部分开始。核对已经付的金额与下一次日期，再看近期需要续费的项目是否仍在使用。有人负责的订阅记录，才会持续准确。
发现用途不明时，先查服务实际使用情况，再决定保留或取消。别单凭月度金额高低判断价值：一个很便宜却已停用的服务仍会积累支出，一个必要的备份服务则不能因短期没人打开界面就认为无用。
Wallos 最适合提供可追踪的记录和提醒。账单来源、服务实际状态与取消结果仍由原平台确认。把这些边界放进日常维护，续费就不必再依赖邮箱里偶然看到的一封通知。