一篇笔记写完以后，往往还要跟着人用很多年。换电脑时要找得到，整理旧项目时要搜得到，哪天不想再用现在的软件，也应该能把内容带走。挑选笔记工具时，这几件事比编辑器里多一个按钮更值得在意。
Docmost 是一个可以部署在自己服务器上的文档系统。它原本面向协作知识库，但把使用人数缩小到一个人，也很适合整理项目记录、读书笔记、操作手册和长期积累的资料。浏览器打开自己的域名，左边是页面目录，右边写内容；换一台设备登录，继续使用同一份笔记。
不过，自建云笔记要接手的事情也很具体。服务器到期需要续费，更新前需要备份，忘记密码得有恢复入口。托管服务以前替你处理的工作，不会因为软件开源就自动消失。如果愿意承担这些维护，一台 VPS 就能成为这套笔记系统的落脚点。
本文从一台新服务器开始，说明 Community 版的安装、域名访问、日常整理、备份和升级。部署示例按 2026 年 9 月 20 日核对的 Docmost 0.96.0 编写，版本号固定，方便复现；以后照着操作时，应先查看新版本的更新说明。0.96.0 的发布记录包含安全修复，已有旧实例也应评估升级。版本发布记录
准备购买 VPS 的读者，可以从这两个入口选机器：
下文的部署方法通用。先看内存、硬盘和自己实际访问的线路，再比较价格，不必为了搭笔记追求高配。
先确认它适不适合你的笔记习惯
Docmost 的长处在于整理成体系的内容。譬如把一个项目放进独立空间，在下面放需求记录、部署说明、故障处理和复盘，再用子页面继续拆分。几个月后重新接手项目，顺着目录读下来，比在聊天记录里搜零散消息省事。
写作时可以直接插入表格、代码块、图片和附件，页面之间也能建立链接。多人需要维护同一份说明时，实时协作和页面历史会比“你改完再发我一份”方便。个人使用则不必一开始就设计复杂的空间结构，先把最常翻的几十篇笔记放进去，观察自己是不是愿意每天打开它。编辑器说明
它和本地 Markdown 文件夹的工作方式不同。编辑器支持 Markdown 快捷输入，并不等于每篇笔记都以独立的 .md 文件保存在服务器目录里。页面数据在数据库中，上传的图片和附件另有存储位置。日常浏览器访问、数据库备份和内容导出，是需要分别理解的三件事。
如果你的主要需求是断网时随手记、在多个本地编辑器之间切换，或者用 Git 管理所有笔记源文件，就不应把它当成现有本地工作流的直接替身。对手机使用也一样：上线前拿自己的手机试试长文编辑、插图和页面跳转，再决定迁移多少内容。电脑上好用，不代表它一定符合你的移动记录习惯。
社区版够写笔记，但不要把付费功能算进去
Docmost 核心采用 AGPL-3.0 许可证，另有商业授权的扩展部分。自托管 Community 版和官网展示的全部产品能力不是同一个范围。本文不需要购买商业许可证，也不配置模型 API。许可证与版本说明
按当前官方文档，社区版已有页面编辑、空间组织、协作和页面全文搜索等基础能力。Bases 的数据库与看板、页面级细粒度权限、AI 功能、API 密钥管理、附件内容全文检索，以及 TOTP 多因素认证，则在付费功能列表中。不要因为页面上有某个入口，就默认自己的免费实例可以长期使用它。官方功能说明
对个人云笔记来说，这个区别直接影响选型。如果你只是写文章、保存代码片段、归档资料，先用基础功能足够判断是否合适。如果你想把整套 Notion 数据库、团队权限和自动化一起迁过去，就应该逐项核对，不能以“界面看起来像”作为迁移依据。
还有一个常被忽略的边界：部署在自己的 VPS 上，不等于端到端加密。服务器和数据库管理员仍可能接触到数据，备份文件也需要保护。密码、恢复码、私钥不要混放在普通笔记里；公司内部资料能否放到个人服务器，应先得到所在组织的许可。
VPS 怎么选才不浪费
个人实例通常不需要很强的处理器，但不能只按一个网页程序估算内存。下面会同时运行 Docmost、PostgreSQL、Redis 和 Caddy，导入旧笔记、处理附件、升级镜像时，还需要一点余量。
如果是新购机器，我建议从 2 核、4GB 内存、40GB 或以上 SSD 这一档比较。这里给的是便于长期使用的选购建议，不是官方最低配置，也不是经过压力测试得出的容量承诺。已有 2GB 机器可以先试，观察空闲内存、交换分区和导入时的情况；不建议为长期笔记专门购买内存紧张的最低价套餐。
硬盘往往比想象中用得快。正文占用未必大，截图、PDF、导入压缩包、Docker 镜像和本机备份却会一起增长。四十多 GB 的盘，如果长期不清理历史镜像，又把多份附件备份留在原机，很容易在一次升级时发现空间不足。购买时除了看总容量，也要留意扩容方式，并预留一份异机备份的空间。
雨云适合先比较访问线路和管理便利
可以先从 雨云的云服务器入口 看支持 Linux 的实例。选择能安装 Docker、拥有管理员权限的云服务器，不要把虚拟主机、游戏专用服务等其他产品当成本文的部署环境。
如果日常主要从国内访问，先比较可选区域对自己网络的表现，再决定购买哪一档。云笔记里的延迟不只体现在首页打开速度，还会影响上传图片、切换页面和编辑连接的稳定性。区域名称不能替代测试，也不能据此保证某条线路一直快。下单前核对公网地址、端口开放规则、续费价格，以及域名接入要求；本文不把某个地区的政策或促销条件一概写成固定承诺。
RackNerd 适合一起比较长期持有成本
RackNerd 的 VPS 入口 也可以作为备选。它提供 KVM VPS，购买时应查看具体套餐允许选择的机房、内存和 SSD 容量。不同活动的配置与可选区域可能不同，不能把另一篇旧文章中的报价当成现在的结算价格。
如果考虑海外机房，最好在自己经常使用的网络上测试，并把晚间访问体验算进去。一个空白首页加载成功，不能说明持续编辑和上传附件一定顺畅。这里只推荐选购入口，没有对两家的所有机房做横向实测，也不承诺带宽能跑满。真正要比较的，是几年下来能否稳定负担、是否方便迁走，以及每天用起来是否顺手。
已有合适 VPS 的读者可以直接使用，不需要为了本文再买一台。不过，如果那台机器同时跑着正式网站或其他业务，应先确认剩余资源和端口占用。下面按一台专用的新服务器编写，不建议把示例直接覆盖到既有生产环境里。
安装前把环境准备好
建议使用一台干净的 Ubuntu 24.04 LTS 服务器，准备一个自己控制的域名，并确保可以通过 SSH 登录。本文示例域名是 notes.example.com，IP 是 198.51.100.10，两者都只是占位符，操作时换成自己的真实值。
先按 Docker 的 Ubuntu 安装文档 安装 Docker Engine 和 Compose 插件。这里使用的是带空格的 docker compose 命令，不是旧版独立的 docker-compose。服务器若已由面板管理 Docker，就先检查已有安装，不要再叠加另一套来源不明的安装脚本。
sudo docker version
sudo docker compose version
后面的服务器命令在 root shell 中执行。普通管理员先运行 sudo -i，随后建立目录：
mkdir -p /opt/docmost
cd /opt/docmost
公网入口最终只需要 HTTP 的 80 和 HTTPS 的 443，SSH 管理端口尽量限制来源。数据库的 5432、Redis 的 6379 不向公网映射，应用的 3000 只绑定本机。Docker 发布端口与主机防火墙的关系容易造成误判，不能只看 UFW 显示了什么规则；还要核对云平台安全组和真实监听地址。
先不要启动公网反向代理。新实例第一次打开时需要创建所有者账号，应该由你先完成这一步，而不是让一个无人认领的初始化页面暴露在网上。
用 Compose 安装 Docmost
Docmost 官方推荐 Docker 部署，主要组件是应用、PostgreSQL 和 Redis。下面在官方结构上做了几处适合个人服务器的调整：固定应用版本，增加数据库与 Redis 健康检查，把密码移入 .env，应用端口仅监听回环地址。数据库版本与存储路径按当前官方配置核对。官方安装说明
先分别运行两次下面的命令，得到两串不同的随机值，一串作应用密钥，一串作数据库密码：
openssl rand -hex 32
openssl rand -hex 32
在 /opt/docmost/.env 中填写：
DOCMOST_VERSION=0.96.0
APP_URL=http://localhost:3000
APP_SECRET=替换成第一串随机值
POSTGRES_PASSWORD=替换成第二串随机值
十六进制密码只有数字和字母，放进数据库连接字符串时不需要再处理 @、: 等特殊字符的转义。两个占位值必须替换，生成的密钥不要发到聊天群，也不要提交到公开仓库。保存后限制文件权限：
chmod 600 /opt/docmost/.env
接着在同一目录创建 compose.yaml：
name: docmost
services:
docmost:
image: docmost/docmost:${DOCMOST_VERSION:?set DOCMOST_VERSION}
depends_on:
db:
condition: service_healthy
redis:
condition: service_healthy
environment:
APP_URL: ${APP_URL:?set APP_URL}
APP_SECRET: ${APP_SECRET:?set APP_SECRET}
DATABASE_URL: postgresql://docmost:${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD}@db:5432/docmost
REDIS_URL: redis://redis:6379
STORAGE_DRIVER: local
DISABLE_TELEMETRY: "true"
ports:
- "127.0.0.1:3000:3000"
restart: unless-stopped
volumes:
- docmost_storage:/app/data/storage
db:
image: postgres:18
environment:
POSTGRES_DB: docmost
POSTGRES_USER: docmost
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD}
healthcheck:
test: ["CMD-SHELL", "pg_isready -U docmost -d docmost"]
interval: 10s
timeout: 5s
retries: 10
restart: unless-stopped
volumes:
- db_data:/var/lib/postgresql
redis:
image: redis:8
command: ["redis-server", "--appendonly", "yes", "--maxmemory-policy", "noeviction"]
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 10
restart: unless-stopped
volumes:
- redis_data:/data
caddy:
image: caddy:2
profiles: ["public"]
depends_on:
- docmost
ports:
- "80:80"
- "443:443"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
- caddy_config:/config
restart: unless-stopped
volumes:
docmost_storage:
db_data:
redis_data:
caddy_data:
caddy_config:
这里有两处值得单独记住。首先，PostgreSQL 18 的卷挂在 /var/lib/postgresql，不要随手换成旧教程里的 /var/lib/postgresql/data；已有旧版本数据库的人，也不能仅修改镜像大版本就当作完成升级。其次，.env 里的值只有被 Compose 引用，或者通过 env_file 传入，才会进入容器。以后配置 SMTP 时，不能只往 .env 追加变量却不改 environment。
DISABLE_TELEMETRY 用于关闭官方文档所述的匿名统计，和页面访问权限、内容加密是不同的事情。APP_SECRET 则要作为长期配置保存，不要每次重建容器都重新生成。环境变量说明
现在检查配置并启动基础服务。config --quiet 只验证配置，不把包含密码的完整结果打印出来：
docker compose config --quiet
docker compose up -d docmost
docker compose ps
docker compose logs --tail=100 docmost
curl -fsS http://127.0.0.1:3000/api/health
第一次需要拉取镜像和初始化数据库，不必看到浏览器暂时打不开就反复重装。先看容器状态，再看应用日志。日志如需发给别人排查，应遮住密钥、连接字符串和个人信息。
先通过 SSH 隧道创建自己的账号
在你自己的电脑上另开一个终端，执行下面这条命令，而不是在 VPS 的 SSH 会话里执行：
ssh -N -L 3000:127.0.0.1:3000 -l root 198.51.100.10
如果服务器用其他 SSH 用户或端口，修改 -l 后的用户名，并按需增加 -p 参数。保持这个终端运行，然后在本机浏览器打开 http://localhost:3000。访问会经过 SSH 隧道转到服务器，公网并没有开放应用的 3000 端口。
看到初始化页面后，创建工作区和所有者账号。邮箱使用自己能收信的地址，密码放进密码管理器。先写一页临时笔记，再刷新页面确认内容仍在。此时不急着导入全部资料，先证明账号、数据库和基本编辑都正常。
如果本机的 3000 已被其他开发服务占用，可以把隧道左侧端口改成 3300，同时把初始化阶段的 APP_URL 改成 http://localhost:3300，在服务器执行 docker compose up -d docmost 使配置生效，再用相应地址访问。正式域名启用后，这个临时入口就不需要日常使用了。
接上自己的域名和 HTTPS
完成所有者初始化后，到 DNS 服务商那里把 notes.example.com 的 A 记录指向 VPS 的公网 IPv4。如果准备添加 AAAA 记录，就要确认 IPv6 确实可达；一个错误的 AAAA 记录可能让部分设备始终访问失败。第一次部署可以先使用直接解析，确认工作正常后，再决定是否加入 CDN 或其他代理。
在 /opt/docmost/Caddyfile 中写入自己的域名：
notes.example.com {
reverse_proxy docmost:3000
}
再把 .env 中的 APP_URL 改为 https://notes.example.com。它要和最终浏览器使用的地址一致，不能一直保留临时 localhost 地址。然后执行：
cd /opt/docmost
docker compose up -d docmost
docker compose --profile public up -d caddy
docker compose logs --tail=100 caddy
示例里的 Caddy 通过单独的 public profile 启动，因此前面的初始化阶段不会顺带开放 80 和 443。现在需要让这两个 TCP 端口从公网可达，并确认没有其他 Nginx、Apache 或面板服务占用。域名解析、网络和证书签发条件都满足时，Caddy 会申请并维护 HTTPS 证书；申请失败应看日志，不能靠不断重启碰运气。
这里的 docmost:3000 是 Docker 网络中的应用服务。不要在 Caddy 容器里把上游写成 127.0.0.1:3000，那会指向 Caddy 自己。官方也提供了这套 Caddy 反向代理用法。Caddy 部署说明
Docmost 的实时编辑依赖 WebSocket。使用上述 Caddy 反向代理时，无需另写 Nginx 风格的 Upgrade 配置；如果换成其他反代或额外接入网关，要确认 WebSocket 被正确转发。登录页能打开但编辑异常，不能据此断定数据库有问题。反向代理要求
域名访问正常后，用它重新登录，并关闭本地 SSH 隧道。应用仍保留仅监听回环地址的管理入口，不需要再把 3000 开到公网。
不要刚装好就搬进全部笔记
我更建议先选一组有代表性的资料试用：一篇纯文字长文，一篇带中文标题和代码块的技术记录，一篇带表格、图片及附件的项目说明。它们能比十篇空白测试页更快暴露问题。
在两台设备上分别登录，检查同一页是否能继续编辑；上传一张图片，退出账号后重新登录，再看图片是否正常显示。搜索时既试标题，也试正文中的中文词组和英文术语。全文搜索有实际的分词与匹配行为，不应只因为搜到了一个英文标题，就推断自己的中文资料一定好找。
页面组织也可以从小处开始。个人空间里先放“收件箱”“进行中的项目”和“长期参考”三类内容。临时摘录进入收件箱，真正需要反复使用的资料再归档。某篇故障记录至少写清楚发生时的环境、尝试过的操作、最终处理方法和日期，过几个月才有可能凭它重现问题。
分类太细会增加记录成本。只有两篇笔记时不必预设五层目录，一份已经过时的部署说明也不该因为目录整齐就继续被当成现行方案。适当标注适用版本、关联后续页面，比不停移动文件夹更能提高资料的可用性。
有协作者时，先在空间层面核对权限，再邀请成员。不同账号实际能看到什么，要用测试成员登录确认，别只凭管理员视角判断。公开分享也应逐页检查，不应把“只有拿到链接的人才会看”当成访问控制。当前免费版没有付费版那套全局禁用公开分享策略，敏感场景要格外谨慎。
邮件配置影响邀请，也影响以后找回账号
第一次创建所有者不等于邮件通道已经配置完成。邀请同事、找回密码这类动作需要发信能力，长期使用前应把它补上。可以使用已有邮件服务提供的 SMTP，不需要为一套笔记系统再搭一台邮件服务器。
按邮件服务商给出的信息填写 MAIL_DRIVER、SMTP_HOST、SMTP_PORT、SMTP_USERNAME、SMTP_PASSWORD、SMTP_SECURE、MAIL_FROM_ADDRESS 和 MAIL_FROM_NAME，并将这些变量加入 docmost 服务的 environment。例如其中一项可以写成 SMTP_HOST: ${SMTP_HOST:?set SMTP_HOST}，其余依照相同方式引用 .env 中的值。发件地址要符合服务商的验证规则。
SMTP_SECURE 不宜凭“我要安全”就统一写成 true。官方说明里，465 通常使用连接即 TLS，而 587 常使用 STARTTLS，对应的配置不同。按提供商文档填写，然后重新运行 docker compose up -d docmost，让新环境变量进入容器；单纯 restart 不会应用 Compose 环境变量的更改。
测试时应真正触发一次邀请或密码重置，并确认邮件能到达、邮件中的链接使用正式 HTTPS 域名。把“SMTP 参数已经保存”和“可以恢复账号”视为两项不同的检查。没有测试过恢复路径之前，先别删除自己手上最后一个可用的登录会话。
备份要同时覆盖正文和附件
自建笔记最容易产生错觉的地方，是把服务器还在运行当成数据已经安全。磁盘损坏、误操作、账户失窃和到期停机都可能让一个正常使用的实例突然消失。只把备份放在同一块 VPS 磁盘上，解决不了整台服务器不可用的问题。
这套部署至少要保留三类东西：PostgreSQL 数据库、/app/data/storage 里的上传文件，以及 .env、Compose、Caddyfile 这些部署配置。数据库里有页面和账号等记录，文件卷里有图片与附件，密钥和版本配置则帮助你把环境重新接起来。少了附件，可能出现正文还在、图片却全部丢失的情况。
下面是适合小型单机实例的停写备份。它会暂时停止 Docmost，使数据库和附件在备份期间不再被应用修改，Caddy 此时可能返回短暂的 502，应该安排在不用笔记的时候。数据库和 Redis 不停止。先确认镜像已经在本机，备份目标磁盘也有足够空间，在 /opt/docmost 新建 backup.sh：
#!/usr/bin/env bash
set -euo pipefail
umask 077
cd /opt/docmost
backup_root=/opt/docmost-backups
mkdir -p "$backup_root"
backup_dir=$(mktemp -d "$backup_root/backup-$(date -u +%Y%m%dT%H%M%SZ)-XXXXXX")
# 不论备份是否成功，都尝试恢复应用服务。
trap 'docker compose start docmost >/dev/null' EXIT
docker compose stop -t 60 docmost
docker compose exec -T db \
pg_dump -U docmost -d docmost -Fc > "$backup_dir/database.dump"
docker compose run --rm --no-deps -T --user root \
--entrypoint tar docmost \
-C /app/data/storage -czf - . > "$backup_dir/storage.tar.gz"
cp .env compose.yaml Caddyfile "$backup_dir/"
# 这些检查能发现一部分损坏，但不等于完成了恢复演练。
docker compose exec -T db pg_restore --list \
< "$backup_dir/database.dump" > /dev/null
tar -tzf "$backup_dir/storage.tar.gz" > /dev/null
(cd "$backup_dir" && sha256sum \
database.dump storage.tar.gz .env compose.yaml Caddyfile > SHA256SUMS)
printf 'Backup completed: %s\n' "$backup_dir"
确认路径和配置文件都存在后运行：
chmod 700 /opt/docmost/backup.sh
bash /opt/docmost/backup.sh
脚本只适用于这里的单应用实例、本地附件存储方案，不是所有部署形态的通用备份工具。使用外部对象存储时，要把对象存储的备份或版本保留策略另行接上；多副本部署则必须处理所有写入方。Redis 中可能有队列等运行状态，上述备份没有把这些状态纳入完整服务快照，也不保证恢复未完成任务。
备份目录包含数据库和密钥，应加密后复制到另一台机器或可信的备份位置，限制读取权限，并设置合理的保留周期。定时任务不仅要能执行，还要能让你发现失败、磁盘不足和备份过期。每天备份一次，通常意味着故障时仍可能损失最近一天的修改；这个时间窗口是否能接受，需要自己决定。
在另一套环境里恢复一次
有备份文件还不够，至少应该在首次正式迁移前做一次恢复演练。准备另一台测试机器或完全独立的 Compose 项目，使用不同的端口、卷和临时访问地址。不要把恢复测试指向当前正在使用的数据库，也不要在没确认目标的情况下运行清库命令。
恢复时先拿回备份里的配置，用同一个 Docmost 版本和 PostgreSQL 主版本建立环境，保留原来的 APP_SECRET，但把 APP_URL 改为测试地址。只启动数据库和 Redis，保持 Docmost 应用停止。向一份全新的空数据库执行 pg_restore，并把 storage.tar.gz 解压到该测试项目的附件卷，再启动应用，让它读取恢复的数据。
数据库恢复命令的形式如下。这里的文件路径是示例，运行前必须确认当前目录属于新建的恢复项目，目标数据库没有需要保留的数据：
docker compose up -d db redis
# 等待数据库健康后，再导入选定备份。
docker compose exec -T db \
pg_restore -U docmost -d docmost --no-owner --exit-on-error \
< /secure-backup/database.dump
docker compose run --rm --no-deps -T --user root \
--entrypoint tar docmost \
-C /app/data/storage -xzf - < /secure-backup/storage.tar.gz
docker compose up -d docmost
恢复后登录原账号，随机打开几篇新旧笔记，下载一个附件，检查页面树与权限，再试着编辑一段文字并刷新。测试应使用隔离地址，禁用恢复副本的发信配置，避免它误发邀请或通知。暂时不要把正式域名切过去，等确认恢复结果才安排真正的迁移。
Compose 项目名也不能随意改。示例的 name: docmost 参与命名数据卷，更换项目名可能让程序连上一组新卷，从外观看像是笔记突然消失。恢复测试需要主动更换项目名来隔离环境，日常维护则应保持它稳定。尤其不要把带 -v 的 down 命令当作普通重启，那会删除这套项目的数据卷。
从旧工具迁移，先留一条退路
Docmost 支持 Markdown、HTML 等内容的导入导出，也提供针对 Notion 导出包的导入入口。不同来源的格式保真程度需要用自己的资料验证；Confluence、DOCX 等导入能力还涉及版本授权范围，不能只看某一页操作说明就忽略版本差异。导入与导出说明
试迁移时不要只看字数大致相同。链接是否仍指向正确的页面，图片是已经进入新服务器还是继续引用旧站，表格、公式和代码缩进有没有变化，都值得逐一抽查。复杂数据库视图、第三方嵌入内容和特殊块结构，不能预期在换工具后完全原样保留。
迁移完成后保留旧系统一段时间，以及一份未经改动的原始导出包。确认日常检索和写作都适应了，再决定何时停止旧服务。把 Markdown 或 HTML 导出作为额外的可读副本也有价值，但它不能替代数据库和附件备份：账号、权限、历史等系统状态不应指望靠一份可读文档导出完整还原。
升级时只改自己理解的部分
这篇配置固定了 Docmost 版本，便于在升级前明确“现在是什么、准备换成什么”。长期不更新当然不合适，但让全部组件在无人检查时一起追随最新版本，也不适合存放重要资料。
升级前先读目标版本的说明，确认是否要求中间版本、数据库变更或额外操作。完成停写备份后，最好在恢复副本里先试升级。确认无异常，再修改正式 .env 中的 DOCMOST_VERSION，只拉取和重建应用：
docker compose pull docmost
docker compose up -d docmost
docker compose logs --tail=100 docmost
curl -fsS http://127.0.0.1:3000/api/health
健康接口通过以后，还要重复登录、编辑、上传和搜索这些实际操作。升级可能执行数据库迁移，因此“把镜像版本改回去”不一定构成可靠回滚。真正的退路，是升级前的数据库、附件、配置和对应旧镜像版本能够一同恢复。
PostgreSQL 的大版本升级应单独安排，不要和 Docmost 更新顺手混在一起。Redis、Caddy 也需要维护，但应分别核对改动。示例固定了它们的主版本，仍不代表同一标签在未来永远对应同一个镜像；需要更严格的可复现部署时，可以记录镜像摘要。
打不开或写不进去时，按链路排查
域名完全打不开，先查解析是否正确、80 和 443 是否可达，以及 Caddy 是否成功启动。出现 502，则检查 Docmost 容器和应用日志；Caddy 已经能响应，和整个服务器失联是两种问题。
可以登录但无法正常编辑，接着看浏览器里的 WebSocket 连接，特别是中间加过 CDN、面板反代或认证网关的环境。不要一遇到编辑器问题就重置数据库，数据很可能根本没有损坏。
图片上传失败，检查磁盘空间、附件卷权限和上传大小限制，同时看看反向代理是否增加了额外限制。数据库报认证错误，则核对连接串和数据库里的实际密码：一个已经初始化过的 PostgreSQL 卷，不会因为你修改 .env 的 POSTGRES_PASSWORD 就自动修改现有数据库用户密码。
内存紧张时先看 docker stats --no-stream 和系统日志，确认是短时导入造成的压力，还是长期运行已经不够用。不要在不清楚卷用途的情况下执行全局清理命令，也不要用删除数据卷的方法处理启动失败。排查前先保护现有数据，比急着让页面恢复空白可用更重要。
让它成为每天会打开的笔记本
部署完成后的第一周，可以只把一个正在做的项目放进去。每天记一点，隔天试着找回昨天写的内容，在电脑和手机之间来回使用。觉得某个目录不好找就调整，发现一篇说明缺少前提就补齐。经过这些真实使用，再决定是否承接更大规模的旧资料。
需要购买服务器时，可以从 雨云 或 RackNerd 开始比较，按照前面的资源和网络要求选择 Linux VPS。购买只是起点，别忘了给域名与服务器设置续费提醒，也给备份安排一个不依赖原服务器的位置。
等到某一天，你在新电脑上打开自己的域名，很快找到半年前留下的处理记录，照着它解决了眼前的问题，这套云笔记就已经发挥了作用。服务器怎么搭，值得认真做一次；之后的大部分时间，应该留给写下有用的东西。