最近在 Ubuntu 24.04 上重新把 n8n 的工作流自动化服务完整部署了一遍包括把界面切换成中文版整个过程用 Docker Compose 串联起来配置干净维护也省心。这篇文章就把我从零开始的操作步骤、关键配置、踩过的坑全部记录下来给需要在 Linux 服务器上自托管 n8n 的开发者、自动化爱好者和运维朋友一个可以直接照做的参考方案。先说结论n8n 本身就已经内置了中文界面严格来说不存在“中文版”这种独立发行版。所谓“中文版”其实只需要在部署阶段设置好默认语言或者在初次登录后手动切换就行。很多人一搜“中文版 n8n”会以为是某个汉化过的镜像其实完全没必要官方镜像就自带多语言。我这次部署过程中真正值得花心思的是 Docker Compose 的编排、数据库选择、时区设置、数据持久化和后续的备份升级这些才是决定能不能长期稳定运行的关键。1. 方案选型为什么是 Ubuntu 24.04 Docker Compose1.1 n8n 是干什么的n8n 是一个开源的工作流自动化工具简单理解就是一个可以自己部署的 Zapier。它把各种应用和服务通过节点连接起来比如定时抓取网页、发送邮件、调用大模型接口、同步表格数据、推送企业微信消息都能靠工作流组合完成。和 SaaS 平台相比数据完全掌握在自己手里没有按执行次数收费的压力节点和接口也没有那么多限制。尤其在国内使用不用考虑平台服务不可达的问题这对依赖 Webhook 和定时任务的人来说非常重要。我用 n8n 已经有一段时间了最常见的用途是把内部系统之间的重复操作串起来。比如某个系统生成报表后自动触发 n8n 工作流把数据整理后推送到企业群里再比如每天定时拉取第三方 API 的数据清洗后写进数据库。这些事如果纯手工用脚本做每个都要单独维护一套任务调度和环境用 n8n 统一管理之后可视化界面里就能看到整个执行链路出问题也好排查。1.2 部署方式对比原生安装、Docker 还是 Docker Compose在 Ubuntu 24.04 上部署 n8n基本有三条路可以走。第一种是直接安装 Node.js 然后运行 npx n8n这种方式对版本管理不友好Node 版本一变就可能出兼容问题而且 n8n 升级后要回滚很麻烦。第二种是用单个 docker run 命令启动容器这种方式已经比原生安装好很多但参数全堆在命令行里可读性差服务和数据库的关系还得额外手动管理。第三种就是用 Docker Compose这也是我最终选择的方案。Docker Compose 的好处在于把整个服务栈用 YAML 文件描述清楚包含 n8n 应用和 PostgreSQL 数据库只要一条docker compose up -d就能全部拉起。配置可以版本化管理换服务器的时候拷走配置文件就能复现同样的环境。更实际的是Compose 能管理服务依赖关系比如等数据库健康检查通过后再启动 n8n避免服务启动顺序导致连接失败的问题。1.3 数据库选型为什么不用默认的 SQLite这里有一个很多人忽略的细节n8n 默认使用 SQLite。如果只是个人测试SQLite 完全够用文件型数据库零配置备份直接复制文件就行。但一旦工作流数量增多、执行频率变高或者同一个 n8n 实例要供多个人使用SQLite 的并发写入能力很快就会捉襟见肘。改用一个单独的 PostgreSQL 容器和 n8n 容器一起编排进同一个 Compose 文件是目前比较合理的生产级配置。PostgreSQL 的并发处理能力、事务支持和备份工具生态都远好于 SQLite而且后续如果要部署 n8n 的高可用集群PostgreSQL 也是必要条件。代价无非是多一个容器内存占用多一点但这和稳定性比起来完全值得。对比项SQLitePostgreSQL部署复杂度零配置需要一个额外容器并发能力弱写锁竞争明显强适合多人同时使用数据备份复制文件即可pg_dump 导出支持定时备份适用场景本地实验、单用户小项目生产环境、多用户、高频率执行升级迁移简单更方便工具链成熟2. 环境准备Ubuntu 24.04 基础配置与 Docker 安装2.1 系统初始化与必要依赖我用的是一台 Ubuntu 24.04 LTS 的服务器纯净系统没有装过 Docker。准备工作从更新软件源和升级现有软件包开始。sudo apt update sudo apt upgrade -y这一步看起来基础但很重要。24.04 作为一个 LTS 版本软件包更新频率不算高定期升级可以避免系统自带软件和 Docker 源之间出现依赖冲突。接着安装一些基础工具比如 curl 和 ca-certificates后面添加 Docker 官方软件源的时候会用到。sudo apt install -y ca-certificates curl2.2 安装 Docker 与 Compose 插件安装 Docker 有两种常用思路。一种是直接装 Ubuntu 软件源里的 docker.io胜在省事但版本一般偏旧Docker Compose v2 插件可能不完整。另一种是添加 Docker 官方软件源安装 docker-ce我推荐这种版本新和官方文档的对齐程度高。先把 Docker 官方的 GPG 密钥下载并保存到系统钥匙环里这样 apt 才能验证软件包签名。sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg然后根据系统版本写入 Docker 软件源地址。Ubuntu 24.04 的版本代号会通过VERSION_CODENAME自动读取不需要手工修改。echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null软件源配置好之后更新索引并安装 Docker Engine 全家桶其中就包含 docker-compose-plugin。sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完成后把当前用户加入 docker 组这样操作 docker 命令时就不用每次都加 sudo。sudo usermod -aG docker $USER提示执行完 usermod 之后需要重新登录一次让组权限生效。如果不想重新登录可以用newgrp docker临时切换当前会话。验证安装是否成功docker --version docker compose version能看到 Docker 和 Compose 版本号输出说明环境已经就绪。3. 核心配置docker-compose.yml 逐段拆解3.1 目录规划与配置文件骨架我习惯把所有服务放在一个独立目录里这样无论是备份还是清理都边界清晰。mkdir -p ~/n8n-deploy cd ~/n8n-deploy在目录里创建 docker-compose.yml整个服务栈就由两个容器组成postgres 负责数据存储n8n 负责应用逻辑。services: postgres: image: postgres:16 restart: unless-stopped environment: POSTGRES_USER: n8n POSTGRES_PASSWORD: change_this_to_a_strong_password POSTGRES_DB: n8n volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U n8n -d n8n] interval: 10s timeout: 5s retries: 5 n8n: image: n8nio/n8n:latest restart: unless-stopped depends_on: postgres: condition: service_healthy environment: DB_TYPE: postgresdb DB_POSTGRESDB_HOST: postgres DB_POSTGRESDB_PORT: 5432 DB_POSTGRESDB_USER: n8n DB_POSTGRESDB_PASSWORD: change_this_to_a_strong_password DB_POSTGRESDB_DATABASE: n8n N8N_DEFAULT_LOCALE: zh TZ: Asia/Shanghai GENERIC_TIMEZONE: Asia/Shanghai ports: - 5678:5678 volumes: - n8n_data:/home/node/.n8n volumes: postgres_data: n8n_data:新版 Docker Compose 不再需要写version字段写了也不影响运行但不写更干净。你需要在配置里把change_this_to_a_strong_password替换成自己的强密码并且保证 postgres 和 n8n 两处的密码完全一致。3.2 PostgreSQL 容器配置要点postgres 容器用的是 postgres:16这个版本是当前社区兼容性很好的版本。环境变量中POSTGRES_USER、POSTGRES_PASSWORD、POSTGRES_DB三个参数决定 PostgreSQL 初始化时创建的用户、密码和数据库名。这三个值要和后面 n8n 容器连接数据库时填写的完全对应否则 n8n 启动时会报认证失败。restart: unless-stopped保证服务器重启后容器自动拉起除非你手动 stop这个策略适合常驻服务。数据卷postgres_data挂载到/var/lib/postgresql/data这行配置必须有否则容器一删数据库数据就全没了。健康检查用的命令是pg_isready -U n8n -d n8n这段逻辑很简单就是探测 PostgreSQL 是否已经准备好接受连接。配合 n8n 服务的depends_on.condition: service_healthy可以确保 PostgreSQL 完全启动后再启动 n8n从根源上避免“数据库没起来n8n 疯狂报连接错误后退出”的情况。3.3 n8n 容器配置与中文化设置n8n 镜像我写了n8nio/n8n:latest最省心。如果追求版本可控可以改成具体版本号比如n8nio/n8n:1.60.0升级时手动修改版本号再重新部署。对于大多数人latest 足够更新走docker compose pull docker compose up -d就行。环境变量里分成几组核心参数。数据库连接组DB_TYPEpostgresdb告诉 n8n 不要用默认的 SQLiteDB_POSTGRESDB_HOSTpostgres是因为 Compose 会自动创建一个内部网络服务名postgres可以直接解析为那个容器的 IP其他几项就是数据库端口、用户、密码和库名和 PostgreSQL 容器里的配置保持一致。中文化设置组N8N_DEFAULT_LOCALEzh是让 n8n 首次启动就使用简体中文作为默认语言。如果你忘记设置这一项也不要紧登录之后在用户设置里还能手动切换。这里需要注意语言代码是zh不是zh-CN之类写错可能导致设置不生效。设置这个环境变量之后如果发现界面还是英文通常是浏览器语言优先级或旧版本缓存问题强制刷新一次浏览器基本能解决。时区设置组TZAsia/Shanghai影响的是容器内部系统时区GENERIC_TIMEZONEAsia/Shanghai影响的是 n8n 内部的时间处理逻辑。如果不设置GENERIC_TIMEZONE定时触发节点 Schedule Trigger 可能会按 UTC 时间执行导致你想象中早上 8 点执行的任务实际在下午 4 点才跑。这是很多人部署后最容易忽略的问题。端口映射5678:5678将宿主机的 5678 端口转发到容器内的 n8n 默认端口。n8n 的官方默认端口就是 5678如果你本机已经占用了这个端口可以把左边改成任意未占用的端口比如5678:5678改为8080:5678访问时就用对应端口。3.4 数据卷与权限经验配置末尾声明了两个数据卷postgres_data和n8n_data。命名卷会由 Docker 创建并管理首次启动时自动初始化目录。这里我推荐使用命名卷而不是直接挂载宿主机目录原因是权限问题经常在直接挂载时出现。n8n 容器内部的运行用户是 node它的 UID 是 1000。如果用宿主机的目录挂载到/home/node/.n8n一旦目录所有者不是 UID 1000n8n 容器会因为没有目录写权限而启动失败。命名卷则完全避开这个坑Docker 会规范化权限所以个人部署场景选择命名卷是最稳妥的。4. 启动部署从命令到中文界面落地4.1 一键拉起服务与日志观察在~/n8n-deploy目录里执行docker compose up -d-d参数表示后台运行首次执行时 docker 会拉取 postgres:16 和 n8nio/n8n 两个镜像视网络情况可能需要几十秒到几分钟。如果拉取镜像特别慢大概率是 Docker Hub 网络问题可以给 Docker 配置 registry mirror 镜像源来加快下载速度。启动完成后用下面的命令确认服务状态docker compose ps正常情况下两个容器都应该是 Up 状态而且 postgres 的 HEALTHY 健康状态会在启动后十几秒内变为 healthy。如果想实时观察 n8n 容器的日志用docker compose logs -f n8n看到日志里出现类似服务启动成功、端口监听的输出就说明 n8n 已经正常运行了。此时打开浏览器访问http://你的服务器IP:5678如果是在本地虚拟机部署访问http://localhost:5678即可。4.2 首次访问与管理员账号注册首次访问 n8n 页面会出现一个用户注册表单。按照页面提示填写邮箱、姓名和密码创建的就是 n8n 的管理员账号。这一步只需要认真设置一个足够强度的密码就行后续的数据库连接、节点认证都走工作流内的凭据配置和这个账号无关。完成注册后进入 n8n 主界面这时候页面默认显示的语言取决于镜像内部默认值。如果你设置了N8N_DEFAULT_LOCALEzh界面直接就是中文如果没设置或者不生效接下来手动切一次即可。4.3 手动切换为中文版界面点击右上角的用户头像在弹出的菜单里进入 Settings 设置页找到 Language 语言选项在下拉框里选择中文简体保存后页面会自动刷新整个工作台界面会切换成中文。这是 n8n 原生的多语言功能不需要额外安装任何汉化包也不需要更换镜像。注意n8n 的中文翻译由社区持续维护大部分核心界面和常见节点都有完整翻译但个别比较新的节点或高级设置项可能仍显示英文这属于正常现象。对实际使用基本没有阻碍。4.4 验证工作流能正常执行部署完成不代表一切正常我习惯在初始化配置之后立即创建一个最小工作流验证链路通畅。比如用 Manual Trigger 手动触发节点作为起点连接一个 Set 设置数据节点再连一个 NoOp 空操作节点手动运行一次看执行结果是否成功。这样能确认 n8n 应用本身没问题而不至于等到需要真正跑业务时才发现某个底层组件有问题。如果执行日志正常说明 n8n 和 PostgreSQL 的交互、前端渲染、工作流引擎都正常工作。到这一步一套完整的中文 n8n 服务已经跑起来了。5. 对外访问反向代理与 HTTPS 配置5.1 三种常见访问方式部署完成后默认通过http://IP:5678访问这种方式适合内网实验环境。但如果 n8n 需要接收外部 Webhook或者要通过手机在外网访问继续用 IP 加端口的方式就有些局限。日常使用中还可以配置一个反向代理域名让 n8n 跑在标准的 443 端口并自动启用 HTTPS。三种方式简单对比如下方式优点缺点适用场景直接 IP:5678配置简单零额外操作无加密Webhook 地址不好看内网测试、个人实验Nginx 反向代理灵活可控性好证书申请与管理要自己处理已有 Nginx 环境的用户Caddy 反向代理自动申请和续期 HTTPS 证书需要额外安装 Caddy追求省心的朋友5.2 Caddy 反向代理示例Caddy 配置很简单可以自动申请 Let’s Encrypt 证书your.domain.com { reverse_proxy 127.0.0.1:5678 }这种情况下最好把 docker-compose.yml 里 n8n 的端口映射改为只监听本机回环地址避免 5678 端口暴露到公网减少被扫描的风险。ports: - 127.0.0.1:5678:5678改了端口映射之后执行docker compose up -d重新创建容器然后启动 Caddy 服务访问https://your.domain.com就能直接打开 n8n。5.3 配置域名后需要同步修改的环境变量一旦使用域名访问建议在 n8n 环境变量中补上N8N_HOST、N8N_PROTOCOL和WEBHOOK_URL让 n8n 生成的回调地址和 Webhook 地址跟着域名走。N8N_HOST: your.domain.com N8N_PROTOCOL: https WEBHOOK_URL: https://your.domain.com/不设置的话工作流里的 Webhook 节点生成的外部地址可能是http://你的IP:5678这种形式发给第三方系统后对方无法通过 HTTPS 回调用。这个细节在对接外部系统时非常容易踩中建议一步到位配好。6. 常见问题排查与日常维护6.1 常见问题速查表部署过程中最常遇到的问题我整理成一张速查表遇到对应现象直接对照处理。现象可能原因排查与解决方法n8n 容器启动后立即退出数据库密码不一致或数据库未就绪用docker compose logs n8n查看报错确认两个服务的密码一致访问 5678 端口超时云安全组或 UFW 防火墙未放行执行sudo ufw allow 5678/tcp并检查云控制台安全组规则页面长时间英文切换语言无效浏览器缓存了旧版本前端资源强制刷新浏览器或清除站点缓存后重新加载定时任务执行时间差 8 小时缺少GENERIC_TIMEZONE环境变量在 n8n 环境变量中补上GENERIC_TIMEZONE: Asia/Shanghai后重建容器数据库数据随容器删除而丢失未配置数据卷或误删了命名卷查看docker volume ls确认卷存在用docker compose down -v会清空数据慎用镜像拉取速度极慢Docker Hub 网络延迟配置 Docker registry mirror 镜像源后重启 Docker6.2 数据备份与恢复备份是部署完必须立刻考虑的事否则数据丢了才后悔。n8n 的业务数据都保存在 PostgreSQL 里所以最核心的备份是导出一个 SQL 文件。cd ~/n8n-deploy docker compose exec postgres pg_dump -U n8n -d n8n n8n_backup_$(date %F).sql这条命令会在当前目录生成一个以当天日期命名的 SQL 备份文件。恢复时把备份文件复制到服务器上执行docker compose exec -T postgres psql -U n8n -d n8n n8n_backup_2025-01-01.sql实际操作前建议先让 n8n 停止对外写入比如docker compose stop n8n恢复完成后再启动避免数据不一致。除了数据库n8n 的~/.n8n目录里还保存了部分配置文件和一些本地文件所以除了 pg_dump 之外也建议把 n8n_data 卷里的内容打包一份。6.3 升级和回滚n8n 的新版本发布频率相当高一些安全问题和新节点都依赖版本更新所以我会定期升级。升级流程很简单cd ~/n8n-deploy docker compose pull docker compose up -d升级前一定先做一次数据库备份。因为新版本可能包含数据库迁移逻辑迁移一旦失败或者出现不兼容没有备份就只能干瞪眼。升级后观察日志确认工作流的执行没有异样再清理旧镜像docker image prune -f如果升级后发现功能异常可以在 docker-compose.yml 里把镜像 tag 改回上一个版本号然后重新docker compose up -d回滚操作同样依赖之前那个备份文件。6.4 一点经验体会这套 deployment 跑下来我最大的感受是 Docker Compose 把 n8n 的部署复杂度压到了最低但真正决定一个自动化服务能否长期稳定运行的不是那一条启动命令而是部署前对数据持久化、时区、语言、端口暴露、备份策略的考虑是否到位。我个人比较习惯在 compose 文件旁边放一个 README记录部署时间、管理员邮箱、数据卷名称、上一次备份的路径。因为 n8n 这种自托管服务往往不会天天去操作它等半年后需要升级时这些记录能帮你快速回忆当时的部署决策。另外强烈建议启用 Docker 的restart策略配合服务器的进程守护保证断电重启后服务能自动恢复。自动化工具的使命就是省心部署完之后它越安静说明你做得越对。