Encore 对比 Heroku在保留 PaaS 简洁性的同时把部署与基础设施交还给你自己的 AWS/GCP【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encoreEncore 是一个以Infrastructure from Code基础设施即代码声明为核心的云后端开发平台本文基于其官方对比文档系统梳理 Encore 与 Heroku 这类传统 PaaS 在基础设施模式、部署工作流、本地开发、可观测性与云厂商锁定等维度上的差异。读完本文你将理解 Encore 如何做到保留 Heroku 式 push to deploy 的简洁体验同时把应用部署到你自己拥有的 AWS/GCP 云账户以及它内置的开发与 DevOps 工具链分别解决什么问题。为什么拿 Encore 和 Heroku 对比在云计算的早期Heroku 凭借 Platform as a ServicePaaS模式把部署和基础设施管理变得前所未有的简单被视为极具创新性的平台。但过去十年云服务高速演化Heroku 逐渐失去势头其平台模式无法提供足够的灵活性来支撑用户日益复杂的需求。Encore 的定位与 PaaS 截然不同它采用Infrastructure from Code从代码生成基础设施的范式。熟悉 Heroku 的开发者会在 Encore 中看到熟悉的push to deploy工作流关键区别在于——Encore 把应用部署到你自己拥有的 AWS/GCP 云账户。这意味着你保留了使用各大云厂商久经考验的服务进行弹性扩展的完整灵活性可以直接调用云厂商数以千计的服务能力而不必被托管平台锁死。核心能力对照表对比维度EncoreHeroku基础设施方式Infrastructure from Code从代码生成Platform as a Service托管平台内置 CI/CD✅ 是✅ 是内置 Preview Environments预览环境✅ 是✅ 是内置本地开发环境✅ 是❌ 否内置分布式追踪✅ 是❌ 否部署到 AWS、GCP 等主流云厂商✅ 是❌ 否避免云厂商锁定✅ 是❌ 否支持 Kubernetes 与自定义基础设施✅ 是❌ 否基础设施类型安全✅ 是❌ 否托管收费否是从这张表可以看出二者的分水岭并不在 CI/CD 或预览环境这类基础能力上而在于本地开发、分布式追踪、多云部署、规避锁定、类型安全的基础设施声明——这些恰恰是现代分布式后端开发中最耗精力、也最容易被托管平台限制的部分。Infrastructure from CodeEncore 访问云厂商全部能力的途径Encore 的核心主张是你不需要成为云专家也能充分利用 AWS 和 GCP 提供的服务。你只需使用 Encore.ts 或 Encore.go 在应用程序代码中直接声明基础设施语义数据库、缓存、队列、定时任务、对象存储等Encore 就会在编译期解析应用代码生成 Application Model应用模型基于该元数据构建一张高分辨率的基础设施图infrastructure graph精确描述应用所需的基础设施在 基础设施供给 阶段通过 AWS/GCP API 在你自己的云账户中自动创建、配置并管理对应资源同时提供与云环境匹配的本地开发环境。具体来说不同环境下的资源供给方式不同。以开发类环境为例基础设施文档 给出的对照如下资源本地预览 / 开发Encore Cloud 托管GCP / AWSSQL 数据库DockerEncore Cloud 托管Kubernetes/ Neon见生产环境Pub/Sub内存实现GCP Pub/Sub见生产环境缓存内存 Redis内存 Redis见生产环境定时任务禁用Encore Cloud 托管见生产环境对象存储本地磁盘Encore Cloud 托管见生产环境在生产环境Encore 为每个云厂商按最佳实践供给资源GCP 侧包括 VPC、Cloud Run/GKE、Cloud SQL、Pub/Sub、GCS/Cloud CDN、Memorystore 与 Secret ManagerAWS 侧包括 VPC、Fargate ECS/EKS、RDS、SQS/SNS、S3/CloudFront、ElastiCache 与 Secrets Manager详见 GCP 基础设施文档 与 AWS 基础设施文档。部署后你既可以使用云厂商控制台直接修改这些资源也可以使用 Encore Cloud 控制台内置的配置界面Encore 会负责同步你的更改基础设施配置。这种端到端集成带来的直接收益是无需基础设施配置文件也不会在应用中产生云厂商特定依赖同时基础设施状态始终可被追踪帮助你发现闲置资源、避免不必要的云成本。为什么这能规避云厂商锁定传统 PaaS 的锁定来自托管平台即唯一运行环境一旦应用依赖平台提供的运行时与专有服务迁移成本极高。而 Encore 的模型下你拥有云账户和全部基础设施——数据库是 RDS/Cloud SQL队列是 SQS/SNS/GCP Pub/Sub容器跑在 ECS/EKS/GKE 上这些都是云厂商的标准服务同时不存在对 Encore Cloud 的运行时依赖云中也不会运行任何专有代码。因此从源码结构看避免锁定由三层机制共同保证基础设施由标准云服务承载、应用代码与基础设施解耦通过声明式框架而非平台 API、部署目标完全位于你的账户内。本地开发工作流encore run一行命令启动完整环境使用 Heroku 这样的 PaaS 部署应用时平台并不解决本地开发效率问题。开发者需要手动搭建并维护本地环境与可观测性工具例如用 Docker Compose 编排各种云基础设施的本地版本。这项工作会随着系统演化持续进行服务与基础设施规模越大就越复杂不断挤占产品开发时间也拉长新人的上手周期。而 Encore 中本地环境与云环境由同一份代码定义——就是你的应用代码本身。开发者只需要执行encore runEncore 的开源 CLI 会自动完成所有基础设施的本地版本搭建。从源码看这一命令的实现入口位于 cli/cmd/encore/run.go 的runApp函数它负责解析应用根目录并启动本地开发流程。本地环境中SQL 数据库通过 Docker 供给Pub/Sub 与缓存以内存方式运行本仓库 cli/daemon/pubsub/nsq.go 中可以看到基于 NSQ 的本地 Pub/Sub 实现cli/daemon/redis/redis.go 对应本地缓存应用代码在本地机器上原生编译运行无需 Docker测试时还会额外供给一个针对高性能优化内存文件系统 禁用 fsync的独立数据库集群定时任务在本地默认不触发避免开发时意外执行需要时可通过开发控制台手动调用 API 触发。配合内置的可观测性工具本地开发控制台本地开发迭代速度大幅提升开发者可以立即使用新的基础设施构建新服务和事件驱动系统变得极其高效。Push to Deploy完整的上线工作流Encore 保留了 Heroku 式的推送即部署体验具体分为四步详见 部署文档Step 1创建账户与应用encore app create如果应用已在本地创建则先登录再链接encore auth login # 已有 Encore Cloud 账户 encore app init # 在应用根目录执行链接到 Encore Cloud git remote add encore encore://app-id # 添加 Encore 管理的 git remoteStep 2集成 GitHub可选在 Encore Cloud 控制台的 App Settings Integrations GitHub 中连接 GitHub 账户并选择要关联的仓库详见 GitHub 集成文档。集成后推送代码会自动触发部署。Step 3连接 AWS / GCP 云账户可选在 App Settings Integrations Connect Cloud 中连接你自己的云账户详见 连接云账户文档。跳过此步则使用 Encore Cloud 免费开发托管。Step 4推送触发部署git add -A . git commit -m Commit message git push origin # 或 git push encore推送后 Encore Cloud 依次执行三个阶段构建与测试build test→ 基础设施供给infrastructure provisioning→ 部署deployment进度可在控制台的 Deployments 页面监控。你还可以在encore.app文件中覆盖 CI/CD 的若干构建设置例如cgo_enabled、Dockerbase_imageGo 应用默认为scratchTypeScript 应用默认为node:24-trixie、bundle_source以及prebuild/postbuild钩子。环境体系本地、预览、开发、生产环境文档 定义了四种环境类型production、development、preview、local。不同环境的供给策略不同local由开源 CLI 使用本地基础设施供给preview在 Encore Cloud 托管中供给优化目标为低成本、快速创建production/development由 Encore Cloud 供给可部署到你自己的云账户或使用免费开发托管。环境类型同样服务于 Secrets 管理你可以为production和development配置不同的密钥。每个环境还可独立配置部署触发器Git 分支或手动、基础设施审批启用后需 Admin 手动审批基础设施变更才能继续部署、进程分配方式单进程或每服务独立进程。Preview Environments每个 Pull Request 一个临时环境连接 GitHub 后Encore 会自动为每个 Pull Request 供给独立的 Preview Environment。它按 PR 命名例如 PR #72 会创建名为pr:72的环境API 地址形如https://pr72-$APP_ID.encr.app。PR 合并或关闭后环境自动销毁。前端协作时只需把 API client 指向对应环境encore gen client --envpr:72 --langtypescript my-app开箱即用的开发者与 DevOps 工具链Encore 不止自动化基础设施供给与配置它是为云后端开发而生的端到端工具同时覆盖开发与运维两侧。内置开发者工具跨服务类型安全与 IDE 自动补全分布式追踪Tracing 文档自动捕获整个应用在所有环境中的调用链无需手工插桩本地开发也能用支持按环境、服务、端点三级配置采样率以及按日/月预算控制追踪成本测试追踪自动 API 文档自动架构图API Client 生成Secrets 管理Service/API Mocking内置 DevOps 工具AWS/GCP 基础设施自动供给基础设施追踪与审批工作流Encore 与 AWS/GCP 之间的云配置双向同步自动最小权限 IAM根据代码对资源的使用方式生成每个 Pull Request 的预览环境成本分析仪表盘Encore Terraform Provider用于将 Encore 尚未纳入后端框架的基础设施扩展接入。它提供encore_database、encore_cache、encore_pubsub_topic等只读数据源可在 Terraform 配置中引用 Encore 已供给资源的云标识符例如data encore_pubsub_topic topic { name my-topic env my-env }总结与 Heroku 这类传统 PaaS 相比Encore 的本质差异在于基础设施的归属与生成方式Heroku 托管一切、也锁定一切Encore 通过 Infrastructure from Code 把基础设施声明嵌入应用代码在保留推送即部署体验的同时将资源供给到你自己拥有的 AWS/GCP 账户并配套完整的本地开发环境、分布式追踪、预览环境、自动 IAM 与 Terraform 集成。如果你需要 Heroku 式的开发体验又不想被托管平台限制住扩展性与自主权Encore 提供了一条可落地的中间路线——本仓库README中的 CLIcli/cmd/encore、本地运行时runtimes/go/appruntime与基础设施模拟器pkg/emulators/storage等开源组件正是这条路线在代码层面的完整呈现。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Encore 对比 Heroku：在保留 PaaS 简洁性的同时，把部署与基础设施交还给你自己的 AWS/GCP
Encore 对比 Heroku在保留 PaaS 简洁性的同时把部署与基础设施交还给你自己的 AWS/GCP【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encoreEncore 是一个以Infrastructure from Code基础设施即代码声明为核心的云后端开发平台本文基于其官方对比文档系统梳理 Encore 与 Heroku 这类传统 PaaS 在基础设施模式、部署工作流、本地开发、可观测性与云厂商锁定等维度上的差异。读完本文你将理解 Encore 如何做到保留 Heroku 式 push to deploy 的简洁体验同时把应用部署到你自己拥有的 AWS/GCP 云账户以及它内置的开发与 DevOps 工具链分别解决什么问题。为什么拿 Encore 和 Heroku 对比在云计算的早期Heroku 凭借 Platform as a ServicePaaS模式把部署和基础设施管理变得前所未有的简单被视为极具创新性的平台。但过去十年云服务高速演化Heroku 逐渐失去势头其平台模式无法提供足够的灵活性来支撑用户日益复杂的需求。Encore 的定位与 PaaS 截然不同它采用Infrastructure from Code从代码生成基础设施的范式。熟悉 Heroku 的开发者会在 Encore 中看到熟悉的push to deploy工作流关键区别在于——Encore 把应用部署到你自己拥有的 AWS/GCP 云账户。这意味着你保留了使用各大云厂商久经考验的服务进行弹性扩展的完整灵活性可以直接调用云厂商数以千计的服务能力而不必被托管平台锁死。核心能力对照表对比维度EncoreHeroku基础设施方式Infrastructure from Code从代码生成Platform as a Service托管平台内置 CI/CD✅ 是✅ 是内置 Preview Environments预览环境✅ 是✅ 是内置本地开发环境✅ 是❌ 否内置分布式追踪✅ 是❌ 否部署到 AWS、GCP 等主流云厂商✅ 是❌ 否避免云厂商锁定✅ 是❌ 否支持 Kubernetes 与自定义基础设施✅ 是❌ 否基础设施类型安全✅ 是❌ 否托管收费否是从这张表可以看出二者的分水岭并不在 CI/CD 或预览环境这类基础能力上而在于本地开发、分布式追踪、多云部署、规避锁定、类型安全的基础设施声明——这些恰恰是现代分布式后端开发中最耗精力、也最容易被托管平台限制的部分。Infrastructure from CodeEncore 访问云厂商全部能力的途径Encore 的核心主张是你不需要成为云专家也能充分利用 AWS 和 GCP 提供的服务。你只需使用 Encore.ts 或 Encore.go 在应用程序代码中直接声明基础设施语义数据库、缓存、队列、定时任务、对象存储等Encore 就会在编译期解析应用代码生成 Application Model应用模型基于该元数据构建一张高分辨率的基础设施图infrastructure graph精确描述应用所需的基础设施在 基础设施供给 阶段通过 AWS/GCP API 在你自己的云账户中自动创建、配置并管理对应资源同时提供与云环境匹配的本地开发环境。具体来说不同环境下的资源供给方式不同。以开发类环境为例基础设施文档 给出的对照如下资源本地预览 / 开发Encore Cloud 托管GCP / AWSSQL 数据库DockerEncore Cloud 托管Kubernetes/ Neon见生产环境Pub/Sub内存实现GCP Pub/Sub见生产环境缓存内存 Redis内存 Redis见生产环境定时任务禁用Encore Cloud 托管见生产环境对象存储本地磁盘Encore Cloud 托管见生产环境在生产环境Encore 为每个云厂商按最佳实践供给资源GCP 侧包括 VPC、Cloud Run/GKE、Cloud SQL、Pub/Sub、GCS/Cloud CDN、Memorystore 与 Secret ManagerAWS 侧包括 VPC、Fargate ECS/EKS、RDS、SQS/SNS、S3/CloudFront、ElastiCache 与 Secrets Manager详见 GCP 基础设施文档 与 AWS 基础设施文档。部署后你既可以使用云厂商控制台直接修改这些资源也可以使用 Encore Cloud 控制台内置的配置界面Encore 会负责同步你的更改基础设施配置。这种端到端集成带来的直接收益是无需基础设施配置文件也不会在应用中产生云厂商特定依赖同时基础设施状态始终可被追踪帮助你发现闲置资源、避免不必要的云成本。为什么这能规避云厂商锁定传统 PaaS 的锁定来自托管平台即唯一运行环境一旦应用依赖平台提供的运行时与专有服务迁移成本极高。而 Encore 的模型下你拥有云账户和全部基础设施——数据库是 RDS/Cloud SQL队列是 SQS/SNS/GCP Pub/Sub容器跑在 ECS/EKS/GKE 上这些都是云厂商的标准服务同时不存在对 Encore Cloud 的运行时依赖云中也不会运行任何专有代码。因此从源码结构看避免锁定由三层机制共同保证基础设施由标准云服务承载、应用代码与基础设施解耦通过声明式框架而非平台 API、部署目标完全位于你的账户内。本地开发工作流encore run一行命令启动完整环境使用 Heroku 这样的 PaaS 部署应用时平台并不解决本地开发效率问题。开发者需要手动搭建并维护本地环境与可观测性工具例如用 Docker Compose 编排各种云基础设施的本地版本。这项工作会随着系统演化持续进行服务与基础设施规模越大就越复杂不断挤占产品开发时间也拉长新人的上手周期。而 Encore 中本地环境与云环境由同一份代码定义——就是你的应用代码本身。开发者只需要执行encore runEncore 的开源 CLI 会自动完成所有基础设施的本地版本搭建。从源码看这一命令的实现入口位于 cli/cmd/encore/run.go 的runApp函数它负责解析应用根目录并启动本地开发流程。本地环境中SQL 数据库通过 Docker 供给Pub/Sub 与缓存以内存方式运行本仓库 cli/daemon/pubsub/nsq.go 中可以看到基于 NSQ 的本地 Pub/Sub 实现cli/daemon/redis/redis.go 对应本地缓存应用代码在本地机器上原生编译运行无需 Docker测试时还会额外供给一个针对高性能优化内存文件系统 禁用 fsync的独立数据库集群定时任务在本地默认不触发避免开发时意外执行需要时可通过开发控制台手动调用 API 触发。配合内置的可观测性工具本地开发控制台本地开发迭代速度大幅提升开发者可以立即使用新的基础设施构建新服务和事件驱动系统变得极其高效。Push to Deploy完整的上线工作流Encore 保留了 Heroku 式的推送即部署体验具体分为四步详见 部署文档Step 1创建账户与应用encore app create如果应用已在本地创建则先登录再链接encore auth login # 已有 Encore Cloud 账户 encore app init # 在应用根目录执行链接到 Encore Cloud git remote add encore encore://app-id # 添加 Encore 管理的 git remoteStep 2集成 GitHub可选在 Encore Cloud 控制台的 App Settings Integrations GitHub 中连接 GitHub 账户并选择要关联的仓库详见 GitHub 集成文档。集成后推送代码会自动触发部署。Step 3连接 AWS / GCP 云账户可选在 App Settings Integrations Connect Cloud 中连接你自己的云账户详见 连接云账户文档。跳过此步则使用 Encore Cloud 免费开发托管。Step 4推送触发部署git add -A . git commit -m Commit message git push origin # 或 git push encore推送后 Encore Cloud 依次执行三个阶段构建与测试build test→ 基础设施供给infrastructure provisioning→ 部署deployment进度可在控制台的 Deployments 页面监控。你还可以在encore.app文件中覆盖 CI/CD 的若干构建设置例如cgo_enabled、Dockerbase_imageGo 应用默认为scratchTypeScript 应用默认为node:24-trixie、bundle_source以及prebuild/postbuild钩子。环境体系本地、预览、开发、生产环境文档 定义了四种环境类型production、development、preview、local。不同环境的供给策略不同local由开源 CLI 使用本地基础设施供给preview在 Encore Cloud 托管中供给优化目标为低成本、快速创建production/development由 Encore Cloud 供给可部署到你自己的云账户或使用免费开发托管。环境类型同样服务于 Secrets 管理你可以为production和development配置不同的密钥。每个环境还可独立配置部署触发器Git 分支或手动、基础设施审批启用后需 Admin 手动审批基础设施变更才能继续部署、进程分配方式单进程或每服务独立进程。Preview Environments每个 Pull Request 一个临时环境连接 GitHub 后Encore 会自动为每个 Pull Request 供给独立的 Preview Environment。它按 PR 命名例如 PR #72 会创建名为pr:72的环境API 地址形如https://pr72-$APP_ID.encr.app。PR 合并或关闭后环境自动销毁。前端协作时只需把 API client 指向对应环境encore gen client --envpr:72 --langtypescript my-app开箱即用的开发者与 DevOps 工具链Encore 不止自动化基础设施供给与配置它是为云后端开发而生的端到端工具同时覆盖开发与运维两侧。内置开发者工具跨服务类型安全与 IDE 自动补全分布式追踪Tracing 文档自动捕获整个应用在所有环境中的调用链无需手工插桩本地开发也能用支持按环境、服务、端点三级配置采样率以及按日/月预算控制追踪成本测试追踪自动 API 文档自动架构图API Client 生成Secrets 管理Service/API Mocking内置 DevOps 工具AWS/GCP 基础设施自动供给基础设施追踪与审批工作流Encore 与 AWS/GCP 之间的云配置双向同步自动最小权限 IAM根据代码对资源的使用方式生成每个 Pull Request 的预览环境成本分析仪表盘Encore Terraform Provider用于将 Encore 尚未纳入后端框架的基础设施扩展接入。它提供encore_database、encore_cache、encore_pubsub_topic等只读数据源可在 Terraform 配置中引用 Encore 已供给资源的云标识符例如data encore_pubsub_topic topic { name my-topic env my-env }总结与 Heroku 这类传统 PaaS 相比Encore 的本质差异在于基础设施的归属与生成方式Heroku 托管一切、也锁定一切Encore 通过 Infrastructure from Code 把基础设施声明嵌入应用代码在保留推送即部署体验的同时将资源供给到你自己拥有的 AWS/GCP 账户并配套完整的本地开发环境、分布式追踪、预览环境、自动 IAM 与 Terraform 集成。如果你需要 Heroku 式的开发体验又不想被托管平台限制住扩展性与自主权Encore 提供了一条可落地的中间路线——本仓库README中的 CLIcli/cmd/encore、本地运行时runtimes/go/appruntime与基础设施模拟器pkg/emulators/storage等开源组件正是这条路线在代码层面的完整呈现。【免费下载链接】encoreThe infrastructure platform for the intelligence era项目地址: https://gitcode.com/GitHub_Trending/encor/encore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
