部署第一个应用

完成后，你的 NAS 上跑着一个能用的 Uptime Kuma，并且你走通了「从模板添加、修改、上线、看日志、停止、删除」的完整流程，之后部署任何应用都是这一套。

选 Uptime Kuma 是因为它简单：一个容器、一个数据目录、一个端口，不用配权限。它怎么用，见导航页与可用性监控。

开始之前

Compose 插件已经装好，设置页里的 Compose 文件、数据、备份、Docker 存储 都已保存并应用，Docker 状态正常。见安装 Docker 与 Compose 插件。
OMV 能访问 GitHub（模板清单从那里读取）和 Docker Hub（拉镜像）。

从模板添加

插件自带约两百个示例，每个都是别人写好的 compose 文件。

打开 服务 → Compose → 文件（Services → Compose → Files）。
点工具栏的添加（Add）菜单，选 从模板添加（Add from Example）。官方中文就叫「从模板」，不是「从示例」。
在搜索框输入 uptime-kuma，选中这一行，点工具栏上的添加（鼠标悬停显示「添加示例 compose 文件」）。
弹窗里名字（Name）默认是 uptime-kuma，保持不变；描述（Description）随便写，比如「可用性监控」。点添加。
提示「示例 compose 文件已添加」后，列表里多了一行 uptime-kuma，状态灯是红色，表示容器还没运行。

名字就是目录名

名字会变成 appdata 下的子目录名，也是以后 omv-compose-run 命令里用的名字。创建后不能改，用小写字母、数字和连字符。

修改，别直接用

选中 uptime-kuma 这一行，点编辑（Edit）。示例（日期 2025-06-01）长这样：

yaml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/uptime-kuma/data:/app/data
    ports:
      - 3001:3001 # Host Port:Container Port
    restart: unless-stopped

对照示例顶部注释里的官方链接，发现两处该改：

镜像版本。Uptime Kuma 官方 README 现在写的是 louislam/uptime-kuma:2（2 是大版本标签），示例里的 :1 是旧的大版本。示例会落后于应用官方文档，这是你以后每个应用都要做的一步：部署前打开示例里的官方链接，对照一遍，示例文件开头的日期越旧越要小心。
数据目录。示例用 CHANGE_TO_COMPOSE_DATA_PATH，会落在 data 共享文件夹里。Uptime Kuma 用 SQLite，放在 SSD 上更快，改成 appdata。官方还特别说明：它不支持 NFS 这类网络文件系统，数据目录必须在本地盘。

改好的版本：

yaml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ${{ sf:"appdata" }}/uptime-kuma/data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

路径里的 sf 是 Compose 插件的占位符写法，保存时被替换成 appdata 共享文件夹的绝对路径，详见写好 compose 文件。
端口映射写成带引号的字符串，这是 Compose 官方规范的建议。
左边的 3001 是 NAS 上的端口，右边是容器里的端口。3001 如果已被占用，改左边，比如 "3101:3001"。先在 服务 → Compose → 端口（Ports）页看一眼哪些端口已被 compose 应用占用。

点保存（Save）。

上线并查看

回到文件列表，选中 uptime-kuma，点检查（check）。对话框里没有红色报错就说明语法没问题。
点上线（up），它执行的是 docker compose up -d。任务对话框会显示拉取镜像、创建容器的过程，第一次要等一会儿。结束后点关闭（Close）。
状态灯变绿，表示容器在运行。
打开浏览器访问 http://<NAS 的 IP>:3001，第一次会让你创建管理员账号。也可以直接点列表里端口列的链接，链接打不开时，在设置页的 URL 主机名 里填 NAS 的 IP。

查看状态和日志：

想看什么	在哪里
容器状态	ps 按钮，或 `服务 → Compose → 服务`（Services）
日志	工具栏工具（Tools）菜单里的日志（logs），或日志跟踪（follow logs）实时看
CPU、内存、网络	`服务 → Compose → 统计`（Stats）

停止、下线与删除

操作	结果	数据
停止（stop）	容器停止，但还在，上线后原样继续	保留
下线（down）	停止并删除容器和这个应用的默认网络	挂载进去的目录保留
删除（Delete）	先对它执行下线，再删除 compose 文件和 OMV 里的这条记录	数据目录不删。`appdata/uptime-kuma/` 里还有 `data` 子目录，所以这个目录会留下
Prune 菜单里的镜像	清理悬空镜像，也就是更新后失去标签的旧镜像，释放空间	不影响数据

注意工具栏上的 Prune 按钮官方中文译成了「删除」，鼠标悬停时看到的就是这个字。它清理的是 Docker 里没用的对象，不是删除你的 compose 文件。这几个清理命令都带 --force，不会再确认：Container 会删掉所有已停止的容器（包括你用「停止」停下的应用，用「上线」可以重建，但容器里没挂载出来的数据会丢），卷只清理没被任何容器使用的匿名卷，命名卷不动。详见更新与备份容器。

检查结果

状态灯是绿色，http://<NAS 的 IP>:3001 能打开。
在 OMV 的 shell 里以 root 身份运行 omv-compose-run uptime-kuma ps，能看到 uptime-kuma 状态是 running。omv-compose-run 是插件 8.2.0 起提供的命令，它用和界面一样的参数调用 docker compose，日志写在 /var/log/omv-compose-run.log。
在 appdata/uptime-kuma/data 里有数据库文件，说明数据确实落在你设定的目录里，而不是容器内部。
找机会重启一次 NAS，确认容器自己回来了。回不来，见重启后容器没起来。

常见问题

「从模板添加」列表是空的。 插件运行时从 GitHub 读取示例清单，OMV 访问不了 GitHub 时清单就是空的。先在 OMV 的 shell 里检查网络和 DNS。临时的办法是用添加手动粘贴 compose 文件。

保存时提示「请设置共享文件夹用于数据存储」。 示例里用了 CHANGE_TO_COMPOSE_DATA_PATH，但设置页的数据没有选共享文件夹。选上，或者把示例里的路径改成 sf 占位符。

上线失败，提示 port is already allocated 或 address already in use。 NAS 上的这个端口已经被别的东西占了。改映射左边的端口，排查见端口冲突。

容器启动后马上退出，或者反复重启。 先看日志。常见原因是目录权限不对或配置写错，见容器启动失败。

拉取镜像很慢或超时。 镜像来自 Docker Hub 或 ghcr.io。网络访问这些站点受限时，需要自己准备代理或镜像加速，这超出本文范围。

部署第一个应用 ​

开始之前 ​

从模板添加 ​

修改，别直接用 ​

上线并查看 ​

停止、下线与删除 ​

检查结果 ​

常见问题 ​

参考资料 ​