将 InsForge 自托管到 DokployCompose 应用部署完整指南【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge本文介绍如何在自己的服务器上通过 Dokploy 这个开源 PaaS 平台自托管 InsForge——一个面向 Agent 编程的一站式开源后端平台数据库、认证、存储、计算、托管与 AI 网关。你将学会以 Compose 应用的形式完成创建应用、配置密钥、绑定域名与首次部署的全流程并理解仓库为何在部署时构建 Postgres 与 Deno 镜像而非直接拉取预构建镜像。读完本文你可以独立在 Dokploy 上搭建一套生产可用的 InsForge 实例并掌握后续更新与存储扩展的正确姿势。注意这里部署的是 InsForge 平台本身而不是你用 InsForge 构建的应用。如果只是想让你用 InsForge 开发的应用上线请参考 Sites 概览。前置条件开始之前你需要准备两样东西一个 Dokploy 实例Dokploy 是一个运行在你自己服务器上的开源 PaaS一个解析到该服务器的域名或子域名整个部署栈Postgres、PostgREST、Deno 运行时默认都不向宿主发布端口全部留在 Dokploy 的内部网络中因此一个可用于路由的域名是访问面板的前提。1. 创建 Compose 应用在 Dokploy 控制台中选择Create → Compose把本仓库设为 provider然后填写字段值Compose Pathdeploy/dokploy/docker-compose.ymlCompose TypeDocker Compose仓库中对应的 Compose 文件位于 deploy/dokploy/docker-compose.yml它定义了四个服务postgres从仓库构建的 PostgreSQL 镜像承载 InsForge 的全部业务数据postgrestpostgrest/postgrest:v12.2.12把数据库表暴露为 REST APIinsforgeghcr.io/insforge/insforge-oss:latest后端主服务与面板工作目录/app端口7130deno从仓库构建的 Deno function host运行 Serverless 边缘函数端口7133。2. 环境变量在 Dokploy 的Environment标签页里设置以下变量。除特别说明外每个密钥都用openssl rand -hex 32生成JWT_SECRET32 characters ENCRYPTION_KEY32 characters, different from JWT_SECRET POSTGRES_PASSWORDstrong password ROOT_ADMIN_USERNAMEadmin ROOT_ADMIN_PASSWORDstrong password两个密钥之间的关系务必重视ENCRYPTION_KEY如果不设置会回退到JWT_SECRET。这一点在源码中有明确实现见 backend/src/infra/security/encryption.manager.ts其中const key process.env.ENCRYPTION_KEY || process.env.JWT_SECRET;并在缺少ENCRYPTION_KEY时打印警告明确提示轮换 JWT_SECRET 而不设置独立的 ENCRYPTION_KEY 会损坏所有已存密钥。后果是一旦JWT_SECRET轮换所有已加密存储的密钥API Key、OAuth token 等将永久无法解密。所以现在就应该给ENCRYPTION_KEY一个独立于JWT_SECRET的值。POSTGRES_PASSWORD 的生效时机Postgres 只在初始化数据簇initdb时读取POSTGRES_PASSWORD。数据卷创建之后再修改这个值不会改变数据库的实际密码。如果你确实需要更换数据库密码必须连同DATABASE_URL即insforge服务的POSTGRES_PASSWORD一起改并考虑数据卷的处理。必填校验的硬性保障在 deploy/dokploy/docker-compose.yml 中可以看到ENCRYPTION_KEY使用了 Compose 的${VAR:?error}必填语法JWT_SECRET、ROOT_ADMIN_PASSWORD同样如此例如ENCRYPTION_KEY: ${ENCRYPTION_KEY:?set ENCRYPTION_KEY in Dokploy Environment - openssl rand -hex 32, must differ from JWT_SECRET}这意味着缺少这些变量时部署会在启动前直接失败并给出明确提示而不是用一个占位符悄悄运行——避免产生任何人都能读到的默认密钥。其余可选变量除了上述必填项其余都是可选的。仓库根目录的 .env.example 列出了所有支持的变量及其默认值更新前务必对照查看。下面摘录与 Dokploy 部署最相关的几组PostgresPOSTGRES_USER默认postgres、POSTGRES_DB默认insforgePostgREST 连接池POSTGREST_MAX_SOCKETS默认50需与PGRST_DB_POOL对齐、POSTGREST_MAX_FREE_SOCKETS默认10、POSTGREST_FREE_SOCKET_TIMEOUT_MS默认4000对象存储S3 兼容S3_BUCKET、S3_REGION、S3_ENDPOINT_URL、S3_ACCESS_KEY_ID、S3_SECRET_ACCESS_KEY、S3_FORCE_PATH_STYLE、S3_USE_PRESIGNED_URLS、S3_MAX_OBJECT_SIZE_BYTES、MAX_FILE_SIZE站点部署VERCEL_TOKEN、VERCEL_TEAM_ID、VERCEL_PROJECT_ID支付STRIPE_TEST_SECRET_KEY、STRIPE_LIVE_SECRET_KEYOAuth 社交登录Google、GitHub、Discord、Microsoft、LinkedIn、X、Apple 各自的*_CLIENT_ID/*_CLIENT_SECRETAI 网关OPENROUTER_API_KEY自定义 ComputeDocker provider可选COMPUTE_PROVIDER、DOCKER_SOCKET_PATH、COMPUTE_DEFAULT_INGRESS、COMPUTE_PUBLIC_HOST、COMPUTE_DOMAIN、COMPUTE_BIND_ADDRESS、COMPUTE_BUILD_MAX_CONTEXT、COMPUTE_BUILD_UPLOAD_IDLE_TIMEOUT、COMPUTE_ISOLATE_NETWORK遥测INSFORGE_TELEMETRY_DISABLED置1可关闭匿名遥测。值得一提的细节Compose 文件固定写入INSFORGE_DEPLOYMENT_METHOD: dokploy后端会读取该变量来标记部署方式见 backend/src/services/telemetry/telemetry.service.ts不需要你手动设置。3. 添加域名由于栈不向宿主发布任何端口只有配置好路由之后才能访问面板。在 Dokploy 的Domains里添加你的域名字段值Service NameinsforgeContainer Port7130然后把对应的地址加进环境变量API_BASE_URLhttps://insforge.example.com VITE_API_BASE_URLhttps://insforge.example.com这两个地址必须和浏览器实际访问的地址完全一致否则面板会向错误的源发起请求API_BASE_URL用于后端生成回链VITE_API_BASE_URL用于前端构建时指向后端。Compose 中它们的默认值是http://localhost:7130仅适合无域名的本地验证。只有insforge服务需要域名。Postgres、PostgREST 和 Deno 运行时都留在 Dokploy 的内部网络里彼此通过服务名postgres、postgrest、deno和内部端口5432、3000、7133通信。4. 部署按Deploy开始部署。首次运行会做三件事构建两个小镜像——Postgres 镜像deploy/Dockerfile.postgres和 Deno function host 镜像deploy/Dockerfile.deno拉取其余镜像insforge-oss、postgrest后端容器启动时自动执行数据库迁移。部署完成后打开你的域名用ROOT_ADMIN_USERNAME/ROOT_ADMIN_PASSWORD登录面板即可。更新更新很简单再按一次Deploy或者开启 Auto Deploy 让代码推送时自动重新部署。每次部署 Dokploy 都会重新 clone 仓库并用当前 commit 重建 Postgres 和 Deno 镜像因此这两个组件的配置和 function host 始终跟随后端版本走不会出现镜像里的代码落后于仓库的漂移问题。更新前记得先看一遍 .env.example 的 diff——新版本新增的变量不会自动出现在你的 Dokploy 环境里。如果新版本引入了必须的环境变量而你没有在 Dokploy 的 Environment 里补上部署会按 Compose 的${VAR:?}必填校验直接失败或按默认值运行这是新版本最常见的部署问题。存储默认情况下对象存储落在 Docker 卷上的容器文件系统里storage-data→ 挂载到/insforge-storage对象存储insforge-logs→ 挂载到/insforge-logs日志postgres-data→ 挂载到/var/lib/postgresql/data数据库deno_cache→ 挂载到/deno-dirDeno 模块缓存由于Dokploy 只接受单个 compose 文件仓库中 MinIO 和 RustFS 的 overlay compose 在这里用不了overlay 依赖多个 compose 文件叠加。可用的两种存储方案见 Self-Hosted Storage 自托管存储指南简单来说外部 S3 兼容存储在 Dokploy 环境里设置S3_BUCKET、S3_ENDPOINT_URL、S3_ACCESS_KEY_ID、S3_SECRET_ACCESS_KEY、S3_FORCE_PATH_STYLEtrue私有端点还需S3_USE_PRESIGNED_URLSfalsedeploy/dokploy/docker-compose.yml 会把它们透传给后端在同一个 Dokploy 主机上把 MinIO/RustFS 作为独立服务部署然后把上面这些变量指向其内部地址。切换存储方案时要注意对象不会自动迁移。已有数据请先迁移例如用mc mirror或aws s3 sync同步storage-data卷的内容再切换配置。为什么 Postgres 是构建而不是拉取这是本部署方案中最核心的架构决策值得展开说明。InsForge 的 Postgres 需要仓库里的三个文件postgresql.confdeploy/docker-init/db/postgresql.conf核心在于shared_preload_libraries pg_cron,http,pgcrypto,insforge_pg_utils——它预加载了insforge_pg_utils扩展而托管表上的行级安全RLS依赖这个扩展。同时它还固定了insforge.policy_grant_role等扩展参数并声明insforge.internal_schemasai,auth,compute,deployments,email,functions,memory,payments,realtime,schedules,storage,system这些内部 schema 绝不会暴露给 REST 数据 API。db-init.sqldeploy/docker-init/db/db-init.sql初始化时创建anon、authenticated、project_admin三个角色并安装两个事件触发器create_policies_on_table_create、create_policies_on_rls_enable自动为开启 RLS 的新表生成project_admin的默认策略。jwt.sqldeploy/docker-init/db/jwt.sql把JWT_SECRET写入数据库的app.settings.jwt_secret配置。这三个文件通过 deploy/Dockerfile.postgres 打进镜像FROM ghcr.io/insforge/postgres:v15.13.4 COPY deploy/docker-init/db/postgresql.conf /etc/postgresql/postgresql.conf COPY deploy/docker-init/db/db-init.sql /docker-entrypoint-initdb.d/01-init.sql COPY deploy/docker-init/db/jwt.sql /docker-entrypoint-initdb.d/02-jwt.sql为什么不直接拉一个预构建镜像原因有两层bind mount 在 Dokploy 上会失效Dokploy 每次部署都会重新 clonecode/指向仓库路径的 bind mount 会指向旧内容甚至不存在的路径。Dokploy 的文档要求在 UI 里创建 File Mounts 并以../files/引用这对每个安装都是一次手工配置容易遗漏且难以维护。预构建镜像的代码会落后于仓库Postgres 镜像的副本在镜像构建时就冻结了如果insforge_pg_utils没有进入它的shared_preload_libraries自托管环境下的 RLS 就会失效——这正是历史上发生过的问题。Deno 运行时同理发布在 ghcr 的deno-runtime镜像在另一个仓库组装其functions/副本与仓库任何 commit 都不匹配本仓库的修复永远到不了那个镜像见 deploy/Dockerfile.deno 头部注释。所以 deploy/dokploy/docker-compose.yml 选择在部署时用仓库根目录context: ../..现场构建什么都不用额外配置且配置永远与所部署的版本一致。Deno 镜像也做了类似的构建时处理以denoland/deno:alpine-2.0.6为基础把仓库的functions/目录拷入镜像并以非 root 的deno用户运行启动命令会先deno cache再deno run启动 functions/server.ts。安全与运维提示四个服务全部配置了security_opt: no-new-privileges:true防止容器内提权postgres 与 deno 配置了健康检查insforge与postgrest通过depends_on: condition: service_healthy保证启动顺序postgrest 无健康检查是因为其 amd64 镜像内没有 shell 与工具容器内部无法探测自定义 Compute 的 Docker provider 在 Dokploy 平台上是未验证UNVERIFIED状态Dokploy 自身的 reconciler 可能移除它不认识的容器且其反向代理期望特定 labels。Compose 文件里对应的 socket 挂载是注释掉的需自行评估风险后取消注释启用若需在同一主机运行第二个实例注意通过COMPOSE_PROJECT_NAME隔离命名空间避免容器与卷被相互接管。至此你已经可以在 Dokploy 上完成 InsForge 的创建、配置、域名绑定与部署并理解了构建式 Postgres/Deno 镜像背后的设计考量——这套配置会一直跟随后端版本保持一致让自托管体验既简单又可靠。【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考