用 Docker 部署 Memos：把零散笔记整理成能找回的私人时间线

一条排错命令、一张收据照片、读到一半的想法，往往不值得马上开一个文档。它们留在聊天窗口或浏览器标签里，过几天再找就要靠记忆。Memos 的时间线适合收这些短记录：先写下内容，再通过标签、日期和搜索找回来，不必每次给笔记想一个标题。

这种轻量记录也容易积累敏感内容。服务器地址、内部截图、账单和未完成的想法混在一起时，部署前就应该确定默认可见性。不要先把实例公开，写了几十条以后才逐条检查哪些内容可以被别人看到。

部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。

先划清私人记录与分享记录

日常记录可以分成私人、已登录用户可见和公开三类。公开记录适合分享知识或项目进展，私人记录用来保存个人内容，给少数同事看的内容则需要核对账号和可见范围。分享一个链接之前，分别用登录窗口和无痕窗口打开，实际确认访客看到什么。

Memos 官方时间线与记录编辑器示例

官方示例展示了记录输入区、时间线和标签的关系，不同版本的布局可能变化。新实例的设置和每条记录的可见性需要单独检查。

Memos 能保存短文本及附件，但它不会自动判断一条笔记是否包含密码。接口密钥、一次性恢复码等内容继续放在合适的密码管理器中，笔记里记录用途和获取位置即可。截图上传前也检查是否暴露账号、令牌或私人地址。

新实例从一个容器开始

本文针对新部署，使用官方仓库当前推荐的 neosmemo/memos:stable。stable 会随稳定版本更新，长期运行前应记录实际镜像摘要，并按发行说明固定版本。官方当前发布命名已采用年月形式，不能把旧文章里的版本号机械套到新实例上。

mkdir -p ~/services/memos/data
cd ~/services/memos

保存 compose.yaml：

services:
  memos:
    image: neosmemo/memos:stable
    ports:
      - "127.0.0.1:5230:5230"
    volumes:
      - ./data:/var/opt/memos
    restart: unless-stopped

默认以 SQLite 保存数据。data 挂载的是应用的数据目录，重建容器时需要保留。不要因为某次启动失败便删除它；先查看日志和权限，确认问题是不是镜像、文件属主或数据库迁移造成的。

docker compose config --quiet
docker compose up -d
docker compose logs --tail=80 memos
docker compose images

通过 SSH 转发访问后台：

ssh -L 15230:127.0.0.1:5230 user@your-server

本机打开 http://127.0.0.1:15230，完成初始账号设置。因为端口绑定回环地址，远程访客不能直接通过公网 IP 打开 5230。需要域名访问时，再把反向代理接到这处入口并启用 HTTPS。

域名确定之后再设置外部地址

Memos 的 MEMOS_INSTANCE_URL 用于告诉应用自己的外部访问地址。正式入口确定为 https://notes.example.com 后，可在 Compose 的服务内加入这一环境变量。域名示例需要换成实际域名，反向代理也必须真的能够转发到 5230。

services:
  memos:
    image: neosmemo/memos:stable
    environment:
      MEMOS_INSTANCE_URL: https://notes.example.com
    ports:
      - "127.0.0.1:5230:5230"
    volumes:
      - ./data:/var/opt/memos
    restart: unless-stopped

更新后运行 docker compose up -d。用正式域名登录、提交短记录、上传图片，再退出登录看一次。只验证首页加载不够：前端正常出现，而上传、登录或接口访问失败，依然说明代理或外部地址没有配完整。

Memos 文本、附件和公开访问关系示意

文本和附件都需要恢复，公开访问则取决于账号与记录设置。图里把这两条路径分开，避免把“文件已保存”误当成“访问权限已检查”。

准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。

标签不必从第一天设计得很复杂

先围绕自己会搜索的词建立少量标签，例如项目名、设备名或工作主题。一条记录已经写出完整设备型号时，不一定还要补一个大而泛的“科技”标签。标签的目的应是缩小范围，而不是给每条记录增加整理任务。

故障记录可以写清日期、现象、相关服务和最后采取的措施。把“网站打不开”细化为“首页能打开，上传图片返回错误”，以后搜索时才知道自己当时排查的是哪一步。涉及技术结论时，保留版本和条件，别只剩下一条脱离环境的命令。

适合放进 Memos 的记录通常能单独理解。保存外部页面时，给链接加一句说明，交代为什么收藏它；截取一段内容时保留来源信息。如果内容后来发展成一份长文，把笔记整理进正式文档，在时间线里留下指向文档的入口，比不断往旧短记录里堆内容更容易阅读。

附件应当和文本一起接受检查

初次部署时上传一张图片和一个普通文件，分别检查登录后能否打开，以及预期无权限的访客是否能够访问。不要只检查正文页面上的可见性按钮，直接附件地址也要纳入自己的验证。应用版本、存储配置和代理都会影响实际行为。

上传失败先查看容器日志，再看代理的请求大小限制与超时。手机拍摄的图片可能比想象中大，不要把所有限制直接调成无限；先确定实际需要上传的类型和大小。附件逐渐增多后，监控 data 目录占用，保持恢复时也有足够空间。

多人使用时，为每个人建立独立账号。不要共享管理员密码，也不要通过匿名入口把私人资料临时传给同事。成员离开后，处理账号、令牌和相关记录的权限；关闭一个账号并不会替你审查此前发布的所有公开内容。

需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。

用少量记录验证导出和恢复

首次保存几条文字、不同标签和一份附件后，就做一次备份。用户层的文本导出适合整理或迁移笔记，但不能默认包含完整数据库、所有账号和附件。整实例恢复需要把这些组成部分考虑在内。

最容易说明清楚的方式，是暂停应用后对整个持久目录做一致副本：

mkdir -p backups
docker compose stop memos
tar -czf "backups/memos-$(date +%F-%H%M%S).tar.gz" data compose.yaml
docker compose start memos

备份完成后将文件转移到其他机器或存储，限制访问。backups 不在 data 里面，避免应用目录与备份副本混在一起。数据量增加后，停机复制的耗时可能不合适，再根据所用数据库和存储改用更适合的方案。

恢复测试放到独立目录，使用备份时记录的镜像版本或摘要，映射另一个回环端口，例如 15231。登录后检查记录文本、日期、标签、用户、图片和文件下载；原实例继续运行时，不要让测试实例使用同一个数据目录。

老实例升级需要按迁移路径走

这里的 Compose 适用于新安装。已有实例，尤其旧版本，不应把镜像直接改成 stable 就视为升级完成。官方仓库明确给出早期版本的迁移要求，例如早于 v0.31.0 的实例要先成功运行 v0.31.0；更旧版本还应检查迁移文档中的对应步骤。

升级前保存数据副本、旧镜像标识和配置。先在副本上验证，再更新正式实例。新镜像如果已经修改数据库结构，回退时必须使用升级前的数据副本，不能只换回旧容器。恢复路径确认后，再继续往时间线里放新的笔记。