从零部署Wallos打造专属预算管理平台1. 项目概述Wallos到底在解决什么问题1.1 个人财务管理的三个真实痛点先聊一个很现实的问题你的钱到底花在哪了我把近两年的流水拉出来看最大开销不是房租不是吃饭而是一堆“看起来很小”的订阅服务——视频会员、音乐、云盘、域名、VPS、AI工具API加起来一个月居然有三百多块一年就是四千多。这种钱最大的特点就是“每笔不多累积惊人”而且容易被忽略。等到扣费短信弹出来才意识到有些服务已经续费好几个月自己却压根没用过几次。第二个痛点是跨平台记账的繁琐。市面上主流记账App我基本都试过要么数据存在别人服务器上隐私没有保障要么功能太重每次记账要选分类、选账户、填备注三个月下来就坚持不住。还有一个很实际的问题很多记账工具不支持多币种或者只有付费版才开放统计功能。我人在国内偶尔有海外收入币种一混账单立刻变成一团浆糊。第三个痛点是“预算控制”停留在嘴上。你告诉自己“这个月少花点”但缺少一个工具告诉你我到底超了没有、还差多少到预算线、哪些类别已经接近上限。等你自己反应过来钱已经花完了。这三个痛点叠加在一起我一直在找一套能长期用下去的解决方案最后锁定了Wallos。1.2 Wallos的核心功能拆解Wallos是一个自托管的开源财务管理工具技术上基于PHP和MySQL/MariaDB功能设计上紧紧围绕“订阅管理”和“预算控制”两个核心。它的仪表盘能直接看到当月支出总额、可用预算、活跃订阅数量以及最近七天的消费趋势曲线。订阅管理支持按周、月、季度、年等不同计费周期记录自动算出下次扣费日期还能给即将到来的账单设置提醒。“预算”模块可以按类别设置月度限额比如餐饮、交通、娱乐各设一个数每笔支出记账后自动扣减对应类别额度用图形标出剩余预算。它还内置了支出和收入流水、分类管理、多账户比如现金、信用卡、储蓄卡、多币种汇率换算以及数据导出。最让我在意的一点是所有数据都存在你自己的数据库里跟云端服务彻底脱钩。1.3 什么人适合用Wallos对号入座的话适合用Wallos的人大概有三类一是有大量订阅服务、需要做“订阅健康检查”的人二是想建立月度预算习惯、希望每笔开销都有地方记录的普通人三是已经跑着其他自托管服务比如家里有NAS、VPS上挂着其他容器纯粹想把数据控制权握在自己手里的玩家。前两类人是主力用户第三类人则是“顺手就会去部署”的天然受众。我自己属于第一类和第三类的混合体订阅多、又不想用别人的云服务。如果你跟我情况类似这篇文章应该能帮你少走不少弯路。2. 部署方案选型为什么必须用Docker2.1 传统安装与容器化部署的横向对比Wallos的官方文档提供了多种安装方式但部署路径大致分两类传统LAMP/LEMP环境安装和Docker容器化部署。传统方式要在服务器上装好Nginx或Apache、PHP 8.1以上版本、Composer、MariaDB然后手动clone源码、安装依赖、配置虚拟主机、设置数据库连接。这套流程对于只部署过一两个服务的人来说并不轻松而且最容易出问题的是PHP扩展版本对不上、权限没给够、伪静态规则写错这种让人崩溃的细节。一旦后续要升级版本还得重新走一遍环境检查和源码更新的流程操作成本不小。Docker Compose方式则是把Web服务、PHP运行环境、数据库全部封装进容器宿主机器上只要有一个Docker环境即可。升级版本只需改一下镜像tag后重新拉取数据用volume挂载在宿主机上备份和迁移都非常方便。这跟很多人在本机部署大模型、安装其他自托管应用时的方式一致——容器化已经成为部署类工具的主流姿势。我自己在部署Wallos前已经在同一台VPS上跑了好几个容器包括持续集成用的Jenkins、监控用的Prometheus以及一些日常工具对这些服务的管理维护已经习惯用Docker Compose统一编排。所以毫不犹豫选了容器化方案不折腾系统环境也是后续能长期稳定运行的前提。2.2 运行环境要求与最简配置参考Wallos本身是轻量应用资源占用并不高。官方推荐的最低配置比较保守但实际跑下来我用过的配置如下项目官方最低参考我实际使用的配置说明CPU1核1核空闲时占用极低几乎可以忽略内存1GB1GB含数据库容器两个容器约占300~400MB磁盘1GB10GB主要存储数据库文件和备份系统Docker环境即可Debian 12不挑系统Linux/群晖/威联通都行浏览器现代浏览器Chrome/Firefox前端无特殊要求如果你手头只有一个跑着其他服务的服务器完全不冲突。我部署Wallos的这台VPS同时跑着Nginx反代、监控采集器和几个定时任务Wallos的两个容器加进来后内存占用一共多出大约350MB左右CPU占用平时几乎为零。也就是说这台机器从1GB内存升级到2GB后部署Wallos是绰绰有余的。2.3 部署位置VPS、NAS还是本地小主机部署位置的选择会影响后续使用体验。我见过三种方案各有侧重点第一种是部署在国外VPS上。优点是有固定公网IP访问不受家里网络环境影响后续还可以配上域名和HTTPS证书出门在外随时打开看账单。缺点是需要额外支付服务器费用且网络链路质量取决于服务商。第二种是部署在家里的NAS上。很多人的群晖或威联通本来就在跑Docker与Wallos的契合度很高。数据完全存在于本地隐私性最强访问速度也有保证。但外网访问要处理内网穿透或IPv6对没有公网IP的用户稍麻烦。第三种是本地小主机。比如用树莓派或淘汰下来的旧笔记本长期开机专跑家庭服务。适合对隐私有极致要求的人但断电、网络稳定性都是需要考虑的因素。我自己的选择是VPS方案因为这台机器本身就是自己的资产而且后续可能还要在上面部署更多服务Wallos只是其中一个容器。如果你家里已经有NAS且在运行Docker直接部署在NAS上更合理。这个选择没有绝对对错关键是明确自己的访问需求和数据保管偏好。3. 从零开始完整部署流程与Compose配置3.1 准备好你的docker-compose.yml我采用的是Docker Compose方式这也是官方推荐的主流做法。先在服务器上建好项目目录mkdir -p /opt/wallos cd /opt/wallos touch docker-compose.yml然后编辑docker-compose.yml。下面这份配置是我自用的版本经过多轮调整后已经稳定运行了两三个月version: 3 services: wallos: image: bellamy/wallos:latest container_name: wallos restart: unless-stopped ports: - 8282:80 volumes: - ./wallos-data:/var/www/html depends_on: - wallos-db environment: TZ: Asia/Shanghai wallos-db: image: mariadb:10.11 container_name: wallos-db restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: change_this_root_password MYSQL_DATABASE: wallos MYSQL_USER: wallos MYSQL_PASSWORD: change_this_db_password volumes: - ./wallos-db-data:/var/lib/mysql这里有几个关键点值得多说几句。镜像选择镜像名以官方仓库当前信息为准不同时期可能有变化。bellamy/wallos:latest是我部署时常用的一个构建镜像也有用户使用ghcr.io上的官方镜像。如果你拉取的是其他版本注意确认和数据库的兼容性尤其是PHP版本和宿主的架构x86_64还是arm64。同一时间只保留一份镜像别让old和new两个tag并存否则容易搞不清自己跑的到底是哪个版本。端口映射宿主机的8282端口映射到容器内的80端口。之所以不用80是因为我这台VPS上已经由Nginx占用了80/4438282这个高位端口交给Wallos后续想加域名反代也方便。如果你不打算加反代直接映射成80:80也是可以的但要确保宿主端口没有被占用。数据卷挂载把宿主机上的./wallos-data映射到容器内的/var/www/html这个是Wallos代码和数据所在目录。数据库单独挂载./wallos-db-data到MariaDB的数据目录这样数据库文件也能独立保存。两个目录分开挂载的好处是将来重装Web容器时数据库还在反过来如果只想保留程序文件、数据库重来也只需要删掉db目录即可。数据库密码MYSQL_ROOT_PASSWORD和MYSQL_PASSWORD务必替换成自己的强密码。很多人第一次部署图省事用默认密码结果安全隐患非常大后面改起来又要重建容器非常麻烦。3.2 启动容器与验证服务配置写好后启动命令非常简单docker compose up -d第一次执行时会从远端仓库拉取Wallos和MariaDB的镜像。如果服务器网络稳定几分钟就能完成。拉取镜像时我遇到过两次问题一次是网络超时一次是镜像体积较大导致下载中断。解决办法是换一个网络时段再试或者配置好镜像加速源多试几次基本都能成功。启动完成后先用docker compose ps查看容器运行状态CONTAINER ID IMAGE STATUS PORTS f3c8a2b9e1e2 bellamy/wallos:latest Up About a minute 0.0.0.0:8282-80/tcp 5b7e2d1a6c47 mariadb:10.11 Up About a minute 3306/tcp两个容器都是Up状态就说明基础服务没问题。此时在浏览器里访问:8282比如http://你的服务器IP:8282能看到Wallos的初始化页面。第一次打开时页面会自动进入安装向导要求你填写数据库连接信息。这里的关键是数据库容器名是wallos-db由于两个容器在同一个Docker网络中数据库地址不要填localhost或127.0.0.1而是要填服务名wallos-db。端口填3306数据库名、用户名、密码填docker-compose里对应的三个环境变量值。这一步如果填错页面上会直接提示数据库连接失败。我当时就犯过这个错——把数据库地址填成了服务器公网IP结果一直连不上后来改成容器服务名才顺利通过。第一次接触容器互联的新手特别容易踩这个坑。3.3 首次登录与基础配置安装向导完成后用默认管理员账号登录后台具体默认账号建议看官方文档因为不同版本可能不同。登录后第一件事不是急着录账单而是先把“设置”里的基础参数配好。语言选择界面直接切换到简体中文。然后设置默认货币。Wallos内置了多币种支持你可以选出常用币种作为默认货币。如果你有外币账户还可以在“货币”设置里维护汇率Wallos会自动按汇率换算成你设定的基准货币来统计总支出。这个功能对经常有跨境消费的人非常友好也是我放弃其他记账App而选择Wallos的重要原因之一。接着设置时区。前面docker-compose里已经通过TZ环境变量指定了Asia/Shanghai但网页端设置里可能还有自己的时区选项两个地方都要确认一致否则日期统计会错位。最后是通知设置如果你希望账单到期前收到提醒可以在此配置邮件通知服务器。我的经验是先用自己域名邮箱的SMTP服务测试填好发送方、授权码、接收方邮箱后保存并测试发一封确认能收到再启用订阅提醒功能。4. 日常使用与数据维护让Wallos真正可持续运行4.1 订阅管理记清楚每一笔续费Wallos最核心的使用场景就是订阅管理。在“订阅”页面里每次新增订阅要记录这几个字段订阅名称、费用金额、计费周期周/月/季/年、首次扣费日期以及所属分类。我建议给每个订阅补上备注比如“年费套餐含两个子账户”方便日后回忆。分类我会单独维护一套自己的体系比如“视频/音乐/云服务/域名/软件工具/AI服务”每个订阅归属一个分类统计时一目了然。这里有一个值得养成的习惯到期日尽量设为实际扣款日而不是开通日。例如某会员是每月15号扣费你10号开通的那“首期扣费日”就填15号这样Wallos推算下次扣费日更准确。订阅到期前Wallos会在仪表盘上高亮提醒配合邮件通知基本上不会存在“某会员默默扣了大半年”的情况了。预算设置方面我按分类设了月度上限。比如“娱乐”类别每月300元“云服务”每月200元。每录入一笔支出该分类的剩余预算会自动减少。这比月底看总账单再反思要有效得多——消费趋势是持续可见的不用等到月底才醒悟。4.2 数据备份与恢复实操自托管服务最大的隐忧就是不可恢复所以备份必须做在前面。Wallos的数据主要包括两部分程序目录里的配置和数据库。程序目录通过volume挂载在./wallos-data数据库通过另一个volume挂载在./wallos-db-data。一种比较省事的备份方式是直接用mysqldump导出数据库再加tar打包整个数据目录。我写了一个简单的备份脚本每天凌晨通过cron执行#!/bin/bash BACKUP_DIR/opt/wallos/backups DATE$(date %Y%m%d) mkdir -p $BACKUP_DIR docker exec wallos-db sh -c exec mariadb-dump -u root -p$MYSQL_ROOT_PASSWORD --all-databases $BACKUP_DIR/wallos-db-$DATE.sql tar -czf $BACKUP_DIR/wallos-data-$DATE.tar.gz -C /opt/wallos wallos-data find $BACKUP_DIR -type f -mtime 30 -delete脚本里find的作用是自动清理30天前的备份文件防止磁盘被撑爆。恢复时先把容器停掉解压数据目录再把SQL文件导入数据库重新启动容器即可。整个过程我只完整恢复测试过一次但就是这次测试让我发现了一个官网文档没写清楚的坑数据库容器的用户名和密码如果直接在compose里改了恢复时导出的SQL会包含这些新凭据恢复到新环境时容易因为mysql库中的user表不一致而连不上。稳妥做法是恢复前创建好同名数据库和用户再导入业务库数据而不去碰mysql库里的系统表。4.3 多账户与多币种的使用细节我平时会用现金、信用卡、储蓄卡三个账户每笔支出记录时选择来源账户。这个习惯的好处是月底能看出信用卡花销是否超标也能对照银行账单做核对。Wallos在“账户”里维护这些账户并支持账户余额初始值。每次录入支出后对应账户的余额会自动扣减相当于轻量版的记账本。如果你是跨境消费比较多的人多币种值得多花十分钟去配置。Wallos的宽松做法是允许每个账户设置独立币种比如一张美元信用卡币种设为USD。记账时如果选了美元账户Wallos会按照全局汇率表自动换算成基准货币比如人民币来汇总统计。刚开始用的时候我发现每月的总支出和真实账单总有几十块的误差排查后才发现是汇率设置落后了。后来我改成每个月1号手动更新一次汇率误差基本控制在合理范围内。它虽然没有一些商业软件那般全自动接入实时汇率但胜在可控。4.4 反向代理与HTTPS访问如果只有IP:端口方式用一两个月就足够不耐烦了。尤其是每次打开都要输入一串数字IP和端口手机上想看一眼账单都嫌麻烦。我后来用自己的域名给Wallos加了一个子域名通过Nginx反代再配上HTTPS证书。这里分享一个最简的Nginx反向代理配置片段server { listen 80; server_name wallos.example.com; location / { proxy_pass http://127.0.0.1:8282; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }如果你用Caddy那更简单只要在Caddyfile里写一行wallos.example.com { reverse_proxy 127.0.0.1:8282 }证书自动签发和续期不用手动维护。HTTPS这层加上之后Wallos的体验才真正称得上“平台级”手机浏览器打开就是一个干净清爽的财务管理页面数据在传输过程中也有保障。5. 部署与使用中常见问题及排查流程5.1 容器反复重启这是部署初期最常遇到的问题。docker compose ps显示容器一直在Restartingdocker compose logs wallos会给出具体的错误信息。我遇到过的情况有两种第一种是镜像本身和宿主系统架构不匹配比如在arm64的机器上用了x86版的镜像运行起来直接报exec format error解决办法是换用arm64的镜像。第二种是数据目录权限不对容器内Web进程没有写权限此时检查并修正目录属主即可。5.2 数据库连接失败前面提到过初次安装向导时数据库地址填了localhost导致一直连不上。容器里的Web服务访问的是同网络中的数据库服务名不是宿主机的IP。如果你的compose里数据库服务名是wallos-db那么在安装向导里填wallos-db即可。另外确认数据库容器健康后再执行安装向导不要一上来就填数据docker logs wallos-db能看到MariaDB是否完全初始化完成。5.3 时区错乱导致统计不对这个问题不仔细看还真容易被忽略。容器TZ环境变量设了Asia/Shanghai但网页设置里的“日期格式/时区”如果还停在默认值会出现某一笔支出的归属日期和实际消费日期对不上。排查时不要只看仪表盘先到设置里核对两处时区是否一致再回流水里看具体日期。我曾经一度以为记账逻辑出了问题最后发现纯粹是时区没同步。5.4 升级Wallos版本自托管服务的好处是版本升级完全自主可控。Wallos发新版后至少隔几天再升级等社区反馈稳定了再动。我升级的常规步骤是先备份数据库和程序目录然后进入项目目录执行docker compose pull拉取新镜像再docker compose up -d重建容器最后查看容器日志确认无报错。升级后如果发现页面样式或功能异常优先检查浏览器缓存其次看数据库是否需要执行迁移脚本。切记任何升级都比不上备份可靠只要备份在手升级失败也能回滚。5.5 常见问题速查表问题现象可能原因推荐排查动作容器一直重启架构不匹配/目录权限不足docker logs查看报错更换镜像或修正权限安装向导连不上数据库数据库地址填错/DB未ready数据库地址填容器服务名等DB日志输出就绪再操作页面加载极慢反代未开缓存/宿主机带宽不足检查反代配置或换近地节点的网络统计日期对不上各层时区不一致统一容器TZ、Web设置、服务器时区收不到提醒邮件SMTP配置错误/授权码过期用测试邮件功能排查确认SMTP端口和授权码备份恢复后登录失败数据库用户表冲突重建数据库用户不要覆盖系统库表6. 一些个人实践后的体会坦白讲部署Wallos本身并不是一件多高技术门槛的事一个熟手半小时内就能跑起来。但真正让这个平台长期发挥价值的是持续维护数据、每周花几分钟对一次账、每月看一眼订阅到期提醒。部署完成后我把它接进了自己的日常循环里每月月初更新一次汇率月底导出一份流水看看各分类预算执行情况。这样的习惯坚持下来“钱去哪了”这个问题终于不再是凭感觉猜了。最后分享一个额外的小技巧如果你和我一样在VPS上同时跑着多个服务建议给Wallos单独创建一个Docker网络外的目录结构比如/opt/wallos把所有相关文件、备份、compose文件都放在同一个目录下。后续不管是迁移还是灾备恢复只需要打包这个目录转移到另一台装好Docker的机器上docker compose up -d一跑整个平台就再次活过来了。这种“一个目录一个服务”的组织方式是我在长年维护多容器服务过程中养成的习惯对你管理其他自托管应用同样适用。