用持久化 SQLite 容器部署并验收 Mealie

Mealie 项目文档团队原作。本文合并译写官方《Installation Checklist》与《SQLite (Recommended)》，按 2026 年 10 月 5 日读取的正文整理。示例镜像为 v3.28.0，这不是对当前最新版本的判断。原文未给出首次发表日期。

把容器启动起来只是安装过程的一部分。要在自己的服务器上可靠使用 Mealie，还要选好数据库、保存 Compose 配置和持久化数据，核对邮件及站点地址，并在管理页面完成配置验收。

先选择部署方式

官方建议在本地网络中通过 Docker 部署 GitHub Container Registry 上的镜像，使用配套 Docker Compose 模板，再修改所需的默认值。数据库可以选 SQLite（默认）或 PostgreSQL；对于多数用途，SQLite 已经够用。Mealie 提供自动备份和恢复功能，也便于日后在两种数据库之间迁移。

镜像支持 linux/amd64 和 linux/arm64。由于构建依赖的限制，不支持 32 位 ARM 系统；较新的 Raspberry Pi 如果遇到这个限制，应考虑使用 64 位操作系统。准备好 Docker 和 Docker Compose 后再继续。

SQLite 是开源、自包含、无需单独配置服务的数据库。官方把它作为约 1–20 名用户、并发写入较少时的合适选择。若有大量并发用户，可以考虑 PostgreSQL；模糊搜索等部分功能也只在 PostgreSQL 下启用。

不要将 SQLite 数据库放在网络附加存储（NAS）上。配套文档明确警告：SQLite 并非为这种用法设计，可能发生数据损坏或数据库锁定错误。计划使用网络附加存储时，应改用 PostgreSQL 部署方案。

准备部署目录与文件

原文的目录安排在 Ubuntu 20.04 上测试过，作者认为也适用于大多数 Linux 发行版。这种组织方式不是强制要求；下面保留原文命令，本文未实际执行。

1. 通过 SSH 登录服务器，进入准备运行 Mealie 的用户主目录；若就是当前用户，可运行 cd ~。
2. 按需要创建 Docker 服务的总目录：mkdir docker && cd docker。
3. 创建本服务的目录：mkdir mealie && cd mealie。
4. 建立配置文件：touch docker-compose.yaml。
5. 使用 nano docker-compose.yaml 或 vi docker-compose.yaml 编辑文件，把所选部署类型的完整模板放进去。

SQLite 的完整 Compose 示例

以下代码来自官方 SQLite 配套页。保留版本、端口、内存上限、数据卷和环境变量，只将解释性注释改为中文。

services:
  mealie:
    image: ghcr.io/mealie-recipes/mealie:v3.28.0
    container_name: mealie
    restart: always
    ports:
        - "9925:9000"
    deploy:
      resources:
        limits:
          memory: 1000M
    volumes:
      - mealie-data:/app/data/
    environment:
      # 在这里设置后端环境变量
      ALLOW_SIGNUP: "false"
      PUID: 1000
      PGID: 1000
      TZ: America/Anchorage
      BASE_URL: https://mealie.yourdomain.com

volumes:
  mealie-data:

界面通过容器的 9000 端口提供。模板将它映射到主机的 9925 端口，主机端口可以按环境调整。mealie-data 命名卷挂载到容器的 /app/data/，承载持久化数据。PUID、PGID、时区和站点地址也应与实际部署匹配。

官方建议显式设置内存上限：在内存很多的主机上，Python 可能预分配超过实际需要的内存，造成容器空闲时仍占用较多内存。模板中的上限为 1000M。

首次部署前，原文建议检查项目 README 顶部的 latest release 标记，确认具体版本标签是否过时，格式应为 vX.Y.Z。虽然有 latest，项目团队更建议固定版本，在有时间阅读发行说明并处理必要迁移步骤时再主动升级。

启动前逐项核对

根据安装清单，配置文件准备好后还要核对四类设置。

• 数据库选择对应的环境变量是否正确。
• SMTP 服务器是否已配置。邀请邮件、重置密码等功能需要它；使用 Gmail 时，原文提及可以配置 Google 应用专用密码。
• BASE_URL 是否已经设成实际站点地址。
• DEFAULT_EMAIL、DEFAULT_GROUP 和 DEFAULT_HOUSEHOLD 是否已核对并设置。

这些可选项并未全部列在上面的最小模板中，具体变量说明见官方后端配置页。不要把示例域名、用户标识和时区原样当成自己的环境配置。

启动并在管理页验收

在 docker-compose.yaml 所在目录启动服务：

docker compose up -d

原文预期容器能无错误启动，并可在 http://localhost:9925 打开前端。这里的 localhost 指运行服务的主机；从另一台设备访问时，需要使用那台主机的实际地址。

文档给出的初始登录凭据为：

• 用户名：changeme@example.com
• 密码：MyPassword

原文提醒，默认用户名相较旧版本已经改变。首次登录后进入 /admin/site-settings，逐项查看配置细节和状态。页面若出现警告或错误，会提示需要核查的设置；应先处理这些问题，再继续使用。

编者安全说明：以上是公开的默认凭据，不是安全的长期配置，应立即修改。模板的 9925:9000 没有限定监听为回环地址；BASE_URL 写成 HTTPS 也不等于容器已配置 TLS。公开暴露前应另行完成认证、访问控制和 HTTPS 部署。本次仅静态检查，没有启动容器、验证端口、发送邮件或测试登录。

数据卷之外，还要有离机备份

原文强调：即使版本在数据稳定性和安全性方面有所进步，应用本身也不是备份。Mealie 可通过界面生成整站数据备份。备份是普通 ZIP 文件，可以从界面下载，也可以在主机挂载的数据卷中取得。

要真正保护数据，必须把备份保存到当前服务器之外的安全位置。保存在同一主机上的数据卷和 ZIP，不能应对整台服务器失效。

旧版 v1 部署迁移

安装清单还保留了从旧 nightly 拆分容器或 omni 镜像迁移的说明。Mealie 后来采用单容器部署；若仍使用旧结构，原文给出的顺序是：

1. 先做备份。
2. 将原 API 容器的镜像改为 ghcr.io/mealie-recipes/mealie:v3.28.0。
3. 把原前端容器对外使用的主机端口，映射到新容器的 9000 端口；新前端从这里提供服务。
4. 重启容器，并对照新的 SQLite 或 PostgreSQL Compose 示例检查配置。

这是源文保留的历史迁移语境，不能理解为所有旧版本都可在未经检查的情况下直接升级成功。

镜像标签如何选择

• ghcr.io/mealie-recipes/mealie:nightly：随 mealie-next 分支提交构建，可能包含缺陷，适合协助提前发现问题。
• ghcr.io/mealie-recipes/mealie:<version>：固定到一个发布版本，便于自己决定升级时间。
• ghcr.io/mealie-recipes/mealie:latest：指向最新发布的镜像。

旧的 mealie:frontend-v1.0.0beta-x、mealie:api-v1.0.0beta-x 以及 mealie:frontend-nightly、mealie:api-nightly 标签已不再更新。原页下方仍留有它们过去的说明，本文按页面“已不再更新”的提示解释，不把历史推荐当作当前部署建议。

来源：Mealie Installation Checklist；Installing with SQLite。作者归属保留为 Mealie 项目文档团队。