用 Docker 部署 IT-Tools 在线工具箱

格式化 JSON、解码 URL、换算时间戳，可以放在同一个 IT-Tools 页面里完成。自建后有了固定地址，不过处理敏感材料前，仍要检查具体工具和浏览器是否会把输入发到别处。

先跑一个回环地址上的实例

服务器已有 Docker 和 Compose，并由宿主机 Caddy 承接域名时，可以在独立目录保存：

services:
  it-tools:
    image: corentinth/it-tools:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:3010:80"

这是官方镜像的常用部署方式；latest 是变化的标签，上线后记录实际镜像摘要，升级先看发行说明。首次启动前确认宿主机 3010 未被占用：

docker compose config --quiet
docker compose up -d
docker compose logs --tail=100

工具箱的浏览器输入不是通过保存 Compose 就被备份。是否留有持久化业务数据，要按所用工具核对，别把容器存在当成历史输入被永久保存。

在宿主机 Caddy 中增加站点，替换实际域名：

tools.example.com {
    reverse_proxy 127.0.0.1:3010
}

先验证配置再重载。个人或团队内部使用时，可采用现有的访问控制方案；匿名窗口单独检查入口范围。代理也在容器中的部署，应使用共享网络与服务名。

选择不含秘密的 JSON、URL 和时间戳，核对解析、编码和时区结果。JWT 被解码只能看见内容，不能说明签名有效或权限足够；哈希工具也不能自动成为安全的密码存储方案。

不要把 API 密钥、数据库凭据或整份生产环境文件作为随手测试材料。处理敏感数据之前，查看具体工具与页面行为；浏览器扩展和外部资源同样可能影响输入范围。

维护时保存部署配置、镜像标识和入口规则。升级后重复几份常用样本，并从手机或其他正常使用环境检查页面，不只看容器 running。

已有低负载服务器，可以先用独立端口与统一代理部署，不必为了工具箱单独租一台。首次自建或现有资源不足时，按Docker 应用选购确认架构、内存和访问方式。上线以后用固定样本验证工具结果，而不是只看首页是否打开。

只跑私人工具箱，可先从小型 Linux 实例试部署，公网使用时重点是 HTTPS、访问限制和到使用者的网络。自行维护、预算优先可看 RackNerd 的 VPS 套餐；打算与其他容器统一管理，可看雨云 RCS 的系统与面板。不要把工具箱、数据库和几个后台服务的合计用量，都按单个网页的启动占用估算。