在 Fly.io 上自托管 Convex Backend:从零部署到生产环境的完整指南
数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载导读本指南以仓库中 self-hosted/advanced/fly/README.md 为骨架完整讲解如何将 Convex 后端backend、管理面板dashboard与前端应用部署到 Fly.io 这一 PaaS 平台。你将掌握通过fly launch创建应用、配置CONVEX_CLOUD_ORIGIN/CONVEX_SITE_ORIGIN环境变量、生成 admin key、用convexCLI 推送函数代码以及针对 SQLite 数据卷、HTTP Actions 路由和资源调优的完整实战方案。部署全景自托管 Convex 的三个组成部分自托管 Convex 需要部署三个服务见 self-hosted/README.mdConvex backend运行全部数据库与计算函数的核心服务Convex dashboard用于查看日志、读写数据、运行函数的可视化管理面板你的前端应用可以自己托管也可以放在 Netlify、Vercel 等托管服务上。仓库在self-hosted/advanced/fly/目录下预先为 backend 与 dashboard 各准备了一份fly.toml配置backend/fly.toml 与 dashboard/fly.toml让部署到 Fly.io 的过程几乎零门槛。下文将按 backend → dashboard → 前端应用 的顺序逐步展开。准备阶段获取 Fly 配置文件与安装 CLI1. 拷贝 fly 配置目录原文档推荐使用degit一个从 Git 仓库拷贝文件的工具将self-hosted/advanced/fly目录复制到本地可以放在任何位置不一定要放进你的项目目录npx degit get-convex/convex-backend/self-hosted/fly fly cd fly说明上述命令从上游 GitHub 仓库拉取。如果无法访问外部网络也可以直接从当前仓库手动拷贝self-hosted/advanced/fly/下的backend/与dashboard/两个子目录。拷贝后你会得到两个子目录fly/backend/包含部署 Convex backend 的 fly.tomlfly/dashboard/包含部署 Convex dashboard 的 fly.toml。2. 安装 Fly CLI按 Fly.io 官方文档安装flyctlFly CLI。安装完成后可以用fly version验证是否可用。部署 Convex Backend 到 Fly.io原文档特别强调所谓部署在 Convex 语境下有两层含义——一是把 Convex backend 的 Docker 镜像部署到 Fly.io二是把你应用里的 Convex functions 部署到运行 Convex 的那台 Fly machine 上。本节处理第一层。第一步创建 Fly 应用cd backend fly launch交互式提示时选择y将仓库自带的fly.toml配置复制到新应用。如果使用 Postgres 或 MySQL 作为数据库建议将primary_region修改为与数据库相同的区域以降低跨区域网络延迟。部署成功后终端会打印应用 URL形如https://app-name.fly.dev。原文档将其记为fly-backend-url后续所有环境变量配置都会用到它。读懂 backend 的 fly.toml关键配置项仓库自带的 backend/fly.toml 是一份可直接运行的基准配置逐段解读如下app convex-backend primary_region iad [build] # 改为 :${REV} 可以固定到特定版本 image ghcr.io/get-convex/convex-backend:latest [env] TMPDIR /convex/data/tmp [[mounts]] source convex_data destination /convex/data [http_service] internal_port 3210 force_https true auto_stop_machines stop auto_start_machines true min_machines_running 1 processes [app] [[http_service.checks]] interval 5s timeout 30s grace_period 5s method GET path /version protocol http [[vm]] memory 1gb cpu_kind shared cpus 4app/primary_region应用名与首选区域默认iad即美国弗吉尼亚北部。[build].image直接使用 Convex 官方发布的 backend 镜像ghcr.io/get-convex/convex-backend:latest。若想锁定版本可将latest改为具体的镜像 tag如:${REV}。[[mounts]]将名为convex_data的 Fly volume 挂载到容器内/convex/data。这是 SQLite 数据库与文件存储的持久化位置详见下文数据库小节。[http_service]backend 对外的 HTTP 服务监听容器内3210端口强制 HTTPSauto_stop_machines stop配合min_machines_running 1意味着空闲时机器可停止、但至少保留一台运行auto_start_machines true保证请求到达时自动拉起。[[http_service.checks]]Fly 每 5 秒对/version路径发起一次健康检查超时 30 秒、宽限期 5 秒用于判定实例是否存活。该路径由 backend 自身提供可作为部署成功的验证点。[[vm]]默认分配 1GB 内存、4 个共享 CPU是 Fly 上能跑起来的最小资源适合起步生产环境建议按负载调大见故障排查。第二步设置环境变量CONVEX_CLOUD_ORIGIN与CONVEX_SITE_ORIGIN这两个环境变量告诉 backend 它自己被托管在什么地址backend 据此生成指向自身的 URL例如存储链接、action 回调地址等。在 Convex functions 内部可以通过process.env.CONVEX_CLOUD_URL获取 Convex 客户端 API 地址通过process.env.CONVEX_SITE_URL获取 HTTP API 地址。方式一写入 fly.toml 的[env]段[env] TMPDIR /convex/data/tmp CONVEX_CLOUD_ORIGIN fly-backend-url CONVEX_SITE_ORIGIN fly-backend-url/http修改后重新部署生效fly deploy方式二存为 Fly secrets如果不希望把变量明文留在 fly.toml 中例如多人共用同一个已提交到版本库的 fly.toml但各自有独立的 Fly backend可以用fly secrets set写入fly secrets set CONVEX_CLOUD_ORIGINfly-backend-url CONVEX_SITE_ORIGINfly-backend-url/http从源码看这两个变量的去向查看 run_backend.sh 可以发现容器启动脚本会把它们映射为 backend 二进制convex-local-backend的两个命令行参数--convex-origin $CONVEX_CLOUD_ORIGIN \ --convex-site $CONVEX_SITE_ORIGIN \脚本注释写得很清楚--port与--site-proxy-port是容器内部端口--convex-origin与--convex-site才是外部世界访问 backend 的方式它们会出现在存储 URL、action 回调等地方。这也是为什么CONVEX_SITE_ORIGIN要带上/http后缀——backend 的 HTTP API 正是挂在站点路径的/http之下下文HTTP Actions会再次印证。这个机制对注册 webhook 的库以及 Convex Auth 生成 auth 回调地址尤其重要。第三步验证 backend 运行浏览器访问fly-backend-url应看到提示 backend 正在运行的消息。若访问失败用fly logs查看日志定位问题。也可以直接请求/version端点检查健康检查是否通过。第四步生成 admin keyadmin key 用于授权convexCLI 和访问 dashboard通过容器内的生成脚本获得fly ssh console --command ./generate_admin_key.sh从源码看该脚本generate_admin_key.sh会读取实例凭据read_credentials.sh中的INSTANCE_NAME与INSTANCE_SECRET调用generate_key工具输出 admin key 字符串。请妥善保存此 key——忘记后可随时用同一条命令重新生成。第五步在应用项目里配置.env.local进入使用 Convex 的应用目录创建.env.local不要提交到版本控制CONVEX_SELF_HOSTED_URLfly-backend-url CONVEX_SELF_HOSTED_ADMIN_KEYyour-admin-key第六步部署 Convex functions如果项目还没安装 Convexcd your-frontend-app-directory npm install convexlatest开发模式持续部署npx convex dev会在你编辑代码时持续把函数推送到 backend同时自动在.env.local写入前端所需的变量如VITE_CONVEX_URL。一次性部署npx convex deploy --env-file path to env file部署到其他 backend通过--env-file指定不同环境文件或在调用npx convex deploy前先设置好自托管环境变量CONVEX_SELF_HOSTED_URL与CONVEX_SELF_HOSTED_ADMIN_KEY。关于开发与生产backend 实例本身并不区分开发/生产区别只取决于你调用npx convex dev实时更新还是npx convex deploy一次性推送。利用这一特性你可以通过不同的环境变量组合为 staging 或 preview 创建多个 backend。HTTP Actions 的路由规则HTTP actions 运行在 Fly 应用 URL 的/http路径之下。示例Fly 应用部署在https://self-hosted-backend.fly.dev你的 HTTP action 路由到/sendEmail实际访问地址为https://self-hosted-backend.fly.dev/http/sendEmail。这正好解释了上文CONVEX_SITE_ORIGIN fly-backend-url/http的由来site 源即 HTTP API 的根路径。从 run_backend.sh 可以看到容器内--port 3210对应主服务、--site-proxy-port 3211对应 site 代理fly.toml 中http_service.internal_port 3210与之对应。数据存储SQLite、Fly Volume 与 Postgres/MySQL 切换默认情况下所有数据存放在本地 SQLite 数据库中文件存放在 Fly volume 的文件系统里。登录容器即可看到数据目录fly ssh console ls数据实际落在data目录/convex/data其中db.sqlite3是 SQLite 数据库文件见 run_backend.sh 中SQLITE_DB${SQLITE_DB:-$DATA_DIR/db.sqlite3}的默认值storage是文件存储目录tmp是临时目录。它们都通过 fly.toml 的[[mounts]]挂载到持久化 volumeconvex_data上因此重启/重建机器数据不会丢失。若要将数据迁移到独立的 SQL 数据库Postgres 或 MySQL可参考仓库中的 postgres_or_mysql.md。从 run_backend.sh 的源码可以看出设置POSTGRES_URL或MYSQL_URL环境变量后脚本会自动切换为--db postgres-v5/--db mysql-v5驱动并传入连接串需要额外存储容量时可参考 s3_storage.md 配置 S3 存储。部署 Dashboarddashboard 用于查看日志、读写数据、运行函数等支持本地 Docker 运行或部署到 Fly.io。本地运行docker run -e NEXT_PUBLIC_DEPLOYMENT_URLfly-backend-url -p 6791:6791 ghcr.io/get-convex/convex-dashboard:latest部署到 Fly.io进入拷贝自仓库的 dashboard 目录cd dashboard用 backend URL 部署。写入 fly.toml的方式fly launch -e NEXT_PUBLIC_DEPLOYMENT_URLfly-backend-url存为 secret的方式适合多人共用已入库的 fly.toml、各自部署独立 dashboard 的场景fly launch fly secrets set NEXT_PUBLIC_DEPLOYMENT_URLfly-backend-url部署完成后即可访问 fly 输出的 dashboard URL。仓库自带的 dashboard/fly.toml 中dashboard 容器内部监听6791端口与本地 Docker 运行时的-p 6791:6791一致对外暴露 80/443 端口并强制 HTTPS默认分配 1GB 内存、1 个共享 CPU。登录访问 dashboard 后输入前面生成的 admin key。建议把 key 存入密码管理器以便随时取用忘记时可通过fly ssh console --command ./generate_admin_key.sh重新生成。登录成功后即可看到你的表、函数、日志等信息。部署前端应用Convex backend 只运行数据库与计算函数并不托管你的 Web 应用。如果前端托管在 Netlify、Vercel 等服务上请参考 self-hosted/README.md 中的部署说明关键点在于不要设置CONVEX_DEPLOY_KEY而是把环境变量替换为自托管对应的CONVEX_SELF_HOSTED_URLbackend 的 URL与CONVEX_SELF_HOSTED_ADMIN_KEY用generate_admin_key.sh生成的 admin key。故障排查与资源调优原文档提供了两个最常见的性能/容量问题及建议性能问题默认 fly 配置只分配能跑起来的最小资源backend 为 1GB 内存 4 共享 CPU见 backend/fly.toml。高负载下可能遇到 Fly 的限流和性能不佳建议增大内存与 CPU——修改 fly.toml 的[[vm]]段后fly deploy即可。磁盘空间不足默认配置给convex_datavolume 分配 1GB 空间SQLite 数据库与存储都放在这里。空间不足时用fly volume extend扩容。其他进阶调优手段还包括参考 knobs.md 调整 backend 内部可调参数、参考 benchmarking.md 进行压测评估、参考 upgrading.md 升级自托管版本等这些文档均位于 self-hosted/advanced 目录下。小结至此你已经完成了 Fly.io 上的完整自托管链路backend含 SQLite 数据卷与/version健康检查→ 环境变量与 admin key →convexCLI 推送函数 → HTTP Actions 路由 → dashboard 登录管理 → 前端应用接入。核心要点可归纳为用CONVEX_CLOUD_ORIGIN/CONVEX_SITE_ORIGIN让 backend 认识自己的外部地址对应源码中的--convex-origin/--convex-site参数用.env.local中的CONVEX_SELF_HOSTED_URL/CONVEX_SELF_HOSTED_ADMIN_KEY让 CLI 认识你的 backend再根据负载与容量需求随时调整 fly.toml 资源与 volume 大小。赞分享数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载相关推荐Convex Backend 项目中的 Convex Auth 集成指南从初始化到生产环境部署Convex Backend 项目中的 Convex Auth 集成指南从初始化到生产环境部署 Convex Auth 是 Convex 内置的原生认证方案数据库后端3步搞定PostHog自托管部署从零到生产环境的完整实战指南3步搞定PostHog自托管部署从零到生产环境的完整实战指南 还在为产品数据分析工具的高昂费用发愁想拥有完全可控的私有化分析平台却担心部署复杂度PostH数据分析后端前端数据可视化大数据Selenium Manager架构解析分布式浏览器驱动管理的智能化实现Selenium Manager架构解析分布式浏览器驱动管理的智能化实现 Selenium Manager作为Selenium生态系统的核心组件通过智能化的后端前端Web框架开发工具创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考