如何把n8n部署到线上：Hugging Face + Supabase篇
用初学者能跟上的方式，理解容器平台、外部数据库和 n8n 密钥如何配合；完成在线原型，并避开休眠、持久化和连接配置的常见误区。
这一篇的目标不是让你“抄一套免费方案就永久不用管”，而是让你真正看懂线上 n8n 的三个部件：容器负责运行，数据库负责保存，密钥负责保护凭据。 理解这三件事后，无论以后你换 VPS、NAS 还是托管服务，都会更容易。
先把边界说清楚：Hugging Face 的 Docker Space 可以运行自定义容器，但官方文档说明，运行计算的 Space 需要满足相应账户/套餐条件；免费硬件会在闲置后休眠；Docker Space 本地磁盘在重启后不持久。Hugging Face Spaces Overview Docker Spaces 同时，Supabase Free Plan 的低活跃项目可能自动暂停。Supabase Project Pausing
因此，本文是在线原型教程。适合学习、演示和测试；不适合承诺 24 小时不停的关键 Webhook、订单通知或客户业务。
先认识每个部件在做什么
| 部件 | 白话解释 | 如果它停了会怎样 |
|---|---|---|
| Hugging Face Docker Space | 放 n8n 程序的“线上电脑” | 编辑器、Webhook 与任务都停下来 |
| Supabase PostgreSQL | 保存工作流和执行信息的“数据库仓库” | n8n 无法读取自己的数据 |
N8N_ENCRYPTION_KEY |
给已保存凭据上锁的“总钥匙” | 丢失后旧凭据可能无法解密 |
N8N_WEBHOOK_URL |
告诉外部服务“应该敲哪扇门”的地址 | Webhook 可能登记成错误地址 |
第 0 步：确认你适合做这个实验
如果你的目标是“先了解线上部署”，可以继续；如果你要接收支付、客户表单或绝不能漏掉的定时任务，请直接选择 VPS 或托管服务。不要通过频繁请求平台来“保活”，那既不可靠，也可能违反平台规则。
第 1 步：创建 Supabase 项目
打开 Supabase，创建一个 PostgreSQL 项目。这里的每个项目都是一套独立数据库。设置强数据库密码后，等待项目初始化完成，再点击 Connect 获取连接信息。
这一步成功的标志： 你能在控制台看到项目状态为正常运行，并且 Connect 页面显示主机、端口、数据库名和用户信息。
对长期运行的后端，Supabase 文档建议使用适合运行环境的连接方式；当运行平台仅支持 IPv4 时，可使用 Shared Pooler 的 session mode。Supabase 数据库连接指南 不要自己猜主机和端口，直接复制控制台给出的对应模式。
如果你看不到 Connect： 先确认项目已创建完成；不同界面可能把连接信息放在顶部 Connect 按钮、Database Settings 或项目设置中。页面名称会变，但核心信息始终是主机、端口、数据库名、用户和密码。
第 2 步：创建 Docker Space
在 Hugging Face 新建 Space，选择 Docker。Docker Space 用仓库里的 README.md 顶部 YAML 告诉平台“这是 Docker 项目，公开端口是多少”。创建 README.md 时可使用：
---
title: n8n Prototype
sdk: docker
app_port: 7860
---
接着创建 Dockerfile。下面代码的意思是：从 n8n 官方镜像开始，让 n8n 听平台公开的 7860 端口；它没有写入任何密码。
FROM docker.n8n.io/n8nio/n8n:stable
ENV N8N_LISTEN_ADDRESS=0.0.0.0
ENV N8N_PORT=7860
EXPOSE 7860
提交文件后等待构建。成功的标志： Space 状态从 Building 变为 Running，打开公开链接时不再看到构建错误。
如果停在 Building： 打开 Logs，先检查 Dockerfile 的拼写、镜像是否写对、端口是否和 app_port 一致。不要为了让构建通过而把数据库密码放进 Dockerfile。
第 3 步：把密码放进 Settings 的 Secrets
Hugging Face Docker Space 支持运行时 Secrets，平台会把它们提供给容器，而不会要求你把密码提交进仓库。Docker Spaces：Secrets 与 Variables
在 Space 的 Settings 中添加以下值。尖括号只是提示，必须换成你自己的内容。
| 名称 | 填什么 | 它在做什么 |
|---|---|---|
DB_TYPE |
postgresdb |
告诉 n8n 不要用默认 SQLite，改用 PostgreSQL |
DB_POSTGRESDB_HOST |
Supabase Connect 页面里的主机 | 告诉 n8n 数据库在哪里 |
DB_POSTGRESDB_PORT |
Connect 页面里的端口 | 告诉 n8n 走哪条连接通道 |
DB_POSTGRESDB_DATABASE |
控制台给出的数据库名 | 指定要使用的数据库 |
DB_POSTGRESDB_USER |
Connect 页面里的用户 | 登录数据库的账号 |
DB_POSTGRESDB_PASSWORD |
你创建项目时设置的密码 | 登录数据库的密码 |
DB_POSTGRESDB_SSL_ENABLED |
true |
要求走加密连接 |
N8N_ENCRYPTION_KEY |
一串长期保存的随机值 | 加密 n8n 中保存的凭据 |
N8N_WEBHOOK_URL |
你的 Space 公开 HTTPS 地址 | 生成正确的 Webhook 地址 |
N8N_PROXY_HOPS |
1 |
让 n8n 正确理解平台前面的代理 |
n8n 官方支持用 DB_TYPE=postgresdb 和 DB_POSTGRESDB_* 变量配置 PostgreSQL。n8n 数据库变量参考 当 n8n 放在反向代理后时，应设置 N8N_WEBHOOK_URL 和 N8N_PROXY_HOPS=1。n8n Webhook 反向代理说明
如果教程里的变量和你看到的不一样： 优先使用 n8n 当前官方文档中的变量名；例如现在应优先使用 N8N_WEBHOOK_URL，而不是旧教程常写的 WEBHOOK_URL。
第 4 步：第一次启动后怎么检查
打开 Space 的公开地址，创建 n8n owner 账户，然后只做三个小测试：
- 建一个 Manual Trigger → Set 工作流并运行。看到绿色成功状态，说明编辑器和执行器正常。
- 新建一个测试 Webhook，用浏览器或 HTTP 工具访问它。看到 n8n 收到请求，说明地址配置正常。
- 新建一个很简单的 Schedule Trigger，观察它在平台未休眠时是否执行。这里的目的是理解行为，不是证明它适合生产。
跟教程不一样时，按顺序排查
| 现象 | 最可能原因 | 先检查什么 |
|---|---|---|
| Space 显示 Running 但页面打不开 | 端口不一致或 n8n 未监听公网地址 | app_port、N8N_PORT、构建日志 |
| n8n 提示数据库连接失败 | 主机/端口/用户复制错误，或连接模式不匹配 | Supabase Connect 页面、SSL、IPv4/IPv6 |
| Webhook 地址不对 | 外部 URL 未正确设置 | N8N_WEBHOOK_URL 是否为完整 HTTPS 地址 |
| 重启后本地文件不见 | Docker Space 本地盘不持久 | 不把重要数据放本地盘；使用外部数据库/存储 |
| 一段时间后任务不跑 | Space 休眠或 Supabase 项目暂停 | 查看平台状态；关键任务迁移 VPS |
| 旧凭据打不开 | 加密密钥换了或丢失 | 恢复原 N8N_ENCRYPTION_KEY |
常见问题与排障汇总
为什么数据库连接后仍然要保存加密密钥？ 数据库保存的是工作流与凭据数据，密钥负责解密其中受保护的内容；两者缺一不可。
为什么 n8n 能打开但 Webhook 不工作？ 编辑器能打开只说明网页服务正常，不代表外部服务知道正确回调地址。先看 n8n 显示的生产 Webhook URL 是否就是 Space 的 HTTPS 域名。
为什么不建议把密码写进 README 或 Dockerfile？ 仓库历史会保存提交记录。即使后来删除，密钥也可能已经泄露。密码应放平台 Secrets，并尽量使用独立、可轮换的值。
什么时候必须迁移？ 当流程涉及真实订单、客户数据、必须按时执行的任务，或者你发现自己在和休眠、暂停、临时 URL 反复斗争时，就应该迁移到稳定 VPS 或托管服务。
小结
这个原型的价值在于让你亲手搭起“容器运行 n8n、外部数据库保存状态、Secrets 保存敏感配置、HTTPS 地址接收 Webhook”的完整链路。它不是终点，而是理解线上部署的训练场。下一篇会用 VPS、Docker Compose 和 PostgreSQL 把这些知识变成可长期维护的运行环境。