Instant 自托管 AWS 部署指南：基于 Aurora PostgreSQL 与多后端服务器的高可用架构

后端数据库【免费下载链接】instantInstant is the best backend for AI-coded apps. You get auth, permissions, storage, presence, and streams — everything you need to ship apps your users will love.项目地址https://gitcode.com/gh_mirrors/inst/instant点击查看免费下载导读本文基于 Instant 开源仓库自托管文档 client/www/app/docs/self-hosting/aws/page.md 展开面向需要在生产环境中运行 Instant 的团队讲解如何以两个以上后端容器 Aurora PostgreSQL 17 私有 S3构建与 Instant Cloud 同构的高可用部署。读完本文你将掌握从 AWS 环境准备、Aurora 参数组与数据库初始化、S3 桶与权限配置、共享加密配置生成到后端服务发现、健康检查与横向扩容的完整实战方案并理解这些配置在仓库源码中的底层原理。为什么在 AWS 上需要多后端架构Instant 的 VPS 单机方案参见 self-hosting/vps/page.md适合每月约 $30 的轻量项目而对于需要更高可用性和时间点恢复point-in-time restore的严肃项目官方推荐从两个后端服务器 Aurora PostgreSQL起步。这正是 Instant Cloud 自身采用的整体架构其核心收益是后端与数据库可以独立伸缩后端是无状态的应用容器可按 CPU、内存、请求延迟水平扩容Aurora 提供托管的高可用 PostgreSQL、自动故障转移与时间点恢复能力。文档明确指出资源类型与实例规格完全由你决定真正重要的是Instant 容器如何连接 PostgreSQL、对象存储以及彼此。AWS 上并没有强制的容器平台ECS、EKS、Docker Swarm 或任何等效调度器均可满足需求前提是满足以下架构要求HTTPS 流量路由到每个健康的后端实例至少两个后端任务用于冗余私有 DNS 将tasks.service-name解析到所有后端任务所有后端共享同一份环境变量、密钥与override.ednAurora PostgreSQL 17启用逻辑复制私有 S3 对象存储单独部署一个 Dashboard。其中两个容易被忽略的关键点一是必须设置SWARM_SERVICE_NAME为私有 DNS 中使用的服务名二是不要设置PRODUCTIONtrue因为该变量会选择 Instant Cloud 的生产配置而非自托管配置——这一点在 server/src/instant/config.clj 的get-env中有直接印证PRODUCTIONtrue会将环境解析为:prod进而启用 Cloud 专属配置路径。第一步确认 AWS CLI 访问在创建任何资源之前先选定 AWS CLI profile 与 Region并确认它们指向你打算部署的账户aws sts get-caller-identity --profile your-profile aws configure get region --profile your-profileget-caller-identity返回当前身份Account ID、ARN确认没有指向错误账户configure get region输出当前 profile 的默认 Region。如果尚未配置 AWS可以使用任意 AWS 支持的认证方式创建 CLI profile例如aws configure或 IAM Identity Center 登录并在整个部署过程中一致使用同一个 profile 与 Region。后续所有aws命令、Aurora 参数组、S3 桶与 ECS 任务都应落在同一 Region 内。配置 Aurora PostgreSQL创建集群与参数组Instant 要求PostgreSQL 17并且依赖两个关键能力逻辑复制logical replication与pg_hint_plan 扩展。创建 Aurora PostgreSQL 17 集群后需要在自定义 DB 集群参数组custom DB cluster parameter group中应用如下设置rds.logical_replication 1 shared_preload_libraries pg_stat_statements,pg_hint_plan max_replication_slots 10 max_wal_senders 10 random_page_cost 1.1 rds.force_ssl 0参数说明参数取值作用rds.logical_replication1开启 Aurora 逻辑复制Instant 通过 WAL 逻辑解码同步数据shared_preload_librariespg_stat_statements,pg_hint_plan预加载性能统计与计划提示扩展pg_hint_plan是 Instant 的硬性依赖max_replication_slots10允许的最大复制槽数量每个后端实例会占用复制资源max_wal_senders10允许的最大 WAL 发送进程数random_page_cost1.1调整优化器对随机 I/O 的成本估算适配 Aurora 的存储模型rds.force_ssl0允许非 TLS 连接见下方注意两个注意点shared_preload_libraries中如果已有其他条目保留现有条目在其基础上追加pg_stat_statements,pg_hint_plan复制相关的参数rds.logical_replication、shared_preload_libraries等修改后需要重启集群才会生效。注意摘自原文档 calloutInstant 的迁移连接以非 TLS方式打开因此 Aurora PostgreSQL 17 必须设置rds.force_ssl 0。相应地应将 5432 端口仅对后端服务器的安全组开放不要暴露到公网。创建数据库与登录账号为 Instant 创建专用数据库和登录角色登录账号需要授予RDS 复制角色rds_replication这是逻辑复制从 Aurora 拉取 WAL 所必需的权限CREATE ROLE instant LOGIN PASSWORD replace-with-a-generated-password; GRANT rds_replication TO instant; CREATE DATABASE instant OWNER instant;然后使用Aurora 写入端点writer endpoint拼接DATABASE_URLDATABASE_URLpostgresql://instant:PERCENT_ENCODED_PASSWORDWRITER_ENDPOINT:5432/instant需要特别说明的是PERCENT_ENCODED_PASSWORD仓库的 server/src/instant/config.clj 中db-url-config会把postgresql://形式的 URL 解析为 JDBC 配置并在解析过程中对密码执行percent-decode。因此如果密码中包含、:、/等 URI 保留字符必须先用 URL 百分号编码如→%40再填入连接串避免解析错位。连接池与复制槽的容量规划每个后端实例会打开CONNECTION_POOL_SIZE个数据库连接。从 server/src/instant/config.clj 可以看到默认逻辑若未设置该变量dev 环境默认20而 prod/staging 环境默认400。因此确认 Aurora 的max_connections能同时支撑所有后端实例的连接数之和并预留迁移与管理操作的空间若后端实例超过十个需相应调大max_replication_slots与max_wal_senders。配置 S3 对象存储创建私有桶与最小权限创建一个私有S3 桶用于 Instant Storage。后端需要对该桶拥有以下权限列出桶s3:ListBucket对桶内对象执行读、写、删除s3:GetObject/s3:PutObject/s3:DeleteObject管理分片上传multipart uploads3:ListBucketMultipartUploads/s3:AbortMultipartUpload等用于大文件直传。在每个后端服务器上设置以下环境变量AWS_REGIONyour-region S3_BUCKETinstant-bucket AWS_ACCESS_KEY_IDreplace-with-the-storage-access-key AWS_SECRET_ACCESS_KEYreplace-with-the-storage-secret-key同时务必在桶上配置CORS使 Instant 应用可以在浏览器中直接向 S3 上传文件。两个容易踩坑的点使用 AWS S3 时不要设置S3_ENDPOINT与S3_PUBLIC_ENDPOINT。仓库 server/src/instant/config.clj 表明这两个变量用于自定义 S3 兼容端点如 MinIO默认会回退到 AWS S3 行为即使应用服务器带有实例角色instance role也必须提供静态 IAM 访问密钥。原文档明确说明Instant 目前需要静态 IAM 凭证来签名 S3 URL因此AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY是必填项。共享加密配置 override.ednInstant 使用override.edn文件来加密密钥与签名 Webhook因此每个后端实例必须使用同一份文件。在服务器上一次性生成即可mkdir instant-config docker run --rm \ -v $PWD/instant-config:/out \ ghcr.io/instantdb/server:latest \ /app/start.sh generate-override-config /out/override.edn要点把生成的override.edn与部署密钥一起安全存储如 AWS Secrets Manager在每个后端容器中挂载到固定路径/app/resources/config/override.edn严禁为每台服务器分别生成不同的文件否则各实例的加密密钥与 Webhook 签名不一致导致集群内解密失败。仓库层面server/src/instant/config_edn.clj 的read-config会优先读取config/override.edn作为配置覆盖层server/src/instant/config.clj 的config-map则负责对该文件进行混合解密hybrid decrypt并校验其是否符合配置 spec。文件中的字符串值还可以通过INSTANT_CONFIG_SNAKE_CASE_KEY形式的环境变量覆盖见 server/src/instant/config_edn.clj这为在容器平台注入配置提供了灵活性。部署 Instant运行后端服务器在首选容器平台上部署后端镜像ghcr.io/instantdb/server:latest部署建议初始运行两个后端任务并放置在与 Aurora writer 相同的可用区Availability Zone通过负载均衡器路由公网后端流量健康检查使用/health/system每个后端任务使用相同的环境变量与同一份override.edn挂载到/app/resources/config/override.edn。最低限度的环境变量配置如下WAL_HISTORY_STORAGEpg DATABASE_URLpostgresql://instant:PERCENT_ENCODED_PASSWORDWRITER_ENDPOINT:5432/instant CONNECTION_POOL_SIZE20 INSTANT_BACKEND_URLhttps://api.myinstant.com INSTANT_DASHBOARD_URLhttps://dash.myinstant.com AWS_REGIONyour-region S3_BUCKETinstant-bucket AWS_ACCESS_KEY_IDreplace-with-the-storage-access-key AWS_SECRET_ACCESS_KEYreplace-with-the-storage-secret-key JAVA_OPTS-Xmx4g -Xms4g各变量说明变量说明WAL_HISTORY_STORAGEpg将 WAL 历史存储在 PostgreSQL 而非 S3自托管多机部署的推荐取值。仓库 server/src/instant/config.clj 显示当该值非pg时才会启用WAL_HISTORY_BUCKET_NAME对应的 S3 WAL 历史桶DATABASE_URLAurora writer 端点连接串密码需百分号编码CONNECTION_POOL_SIZE每个后端打开的数据库连接数dev 默认 20prod/staging 默认 400INSTANT_BACKEND_URL/INSTANT_DASHBOARD_URL公网可达的后端与 Dashboard 地址server/src/instant/config.clj 与dashboard-origin均会读取AWS_REGION/S3_BUCKET/ AWS 密钥S3 存储配置AWS S3 场景下不设S3_ENDPOINT/S3_PUBLIC_ENDPOINTJAVA_OPTSJVM 堆设置-Xmx4g -Xms4g表示最小与最大堆均为 4 GB并为操作系统与容器内其他进程预留内存关于 JVM 内存后端默认可能占用大量资源务必用JAVA_OPTS限制最大堆。VPS 指南self-hosting/vps/page.md在 4 GB 服务器上建议从-Xmx2g -Xms2g起步更大、独立的后端容器可分配更大堆但仍应给 JVM 之外留足内存。配置后端发现Backend Discovery多后端任务必须组成同一个 Hazelcast 集群presence在线状态、topics主题与分布式状态才能正常工作。为此在每个后端设置服务名SWARM_SERVICE_NAMEserver配置私有 DNS使tasks.server解析到每个后端任务的私有 IP每个任务必须能通过 TCP 端口5701–5708与5801–5808访问其他任务。ECS AWS Cloud Map、Docker Swarm DNSRR或提供等效私有 DNS 的其他调度器均可满足该要求。源码层面的印证非常具体server/src/instant/reactive/ephemeral.clj 中resolve-task-ips会通过InetAddress/getAllByName tasks.SWARM_SERVICE_NAME解析出所有任务的覆盖网络 IPinit-hz在config/using-swarm?分支见 server/src/instant/config.clj下将解析出的 IP 列表作为 Hazelcast TCP/IP 成员地址并把本机覆盖网络 IP 设为publicAddress。get-hz-portserver/src/instant/config.clj默认5701gRPC 端口则为HZ_PORT 100即 5701–5708 与 5801–5808 的由来。再次强调保持PRODUCTION不设置。一旦设置PRODUCTIONtrueget-env返回:prod后端会走 Instant Cloud 的 AWS 自动发现配置server/src/instant/reactive/ephemeral.clj 中的 AWS 成员发现分支而不是挂载的自托管override.edn。验证提示/health/system返回成功只证明数据库 WAL 健康并不验证后端集群是否组网成功。部署后应在请求被分发到两个后端任务的情况下实测 presence 与实时更新功能。运行 DashboardDashboard 需要单独部署ghcr.io/instantdb/dashboard:latest设置其公网后端地址INSTANT_BACKEND_URLhttps://api.myinstant.com并将 Dashboard 主机名路由到3000 端口https://dash.myinstant.comDashboard不参与后端服务发现它只是一个面向管理员的独立 Web 应用。验证部署负载均衡器应只向后端健康检查返回{wal:ok}的任务分发流量。打开 Dashboard 创建一个应用依次验证查询与写入实时更新文件上传。/health/system的语义在源码中有精确定义server/src/instant/health.clj 中health-get查询 PostgreSQLconfig表中wal-errors键是否有记录有则返回 500{wal:error}否则返回 200{wal:ok}mark-wal-unhealthy/mark-wal-healthy分别由 WAL 消费逻辑在出错/恢复时调用。所以该端点本质上是数据库 WAL 复制健康的探针。在配置邮件服务之前登录验证码会写入后端日志。对于 ECS CloudWatch Logs 的部署可以跟踪后端任务定义上配置的日志组aws logs tail /your/backend/log-group \ --follow \ --region your-region \ --profile your-profile建议将应用日志与基础设施指标接入团队常用的监控体系。至少要观察请求错误率与延迟后端健康状态服务器 CPU 与内存Aurora 连接数与查询延迟S3 错误。扩容扩容遵循哪里是瓶颈就扩哪里的原则当CPU、内存或请求延迟持续偏高时增加后端服务器当数据库 CPU、内存、连接数或查询延迟成为瓶颈时调整 Aurora writer 规格每次增加后端服务器后都要重新审视连接池CONNECTION_POOL_SIZE与复制参数max_replication_slots、max_wal_senders。作为容量参照原文档披露了 Instant Cloud 当前的运行规格仅供参考绝大多数部署应远小于此层级容量应用服务器3 ×m6a.16xlarge各 64 vCPU / 256 GiBPostgreSQLdb.r8gd.16xlarge64 vCPU / 512 GiBAurora I/O-Optimized负载10,000 并发连接、10,000 QPS、1,000 TPS务必从远小于此的规模起步根据实际观测逐步扩容。运行起来之后部署完成并不意味着结束。接下来需要配置邮件服务Postmark / SendGrid / Resend否则登录验证码只能出现在后端日志里配置 Google Dashboard 登录INSTANT_DASHBOARD_GOOGLE_OAUTH_CLIENT_ID/_SECRET设置部署超级用户INSTANT_SUPERUSER_EMAIL并管理 Dashboard 注册策略将 Instant CLI 指向自托管后端INSTANT_CLI_API_URI/INSTANT_CLI_DASH_URI通过/health/system建立告警。以上操作详见 client/www/app/docs/self-hosting/page.md 的 Operating 一节。若你已在使用 Instant Cloud 并希望迁移到自托管可参考迁移指南 client/www/app/docs/self-hosting/migrate/page.md而仓库的 self-hosting/ 目录下还提供了完整的docker-compose*.yml、swarm.yml、Caddyfile 等可直接参考的部署模板。赞分享后端数据库【免费下载链接】instantInstant is the best backend for AI-coded apps. You get auth, permissions, storage, presence, and streams — everything you need to ship apps your users will love.项目地址https://gitcode.com/gh_mirrors/inst/instant点击查看免费下载相关推荐使用 AWS Fargate 与 Aurora PostgreSQL 部署 Backstage基于 CDK 的托管基础设施实践指南使用 AWS Fargate 与 Aurora PostgreSQL 部署 Backstage基于 CDK 的托管基础设施实践指南 Backstage 本身是开发者门户后端前端Karakeep 云端托管部署指南基于 PikaPods 一键启动自托管书签服务Karakeep 云端托管部署指南基于 PikaPods 一键启动自托管书签服务 本篇指南围绕官方安装文档中的 PikaPods 托管方案展开讲解如何在无需后端前端移动开发AI 应用知识管理全文检索MCP 服务Apollo服务端部署与高可用架构Apollo服务端部署与高可用架构 本文详细介绍了Apollo配置中心三大核心服务ConfigService、AdminService、Portal的完整部配置中心后端微服务上一篇Hestia Control Panel防火墙与安全设置暴力攻击防护最佳实践下一篇Chrome-Manager高效管理Chrome多窗口的专业工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考