内容摘要
在 NAS 上用 Docker Compose 部署 n8n，关键是将宿主机 ./data 挂载到容器 /home/node/.n8n，保存数据库与配置，避免容器重建或更新后工作流丢失。部署时还需固定 N8N_ENCRYPTION_KEY，否则既有凭证无法解密，并配置访问认证、Webhook 地址及目录权限。启动后检查日志、登录界面并运行测试工作流；若数据消失，应核对卷路径、密钥、权限和端口。定期备份 data 目录可增强保障，数据量较大或多用户场景也可考虑 PostgreSQL 或 MySQL。
— 此摘要由AI分析文章内容生成，仅供参考。

在 NAS 上用 Docker 部署 n8n，听起来并不复杂，但不少用户在实际操作中都会遇到同一个问题：容器跑起来了，配置也完成了，结果重启容器或者更新镜像之后，之前辛辛苦苦搭好的工作流、凭证和设置全部丢失，仿佛一切从头来过。这种情况通常不是因为 n8n 本身不稳定，而是部署时忽略了几个关键的配置关系。

这篇文章会从项目目录结构开始，把持久化数据、环境变量和访问验证这几块内容串联起来，给出一个在 NAS 上可执行、可复用的部署流程，并重点说明如何避免容器重建后配置丢失。

部署前的准备：理解 n8n 的数据存储方式

n8n 默认把工作流、凭证、执行历史等数据存储在 SQLite 数据库中。如果容器被删除，这个数据库文件也会跟着消失。持久化的核心思路，就是把这个数据库文件以及 n8n 的配置文件、密钥等，从容器内部映射到 NAS 宿主机的文件系统上。

在开始部署之前，建议在 NAS 的文件管理器里创建一个专用的项目目录。例如，在 Docker 共享文件夹下新建 n8n 目录，并在其中创建 data 子目录。这个 data 文件夹就是 n8n 所有持久化数据的最终落脚点。

部署流程：从 docker-compose 到容器启动

使用 Docker Compose 是管理 n8n 最清晰的方式，尤其是当你需要在不同 NAS 设备上复现相同配置时。以下是一个基础但完整的 docker-compose.yml 示例，它已经包含了持久化卷挂载和环境变量配置。

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    volumes:
      - ./data:/home/node/.n8n
      - ./local-files:/files
    environment:
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=你的安全密码
      - N8N_HOST=你的NAS本地IP:5678
      - N8N_PROTOCOL=http
      - N8N_PORT=5678
      - N8N_ENCRYPTION_KEY=一个随机生成的32位以上字符串
      - WEBHOOK_URL=http://你的NAS本地IP:5678/

逐一解释关键部分：

  • volumes：./data:/home/node/.n8n 是持久化的核心。n8n 默认将数据库和配置文件存储在容器内的 /home/node/.n8n 目录，将其映射到宿主机的 ./data 目录后，无论容器如何重建，数据都会保留在 NAS 硬盘上。另外映射了一个 ./local-files:/files，方便 n8n 工作流读取或写入 NAS 上的本地文件。
  • N8N_ENCRYPTION_KEY：这是最容易忽略但极其重要的变量。n8n 使用该密钥加密凭证（如数据库密码、API Token）。如果容器重建后没有使用相同的密钥，n8n 将无法解密已有的凭证，导致工作流执行失败。 生成一个随机字符串并妥善保存，之后每次部署都使用同一个值。
  • N8N_BASIC_AUTH_*：为 n8n 的 Web 界面设置基本的用户名和密码认证，防止未授权访问。
  • WEBHOOK_URL：如果你计划使用 n8n 的 Webhook 节点接收外部请求，这个变量必须设置为你 NAS 的本地 IP 和端口，否则外部请求可能无法正确路由。

在 NAS 的 SSH 终端或 Portainer 的 Stack 功能中，将上述内容保存为 docker-compose.yml 并执行 docker compose up -d，n8n 就会在后台启动。

验证部署：从日志到界面访问

容器启动后，先检查日志确认没有错误：

docker logs n8n

正常的日志末尾会显示 n8n 正在监听 5678 端口。随后，在浏览器中输入 http://你的NAS本地IP:5678，应该能见到 n8n 的登录界面，使用你在环境变量中设置的用户名和密码登录。

此时可以做一个快速验证：创建一个最简单的测试工作流（比如一个 Webhook 节点加一个 Set 节点），保存并执行一次，确认一切正常。

排错思路：容器重建后配置丢失怎么办

如果你发现容器重建后 n8n 变成了一个全新的实例，或者登录后看不到之前的工作流，可以从以下几个方面排查：

  1. 检查卷挂载路径：确认 docker-compose.yml 中的宿主机路径是否正确。进入 NAS 的 ./data 目录，查看是否存在 database.sqlite 文件。如果该文件不存在，说明持久化没有生效。
  1. 确认加密密钥一致性：如果 N8N_ENCRYPTION_KEY 在重建时被改变或未设置，n8n 会认为这是一个全新的实例，并生成新的加密密钥，导致无法读取旧数据。务必在每次部署时使用完全相同的密钥。
  1. 文件权限问题：NAS 上的 Docker 服务默认以特定用户（如 uid:1000）运行。如果 ./data 目录的权限不允许该用户写入，n8n 可能无法正确保存数据。在 NAS 的文件管理器中将 data 目录的所有者设置为 nobody 或直接赋予 777 权限（临时测试用），可以快速定位这类问题。
  1. 端口冲突：如果 5678 端口已被其他容器占用，n8n 会启动失败。可以通过 docker ps 查看端口占用情况，或在 ports 配置中更换宿主机端口，例如 "5679:5678"。

进阶建议：让 n8n 更稳定地运行

如果你对数据安全有更高要求，可以考虑将 SQLite 替换为 PostgreSQL 或 MySQL，这在多用户场景或数据量较大时性能更优。只需在 environment 中添加 DB_TYPE=postgresdb 以及对应的数据库连接变量，并额外部署一个数据库容器即可。

另外，NAS 系统（如群晖、威联通、飞牛）通常自带定时任务功能，可以设置定期备份 ./data 目录到另一个存储池或云盘，为你的自动化工作流增加一道保险。

在 NAS 上运行 n8n 并不需要复杂的云端架构，只要理清持久化、密钥和权限这三者之间的关系，就能轻松实现工作流的稳定运行与安全迁移。

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。