私人日记不想散落在多个App？我用DailyTxT把记录、搜索和图片都放进自己的NAS

前言

日记、随手记和私人备忘最容易遇到的矛盾，是"随时能写"和"数据放在哪里"很难同时兼顾。云笔记用起来方便，但如果内容本身比较私人，很多人还是更希望把服务放在自己的NAS里，账号、数据目录和访问入口都由自己维护。

这次我把 DailyTxT 部署到极空间，先通过SSH确认Docker环境，再用Docker Compose把服务映射到8755端口，并把数据目录挂载出来。

本地页面跑通以后，我继续完成注册登录、日记记录、按日期查看、关键词搜索、图片上传和收藏标记，确认它不只是"容器启动成功"。

最后再给8755增加外部访问入口，从随机公网地址切换到固定二级子域名。整篇重点不是把"自托管"写成绝对安全，而是把极空间 → DailyTxT → 本地数据 → 日记功能 → 远程访问这条链完整跑通，同时把SECRET_KEY、开放注册和公网访问之间的安全边界说清楚。

这类私人记录工具真正值得自己部署的地方，也不只是"页面在家里跑"，而是账号、数据目录和访问入口可以放进同一套维护逻辑里。以后换设备时只需要进入同一个DailyTxT，不必把日记散落在多个App里；但这种便利也意味着备份和权限不能再完全交给平台替你负责。

1 DailyTxT适合解决什么问题

DailyTxT更适合被理解成：

一套可以自己部署的轻量日记Web服务。

它适合这些场景：

想把日记放在自己的NAS或服务器里；
希望通过浏览器记录；
需要按日期查看；
需要关键词搜索；
需要上传图片；
想给重点内容做收藏或标记；
希望多设备访问同一套日记。

它的价值不是"绝对不会泄露"。

而是：

服务运行在哪里、数据目录放在哪里、谁能访问，由自己决定得更多。

2 这篇真正要跑通哪些内容

整个过程可以拆成三段。

第一段：

极空间 → SSH → Docker

第二段：

Docker Compose → DailyTxT → 8755 → 注册 / 登录 / 日记

第三段：

外部设备 → 公网地址 → DailyTxT:8755

先确认本地日记服务可用，再处理远程访问。

3 先通过SSH进入极空间

开启SSH以后，从终端连接：

shell 复制代码

ssh root@IP

页面：

后面的Docker命令都通过SSH执行。

4 验证Docker环境

执行：

shell 复制代码

docker -v 
systemctl status -v

页面：

确认Docker环境正常以后，再创建DailyTxT目录。

5 创建DailyTxT部署目录

执行：

shell 复制代码

mkdir -p /docker/dailytxt

cd /docker/dailytxt

结果：

这次目录使用：

/docker/dailytxt

后面的Compose配置和数据目录都围绕这里保存。

6 创建docker-compose.yml

配置保持如下：

shell 复制代码

version: '3'

services:
  dailytxt:
    image: phitux/dailytxt:latest
    container_name: dailytxt
    restart: always
    ports:
      - 8755:8755
    volumes:
      - ./data:/app/data/
    environment:
      - PORT=8755
      - SECRET_KEY=你的秘钥
      - ALLOW_REGISTRATION=True
      - DATA_INDENT=2
      - JWT_EXP_DAYS=60

这里最关键的参数包括：

镜像：phitux/dailytxt:latest
容器名：dailytxt
端口：8755:8755
数据目录：./data:/app/data/
PORT=8755
SECRET_KEY=你的秘钥
ALLOW_REGISTRATION=True
DATA_INDENT=2
JWT_EXP_DAYS=60

7 数据目录映射为什么重要

Compose里把：

./data

映射到：

/app/data/

目的就是把DailyTxT的数据放在极空间本地目录里，而不是只留在容器内部。

这样后面即使容器需要重建，数据和容器本身也不是完全绑在一起。

不过，自托管并不等于自动备份。

如果日记比较重要，仍然需要单独考虑：

磁盘故障；
数据目录备份；
容器升级；
文件损坏；
误删除。

8 SECRET_KEY不要随便填写固定示例

这份配置里需要设置：

SECRET_KEY

生成方式保持如下：

shell 复制代码

openssl rand -base64 32

这个值不适合：

直接写成文章里的统一密码；
多台服务重复使用同一个值；
发到公开仓库；
截图暴露。

更稳妥的做法是每套部署单独生成并保存好。

同时也要注意：

仅仅看到有SECRET_KEY这个变量，不能直接推导出"所有日记内容都绝对安全、绝对加密"。

它只是当前应用安全配置中的一部分。

9 当前配置仍然允许注册

这份Compose里保留的是：

ALLOW_REGISTRATION=True

也就是说，按这套配置运行时，注册入口是开启的。

如果服务只在局域网里使用，这个风险相对容易控制。

但如果后面把DailyTxT开放到公网，就不能一边保持开放注册，一边又默认认为"只有自己能用"。

所以远程访问前，至少要重新确认：

是否还需要开放注册；
已创建账号的密码是否足够强；
是否需要进一步限制访问范围。

本文不改这份已经跑通的Compose参数，但把这个边界单独说明。

10 启动DailyTxT

执行：

shell 复制代码

docker-compose up -d

结果：

容器启动以后，下一步直接从浏览器验证8755。

11 浏览器打开DailyTxT

访问：

http://极空间IP:8755

页面：

能够正常看到登录界面以后，可以确认：

浏览器 → 极空间8755 → DailyTxT

已经跑通。

12 第一次使用先注册账号

页面：

完成注册以后，再用自己的账号登录。

这一层真正决定的是：

谁能进入自己的日记页面。

如果后面准备公网使用，账号密码不要继续停留在测试强度。

13 开始写第一篇日记

登录以后进入编辑页面：

这一步验证的是最核心的功能：

DailyTxT能够正常保存文字内容。

14 按日期查看已经记录的内容

写完以后，对应日期会出现标记。

页面：

点击具体日期，就可以查看那一天的记录。

这种按日期组织的方式，比把所有内容混在一份长文档里更适合长期写日记。

15 关键词搜索

继续测试：

当记录越来越多以后，搜索能力会比手动翻日期更有价值。

尤其适合找：

某个人名；
某个项目；
某次旅行；
某个事件；
某个关键词。

16 日记里还可以上传图片

页面：

这样记录就不只是纯文字。

照片、截图或其他图片可以和当天内容放在一起。

不过图片一多，数据目录体积也会继续增加。

所以备份DailyTxT时，不要只想着文字数据。

17 收藏和重点标记

页面：

对重要内容做收藏以后，后面查找会更直接。

这一层更适合：

纪念日；
重要决定；
工作复盘；
长期目标；
需要反复回看的内容。

18 本地使用到这里已经跑通

现在已经完成：

极空间Docker → DailyTxT → 8755 → 注册 → 登录 → 日记 → 搜索 → 图片 → 收藏

如果只在家里局域网使用，做到这里已经够了。

后面的步骤只解决：

人在外面怎么继续打开这套DailyTxT。

19 私人日记做公网访问，比普通工具更要谨慎

DailyTxT里面可能记录：

私人情绪；
家庭信息；
工作内容；
联系人；
图片；
账号或事件线索。

所以公网访问不能只看：

"能不能打开页面。"

还要同时关注：

是否继续开放注册；
账号密码强度；
SECRET_KEY是否妥善保存；
公网地址传播范围；
数据目录备份；
应用自身认证是否足够。

cpolar解决的是网络入口。

它不会替代DailyTxT本身的账号和应用安全。

20 安装cpolar

执行：

shell 复制代码

sudo curl https://get.cpolar.sh | sh

结果：

然后检查服务状态：

shell 复制代码

sudo systemctl status cpolar

结果：

确认服务正常以后，再进入cpolar管理页面。

21 打开cpolar Web UI

浏览器访问：

极空间IP:9200

页面：

登录以后开始创建DailyTxT隧道。

22 给8755创建HTTP隧道

创建参数：

隧道名称：daily
协议：HTTP
本地地址：8755
域名类型：随机域名
地区：China Top

页面：

这里映射的是DailyTxT实际使用的8755端口。

23 先用随机公网地址验证

进入在线隧道列表：

从其他网络打开生成的地址：

能够正常进入DailyTxT以后，可以确认：

外部浏览器 → 公网地址 → 极空间8755 → DailyTxT

已经跑通。

24 随机地址适合先测试

随机地址更适合确认：

公网访问链到底通不通。

如果只是偶尔外部查看日记，这一步已经可以使用。

如果准备长期在手机、平板、电脑上记录，再继续配置固定二级子域名。

25 保留固定二级子域名

进入预留页面：

这次示例名称：

dailyy

页面：

实际使用时，以自己账号最终成功保留的名称为准。

26 编辑DailyTxT隧道

回到隧道列表：

进入编辑。

修改：

域名类型：二级子域名；
Sub Domain：已经保留的名称；
地区：China Top。

更新：

27 查看固定地址是否生效

进入在线隧道列表：

可以看到原来的随机地址已经切换成固定二级子域名。

28 最后从外部设备再访问一次

使用固定地址打开：

页面能够正常进入以后，长期远程入口完成。

整条链已经变成：

外部设备 → 固定公网地址 → 极空间8755 → DailyTxT → 本地数据目录

29 固定地址解决的是"入口不变"

固定二级子域名主要解决：

手机长期收藏；
平板长期使用；
电脑不需要反复查新地址；
多设备统一入口。

它解决的是：

访问地址稳定。

并不代表：

账号自动安全；
注册自动关闭；
日记内容自动获得额外加密；
数据自动完成备份；
地址可以随意公开。

30 自托管日记真正带来的是什么

更准确的理解不是：

"放到NAS以后绝对安全。"

而是：

日记服务和数据目录运行在自己的设备里，存储、备份和访问入口由自己掌握得更多。

控制权增加以后，责任也会一起增加。

包括：

维护Docker；
管理账号；
备份数据；
保护SECRET_KEY；
控制公网入口；
处理应用升级。

31 这套方案更适合什么人

比较适合：

已经有NAS；
希望自己托管日记；
想通过浏览器多设备访问；
不想把所有私人记录放在第三方笔记平台；
能接受自己维护Docker和备份。

如果只是偶尔记几句话，又不想维护服务，本地备忘录可能已经够用。

DailyTxT真正体现价值，通常是在：

记录频率增加，同时又希望数据放在自己的设备里。

32 最后把完整技术链重新看一遍

基础环境：

极空间 → SSH → Docker

部署：

Docker Compose → DailyTxT

端口：

8755:8755

数据：

./data → /app/data/

安全相关参数：

SECRET_KEY / ALLOW_REGISTRATION / JWT_EXP_DAYS

本地功能：

注册 → 登录 → 日记 → 日期 → 搜索 → 图片 → 收藏

随机远程：

公网随机地址 → 8755

固定远程：

固定二级子域名 → 8755

实际完成：

SSH连接；
Docker检查；
DailyTxT目录；
Compose配置；
SECRET_KEY生成；
容器启动；
8755本地访问；
用户注册；
日记记录；
日期查看；
关键词搜索；
图片上传；
收藏标记；
cpolar安装；
随机公网访问；
固定二级子域名；
外部设备访问。

这样DailyTxT才真正从"容器已经启动"，变成一套可以长期记录、搜索，并通过多设备访问的自托管日记服务。

总结

这次真正跑通的是一条完整的DailyTxT使用链：先在极空间确认SSH和Docker环境，通过Docker Compose把服务运行在8755端口，并把./data映射到容器里的/app/data/，让日记数据和容器本身分开保存。

本地功能验证没有停在登录页，而是继续完成注册、日记记录、按日期查看、关键词搜索、图片上传和收藏标记。这样才能确认DailyTxT已经真正承担起日常记录，而不是单纯"Docker显示Up"。

远程部分是在本地功能正常以后再增加的能力。随机公网地址先验证链路，固定二级子域名再解决长期多设备访问时入口变化的问题；但当前Compose里仍然保留ALLOW_REGISTRATION=True，所以公网使用时不能默认认为注册已经关闭。

自托管带来的核心是更多控制权，不是绝对安全。SECRET_KEY、账号密码、数据备份、开放注册和公网入口仍然需要一起管理。对于私人日记这类敏感内容，能不能远程打开只是第一步，真正值得长期维护的是整套数据和访问边界。