Activepieces License Keys 深度解析自托管激活句柄与 Autumn 计费体系的完整对接【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces导读本文围绕 Activepieces 企业版/云版中 License Key许可证密钥的完整技术实现展开它并非传统意义上的功能开关包而是自托管客户对接到 Autumn 计费体系的激活/恢复句柄。通过阅读本文你将掌握密钥的激活链路activateLicense→ 控制台/activate→ 权益刷新、自动试用激活链接的前端实现细节、两个激活 API 端点的用法以及社区版CE下该机制如何以 no-op 形式存在等关键边界。所有结论均可在当前仓库源码中逐一验证。License Key 的设计定位激活句柄而非功能开关在 Activepieces 中一个 License Key 是自托管客户对其 Autumn 计费身份的激活/恢复句柄——它是一个不透明字符串opaque string不是一组功能旗标的集合。用户把它粘贴到计费界面Billing UI后Activepieces 后端会把激活动作委托给 Activepieces 控制台console控制台将密钥解析为某个 Autumn 客户必要时创建新客户、挂上该许可证对应的套餐并返回autumnCustomerId与一个客户级的 Autumn API Key。此后套餐上限与功能开关全部由 Autumn entitlements 投影project而来绝不读取密钥本身的内容。从源码看这套接缝在billingProvider上是一个 CE no-op见下文 billing-provider.ts 中的activateLicense空实现真正实现只在 EE/Cloud 下注册因此整个机制是 EE Cloud 专属能力。历史背景在计费迁移到 Autumn 之前系统曾存在一套旧版实现——公开的/v1/license-keys/*端点、licenseKeysService含verifyKeyOrReturnNull、applyLimits、downgradeToFreePlan、每日定时任务TRIAL_TRACKER以及与secrets.activepieces.com的远程校验调用。这套代码在迁移时被整体删除当前代码库中已无任何残留已发布的自托管构建包中捆绑的是它们各自的历史副本。端到端激活流程从粘贴密钥到权益落地核心调用链用户在前端激活密钥时走的完整链路为前端调用POST /v1/platform-billing/activate请求体为{ licenseKey }见 platform-plan.controller.ts 的ActivateLicenseRequest仅允许平台管理员platformAdminOnly([USER])。控制器将其包装为billingProvider.activateLicense({ platformId, licenseKey })调用platformId取自登录主体principal。EE 实现autumnBillingProvider.activateLicense见 autumn-billing.ts依次执行调用autumnConsole.activate({ licenseKey })——即向控制台发起POST {console}/api/v1/billing/activate密钥本身作为 Bearer Token放在请求头中在distributedLockkey 为getAutumnEnrollLockKey(platformId)保护下保存结果先通过platformPlanService.update({ platformId, licenseKey })持久化密钥再通过platformPlanService.setAutumnCredentials保存返回的autumnCustomerId与autumnApiKey最后调用refreshEntitlements刷新权益。源码中有一个值得注意的安全细节激活时若发现该平台此前已绑定过一个不同的autumnCustomerId会输出告警日志License activation replaced an existing Autumn customer; the previous subscription is now orphaned and needs manual reconciliation提示旧订阅已孤儿化需要人工对账。幂等性与恢复场景控制台/activate是幂等的一个密钥固定映射到一个 Autumn 客户。因此客户在全新实例上重新激活同一个密钥会拿到同一个autumnCustomerId与同一组凭证。这正是客户丢失实例后支持团队把密钥还给客户即可恢复这一运维流程的实现基础。权益刷新Autumn 是唯一事实来源refreshEntitlements见 autumn-utils.ts的实现要点通过resolveClientForPlatform取得客户级 Autumn 客户端读取platform_plan上保存的凭证拉取客户数据getCustomerexpand: [subscriptions.plan, purchases.plan]调用mapAutumnFeaturesToPlatformPlan把 entitlements 投影为platform_plan上的字段并落库包括plan套餐标识billedTeamProjectsLimit、usersLimit、activeFlowsLimit分别来自TEAM_PROJECTS_LIMIT、USERS_LIMIT、ACTIVE_FLOWS_LIMIT余额usersLimit/activeFlowsLimit缺省时为nullbilledTeamProjectsLimit缺省为1includedCredits来自AP_CREDITS余额的grantedscheduledUsersLimit排期中的降级套餐以及一整组布尔功能旗标tablesEnabled、eventStreamingEnabled、environmentsEnabled、analyticsEnabled、showPoweredBy、auditLogEnabled、embeddingEnabled、aiProvidersEnabled、chatEnabled、agentsEnabled、workerGroupsEnabled、managePiecesEnabled、manageTemplatesEnabled、customAppearanceEnabled、projectRolesEnabled、globalConnectionsEnabled、customRolesEnabled、apiKeysEnabled、ssoEnabled、secretManagersEnabled、scimEnabled全部由 Autumn 返回的grantedFeatureIds集合驱动写入客户状态缓存billingEnforced、积分余额等供计费闸门快速读取、失效计费概览缓存并执行provisionLicenseKeyIfPaid。懒注册与密钥补发ensureEnrolled懒注册在distributedLock下执行若platform_plan中已存有licenseKey则通过控制台重新激活否则调用enrollFree以平台所有者的邮箱在 Autumn 免费注册。注册完成后同样会刷新权益。provisionLicenseKeyIfPaid付费补发在refreshEntitlements过程中自服务self-serve付费客户若从未录入密钥系统会请控制台铸一枚新密钥POST /api/v1/billing/provision-license-key并保存到platform_plan.licenseKey。这样每一个付费平台最终都会拥有一个恢复句柄。免费/AppSumo/免费遗留套餐FREE、APPSUMO、FREE_LEGACY会被跳过。API 端点一览1.POST /v1/platform-billing/activate平台管理员请求体{ licenseKey }鉴权为securityAccess.platformAdminOnly([USER])。它是billingProvider.activateLicense的薄封装platformId取自 principal——这是终端用户自托管管理员激活密钥的正式入口。2.POST /v1/admin/platforms/apply-license-key云管理员面向 Activepieces 云运维/支持人员请求体为{ email, licenseKey }schema 见 platform.request.ts 的ApplyLicenseKeyByEmailRequestBody。实现位于 admin-platform.controller.ts 与 admin-platform.service.ts模块级preHandlercheckCertainKeyPreHandler检查请求头api-key是否等于AppSystemProp.API_KEY未配置时一律 403服务端applyLicenseKeyByEmail先用邮箱解析用户身份再定位platformRole: PlatformRole.ADMIN的用户及其所属平台最后调用与终端入口同一个activateLicense。因此两个端点的语义完全一致支持团队无需拿到客户的登录态只要知道客户邮箱即可代为激活。自动试用激活链接/?licenseKey…为了让销售能一次点击完成试用开通系统支持在任意来源页面上携带/?licenseKey…链接完成自动激活。整个过程不落任何存储密钥由 URL 跨登录携带。登录前后的路由接力DefaultRoute会把pathname search整体折叠进from登录后useRedirectAfterLogin再导航回该地址对于 Google/SAML 这类外部登录from会搭载在 OAuth 的state参数上其背景是AuthenticatedDefaultRoute要求最后一跳必须学会携带location.search详见 ce-authentication.md 的相关说明链接参数的常量名是TRIAL_KEY_QUERY_PARAM licenseKey见 route-utils.ts。消费端本仓库与生成端控制台仓库之间唯一的约定就是这个查询参数名——若改动参数名或迁移路由控制台仍会继续派发静默失效的链接。历史上曾有一个实现密钥先暂存进sessionStorage并在登录时无条件剥离参数。由于写入用tryCatchSync静默抑制、剥离却不带条件在 Web Storage 被屏蔽的来源沙箱 iframe、禁用 Cookie 的浏览器、把setItemstub 掉且无法抛错的无痕扩展上密钥会从两处同时消失。该实现已被移除改为下述先捕获、后擦除的方案。前端组件AutomaticTrialActivation与TrialActivationScreen组件源码位于 automatic-trial-activation.tsx被渲染在AllowOnlyLoggedInUserOnlyGuard内部见 allow-logged-in-user-only-guard.tsx一旦平台存在便接管整个视口判定时机AutomaticTrialActivation在惰性useState初始化器中决定是否展示——所有输入查询参数、platform、edition、平台角色要么是 suspense 查询、要么是同步读取没有需要等待的东西同时必须在挂载时捕获alreadyLicensed否则激活后的平台 refetch 会在彩带动画中途卸载成功面板。先捕获、后擦除密钥从首次渲染起就存在于 React state 中屏幕在挂载时删除 URL 参数scrubbed.delete(TRIAL_KEY_QUERY_PARAM)后setSearchParams(..., { replace: true })。因此 URL 副本只在密钥已安全持有时才被丢弃。两个已知后果刷新后参数已擦除、密钥丢失用户需重播原始链接若父级组件跳过渲染社区版或已授权则无组件去擦除参数会残留到下一次导航。单一状态now屏幕只持有一个挂载时执行的useEffect——触发激活并启动 250ms 的时钟视图、进度条、客户端超时与跳转倒计时全部由该时钟加 mutation 的isPending/isSuccess/isError派生出来而非另存状态。激活请求仍然 POST 到既有的POST /v1/platform-billing/activate前端封装为platformApi.activateLicenseKey见 platforms-api.tsmutation 为useUpdateLisenceKey见 platform-hooks.ts并显式抑制两次 toastmessages: { success: null, error: null }因为界面自己渲染结果。四种状态activating带一条渐近式的伪进度曲线、success彩带 5 秒后跳转默认路由、not_admin提供可转发的链接、failed重试按钮 支持邮箱 mailto。为什么是组件而非 HookAutomaticTrialActivation必须做成组件是因为父级 guard 的提前 return 会使条件性 Hook 调用违反 React 规则。生成端激活链接由控制台构建其仓库内的packages/web/src/lib/activation-link.ts在许可证密钥表格和密钥创建成功页上以 Copy activation link 形式出现AP 仓库只负责消费。前端展示组件 license-key.tsx 负责自托管场景下展示/复制已有密钥CopyToClipboardInput以及切换 Activate trial key / Activate license key / Update license key 的激活对话框入口activate-license-dialog.tsx。必须知道的边界与陷阱Gotchas社区版CE下激活路由直接 404billingProvider.activateLicense虽是 CE no-op但platformPlanModule只在ApEdition.CLOUD与ApEdition.ENTERPRISE下注册见 app.ts 的 edition 分支因此POST /v1/platform-billing/activate在 CE 上不存在。任何复用的共享前端代码必须先判断EDITION标志再调用激活否则 CE 自托管用户会看到激活失败真实原因其实是AP_EDITIONce。AP 从不读取密钥内容许可证数据license_keys表、套餐与期限、试用签发、autumn_customers台账全部由控制台拥有旧世界密钥里带逐功能开关的模型已不存在。控制台校验先于落库activateLicense中控制台调用发生在platform_plan.licenseKey保存之前——被拒绝的密钥永远不会被持久化。控制台地址是硬编码常量AUTUMN_CONSOLE_URL在 autumn-utils.ts 中由system.getOrThrow(AppSystemProp.AUTUMN_CONSOLE_URL)取到并规范化去掉尾部/当前指向测试控制台所有控制台请求都经由safeHttp并带请求超时CONSOLE_REQUEST_TIMEOUT_MS 30000客户读取超时5000ms。AP 侧没有过期任务platform_plan.licenseKey列保留但 AP 不运行任何 expiry job——套餐失效由控制台/Autumn 侧处理最终通过权益刷新落到 AP。非试用密钥的expiresAt目前无效控制台的 comp 附加使用customize: { price: null }且不带ends_at被补偿的套餐永不失效AP 端也没有任何代码读取licenseExpiresAt。试用期从签发日而非激活日计算控制台两条铸钥路径销售的licenseKeysService.create、自助表单的externalService.generateKey都会在创建时即写入expiresAt now valid_days并把activatedAt也置为同一时间戳列名有误导性从未被重新盖章。控制台的activate只读取expiresAt并挂接剩余天数trialDays ceil((expiresAt - now) / day)。也就是说客户每多等一天激活就损失一天试用——20 天密钥在第 8 天激活只剩 12 天第 21 天激活则落入下面第 7 条的死密钥场景。目前唯一的补救手段是销售手动延长到期时间。expiresAt为空或已过期的试用密钥激活后没有套餐控制台activate仅在isTrial trialDaysRemaining(expiresAt) 1时挂套餐否则仅当!isTrialcomp时挂——剩余天数四舍五入为 0 的试用密钥两个分支都进不去客户被创建但无订阅Autumn 的auto_enable会把它放到free上。升级后的首次请求该平台就会看到所有 EE 旗标被吊销、只剩 1 个席位、billingEnforced开启、带 powered-by 品牌标识。刷新时 Autumn 套餐是唯一事实来源mapAutumnFeaturesToPlatformPlan执行flags[feature] entitlements.flags[feature] ?? false——目标套餐未包含的任何旗标都会被吊销。因此若许可证→套餐的映射在某个 feature 上遗漏客户会被静默降级。发布迁移前务必对照线上 Autumn 目录逐旗标审计而不是只看套餐级别。失败是可重试的 fail-safe若控制台调用抛错凭证不会被保存既有platform_plan旗标原样保留ensureEnrolled每 300 秒重试一次getEnrollAttemptKey权益刷新之后每 15 分钟节流一次。Cloud 计费页同样展示激活区当platform_plan.licenseKey为空时标签显示 Trial Keys云平台的密钥通常是销售分发的企业试用密钥。该区块曾藏在计费路由的 AltA 快捷键彩蛋后面因支持人员无法引导客户操作而移除了该揭示机制。无密钥注册 ≠ 旧版开源默认套餐enrollFree会把平台落到 AutumnfreeaiProvidersEnabled: false、usersLimit: 1、billingEnforced: true、showPoweredBy: true这比旧版未授权 EE 实例获得的OPEN_SOURCE_PLAN范围明显更窄——选择无密钥运行前需知晓这一差异。关键文件索引职责文件激活入口控制器POST /v1/platform-billing/activateplatform-plan.controller.ts计费接缝CE no-op 的activateLicensebilling-provider.tsEE 激活实现activateLicenseautumn-billing.tsautumnConsole.activate、ensureEnrolled、refreshEntitlements、provisionLicenseKeyIfPaidautumn-utils.ts云管理端apply-license-key路由与api-key守卫admin-platform.controller.ts、admin-platform.service.tsApplyLicenseKeyByEmailRequestBodyschemaplatform.request.ts前端激活对话框与密钥展示activate-license-dialog.tsx、license-key.tsx自动试用激活全屏四态automatic-trial-activation.tsx前端 API 封装与 mutationplatforms-api.ts、platform-hooks.ts查询参数常量licenseKeyroute-utils.tsplatformPlanModule的 edition 注册条件app.ts综上Activepieces 的 License Key 机制是一套密钥仅作句柄、权益全部来自 Autumn 投影的现代计费架构激活、恢复、试用与自助补发都围绕控制台展开而 AP 侧通过billingProvider接缝保持了 CE 与 EE 的清晰分界。理解上述调用链与边界条件是排查自托管激活失败、试用期异常缩短或功能被静默降级等问题的前提。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Activepieces License Keys 深度解析：自托管激活句柄与 Autumn 计费体系的完整对接
Activepieces License Keys 深度解析自托管激活句柄与 Autumn 计费体系的完整对接【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces导读本文围绕 Activepieces 企业版/云版中 License Key许可证密钥的完整技术实现展开它并非传统意义上的功能开关包而是自托管客户对接到 Autumn 计费体系的激活/恢复句柄。通过阅读本文你将掌握密钥的激活链路activateLicense→ 控制台/activate→ 权益刷新、自动试用激活链接的前端实现细节、两个激活 API 端点的用法以及社区版CE下该机制如何以 no-op 形式存在等关键边界。所有结论均可在当前仓库源码中逐一验证。License Key 的设计定位激活句柄而非功能开关在 Activepieces 中一个 License Key 是自托管客户对其 Autumn 计费身份的激活/恢复句柄——它是一个不透明字符串opaque string不是一组功能旗标的集合。用户把它粘贴到计费界面Billing UI后Activepieces 后端会把激活动作委托给 Activepieces 控制台console控制台将密钥解析为某个 Autumn 客户必要时创建新客户、挂上该许可证对应的套餐并返回autumnCustomerId与一个客户级的 Autumn API Key。此后套餐上限与功能开关全部由 Autumn entitlements 投影project而来绝不读取密钥本身的内容。从源码看这套接缝在billingProvider上是一个 CE no-op见下文 billing-provider.ts 中的activateLicense空实现真正实现只在 EE/Cloud 下注册因此整个机制是 EE Cloud 专属能力。历史背景在计费迁移到 Autumn 之前系统曾存在一套旧版实现——公开的/v1/license-keys/*端点、licenseKeysService含verifyKeyOrReturnNull、applyLimits、downgradeToFreePlan、每日定时任务TRIAL_TRACKER以及与secrets.activepieces.com的远程校验调用。这套代码在迁移时被整体删除当前代码库中已无任何残留已发布的自托管构建包中捆绑的是它们各自的历史副本。端到端激活流程从粘贴密钥到权益落地核心调用链用户在前端激活密钥时走的完整链路为前端调用POST /v1/platform-billing/activate请求体为{ licenseKey }见 platform-plan.controller.ts 的ActivateLicenseRequest仅允许平台管理员platformAdminOnly([USER])。控制器将其包装为billingProvider.activateLicense({ platformId, licenseKey })调用platformId取自登录主体principal。EE 实现autumnBillingProvider.activateLicense见 autumn-billing.ts依次执行调用autumnConsole.activate({ licenseKey })——即向控制台发起POST {console}/api/v1/billing/activate密钥本身作为 Bearer Token放在请求头中在distributedLockkey 为getAutumnEnrollLockKey(platformId)保护下保存结果先通过platformPlanService.update({ platformId, licenseKey })持久化密钥再通过platformPlanService.setAutumnCredentials保存返回的autumnCustomerId与autumnApiKey最后调用refreshEntitlements刷新权益。源码中有一个值得注意的安全细节激活时若发现该平台此前已绑定过一个不同的autumnCustomerId会输出告警日志License activation replaced an existing Autumn customer; the previous subscription is now orphaned and needs manual reconciliation提示旧订阅已孤儿化需要人工对账。幂等性与恢复场景控制台/activate是幂等的一个密钥固定映射到一个 Autumn 客户。因此客户在全新实例上重新激活同一个密钥会拿到同一个autumnCustomerId与同一组凭证。这正是客户丢失实例后支持团队把密钥还给客户即可恢复这一运维流程的实现基础。权益刷新Autumn 是唯一事实来源refreshEntitlements见 autumn-utils.ts的实现要点通过resolveClientForPlatform取得客户级 Autumn 客户端读取platform_plan上保存的凭证拉取客户数据getCustomerexpand: [subscriptions.plan, purchases.plan]调用mapAutumnFeaturesToPlatformPlan把 entitlements 投影为platform_plan上的字段并落库包括plan套餐标识billedTeamProjectsLimit、usersLimit、activeFlowsLimit分别来自TEAM_PROJECTS_LIMIT、USERS_LIMIT、ACTIVE_FLOWS_LIMIT余额usersLimit/activeFlowsLimit缺省时为nullbilledTeamProjectsLimit缺省为1includedCredits来自AP_CREDITS余额的grantedscheduledUsersLimit排期中的降级套餐以及一整组布尔功能旗标tablesEnabled、eventStreamingEnabled、environmentsEnabled、analyticsEnabled、showPoweredBy、auditLogEnabled、embeddingEnabled、aiProvidersEnabled、chatEnabled、agentsEnabled、workerGroupsEnabled、managePiecesEnabled、manageTemplatesEnabled、customAppearanceEnabled、projectRolesEnabled、globalConnectionsEnabled、customRolesEnabled、apiKeysEnabled、ssoEnabled、secretManagersEnabled、scimEnabled全部由 Autumn 返回的grantedFeatureIds集合驱动写入客户状态缓存billingEnforced、积分余额等供计费闸门快速读取、失效计费概览缓存并执行provisionLicenseKeyIfPaid。懒注册与密钥补发ensureEnrolled懒注册在distributedLock下执行若platform_plan中已存有licenseKey则通过控制台重新激活否则调用enrollFree以平台所有者的邮箱在 Autumn 免费注册。注册完成后同样会刷新权益。provisionLicenseKeyIfPaid付费补发在refreshEntitlements过程中自服务self-serve付费客户若从未录入密钥系统会请控制台铸一枚新密钥POST /api/v1/billing/provision-license-key并保存到platform_plan.licenseKey。这样每一个付费平台最终都会拥有一个恢复句柄。免费/AppSumo/免费遗留套餐FREE、APPSUMO、FREE_LEGACY会被跳过。API 端点一览1.POST /v1/platform-billing/activate平台管理员请求体{ licenseKey }鉴权为securityAccess.platformAdminOnly([USER])。它是billingProvider.activateLicense的薄封装platformId取自 principal——这是终端用户自托管管理员激活密钥的正式入口。2.POST /v1/admin/platforms/apply-license-key云管理员面向 Activepieces 云运维/支持人员请求体为{ email, licenseKey }schema 见 platform.request.ts 的ApplyLicenseKeyByEmailRequestBody。实现位于 admin-platform.controller.ts 与 admin-platform.service.ts模块级preHandlercheckCertainKeyPreHandler检查请求头api-key是否等于AppSystemProp.API_KEY未配置时一律 403服务端applyLicenseKeyByEmail先用邮箱解析用户身份再定位platformRole: PlatformRole.ADMIN的用户及其所属平台最后调用与终端入口同一个activateLicense。因此两个端点的语义完全一致支持团队无需拿到客户的登录态只要知道客户邮箱即可代为激活。自动试用激活链接/?licenseKey…为了让销售能一次点击完成试用开通系统支持在任意来源页面上携带/?licenseKey…链接完成自动激活。整个过程不落任何存储密钥由 URL 跨登录携带。登录前后的路由接力DefaultRoute会把pathname search整体折叠进from登录后useRedirectAfterLogin再导航回该地址对于 Google/SAML 这类外部登录from会搭载在 OAuth 的state参数上其背景是AuthenticatedDefaultRoute要求最后一跳必须学会携带location.search详见 ce-authentication.md 的相关说明链接参数的常量名是TRIAL_KEY_QUERY_PARAM licenseKey见 route-utils.ts。消费端本仓库与生成端控制台仓库之间唯一的约定就是这个查询参数名——若改动参数名或迁移路由控制台仍会继续派发静默失效的链接。历史上曾有一个实现密钥先暂存进sessionStorage并在登录时无条件剥离参数。由于写入用tryCatchSync静默抑制、剥离却不带条件在 Web Storage 被屏蔽的来源沙箱 iframe、禁用 Cookie 的浏览器、把setItemstub 掉且无法抛错的无痕扩展上密钥会从两处同时消失。该实现已被移除改为下述先捕获、后擦除的方案。前端组件AutomaticTrialActivation与TrialActivationScreen组件源码位于 automatic-trial-activation.tsx被渲染在AllowOnlyLoggedInUserOnlyGuard内部见 allow-logged-in-user-only-guard.tsx一旦平台存在便接管整个视口判定时机AutomaticTrialActivation在惰性useState初始化器中决定是否展示——所有输入查询参数、platform、edition、平台角色要么是 suspense 查询、要么是同步读取没有需要等待的东西同时必须在挂载时捕获alreadyLicensed否则激活后的平台 refetch 会在彩带动画中途卸载成功面板。先捕获、后擦除密钥从首次渲染起就存在于 React state 中屏幕在挂载时删除 URL 参数scrubbed.delete(TRIAL_KEY_QUERY_PARAM)后setSearchParams(..., { replace: true })。因此 URL 副本只在密钥已安全持有时才被丢弃。两个已知后果刷新后参数已擦除、密钥丢失用户需重播原始链接若父级组件跳过渲染社区版或已授权则无组件去擦除参数会残留到下一次导航。单一状态now屏幕只持有一个挂载时执行的useEffect——触发激活并启动 250ms 的时钟视图、进度条、客户端超时与跳转倒计时全部由该时钟加 mutation 的isPending/isSuccess/isError派生出来而非另存状态。激活请求仍然 POST 到既有的POST /v1/platform-billing/activate前端封装为platformApi.activateLicenseKey见 platforms-api.tsmutation 为useUpdateLisenceKey见 platform-hooks.ts并显式抑制两次 toastmessages: { success: null, error: null }因为界面自己渲染结果。四种状态activating带一条渐近式的伪进度曲线、success彩带 5 秒后跳转默认路由、not_admin提供可转发的链接、failed重试按钮 支持邮箱 mailto。为什么是组件而非 HookAutomaticTrialActivation必须做成组件是因为父级 guard 的提前 return 会使条件性 Hook 调用违反 React 规则。生成端激活链接由控制台构建其仓库内的packages/web/src/lib/activation-link.ts在许可证密钥表格和密钥创建成功页上以 Copy activation link 形式出现AP 仓库只负责消费。前端展示组件 license-key.tsx 负责自托管场景下展示/复制已有密钥CopyToClipboardInput以及切换 Activate trial key / Activate license key / Update license key 的激活对话框入口activate-license-dialog.tsx。必须知道的边界与陷阱Gotchas社区版CE下激活路由直接 404billingProvider.activateLicense虽是 CE no-op但platformPlanModule只在ApEdition.CLOUD与ApEdition.ENTERPRISE下注册见 app.ts 的 edition 分支因此POST /v1/platform-billing/activate在 CE 上不存在。任何复用的共享前端代码必须先判断EDITION标志再调用激活否则 CE 自托管用户会看到激活失败真实原因其实是AP_EDITIONce。AP 从不读取密钥内容许可证数据license_keys表、套餐与期限、试用签发、autumn_customers台账全部由控制台拥有旧世界密钥里带逐功能开关的模型已不存在。控制台校验先于落库activateLicense中控制台调用发生在platform_plan.licenseKey保存之前——被拒绝的密钥永远不会被持久化。控制台地址是硬编码常量AUTUMN_CONSOLE_URL在 autumn-utils.ts 中由system.getOrThrow(AppSystemProp.AUTUMN_CONSOLE_URL)取到并规范化去掉尾部/当前指向测试控制台所有控制台请求都经由safeHttp并带请求超时CONSOLE_REQUEST_TIMEOUT_MS 30000客户读取超时5000ms。AP 侧没有过期任务platform_plan.licenseKey列保留但 AP 不运行任何 expiry job——套餐失效由控制台/Autumn 侧处理最终通过权益刷新落到 AP。非试用密钥的expiresAt目前无效控制台的 comp 附加使用customize: { price: null }且不带ends_at被补偿的套餐永不失效AP 端也没有任何代码读取licenseExpiresAt。试用期从签发日而非激活日计算控制台两条铸钥路径销售的licenseKeysService.create、自助表单的externalService.generateKey都会在创建时即写入expiresAt now valid_days并把activatedAt也置为同一时间戳列名有误导性从未被重新盖章。控制台的activate只读取expiresAt并挂接剩余天数trialDays ceil((expiresAt - now) / day)。也就是说客户每多等一天激活就损失一天试用——20 天密钥在第 8 天激活只剩 12 天第 21 天激活则落入下面第 7 条的死密钥场景。目前唯一的补救手段是销售手动延长到期时间。expiresAt为空或已过期的试用密钥激活后没有套餐控制台activate仅在isTrial trialDaysRemaining(expiresAt) 1时挂套餐否则仅当!isTrialcomp时挂——剩余天数四舍五入为 0 的试用密钥两个分支都进不去客户被创建但无订阅Autumn 的auto_enable会把它放到free上。升级后的首次请求该平台就会看到所有 EE 旗标被吊销、只剩 1 个席位、billingEnforced开启、带 powered-by 品牌标识。刷新时 Autumn 套餐是唯一事实来源mapAutumnFeaturesToPlatformPlan执行flags[feature] entitlements.flags[feature] ?? false——目标套餐未包含的任何旗标都会被吊销。因此若许可证→套餐的映射在某个 feature 上遗漏客户会被静默降级。发布迁移前务必对照线上 Autumn 目录逐旗标审计而不是只看套餐级别。失败是可重试的 fail-safe若控制台调用抛错凭证不会被保存既有platform_plan旗标原样保留ensureEnrolled每 300 秒重试一次getEnrollAttemptKey权益刷新之后每 15 分钟节流一次。Cloud 计费页同样展示激活区当platform_plan.licenseKey为空时标签显示 Trial Keys云平台的密钥通常是销售分发的企业试用密钥。该区块曾藏在计费路由的 AltA 快捷键彩蛋后面因支持人员无法引导客户操作而移除了该揭示机制。无密钥注册 ≠ 旧版开源默认套餐enrollFree会把平台落到 AutumnfreeaiProvidersEnabled: false、usersLimit: 1、billingEnforced: true、showPoweredBy: true这比旧版未授权 EE 实例获得的OPEN_SOURCE_PLAN范围明显更窄——选择无密钥运行前需知晓这一差异。关键文件索引职责文件激活入口控制器POST /v1/platform-billing/activateplatform-plan.controller.ts计费接缝CE no-op 的activateLicensebilling-provider.tsEE 激活实现activateLicenseautumn-billing.tsautumnConsole.activate、ensureEnrolled、refreshEntitlements、provisionLicenseKeyIfPaidautumn-utils.ts云管理端apply-license-key路由与api-key守卫admin-platform.controller.ts、admin-platform.service.tsApplyLicenseKeyByEmailRequestBodyschemaplatform.request.ts前端激活对话框与密钥展示activate-license-dialog.tsx、license-key.tsx自动试用激活全屏四态automatic-trial-activation.tsx前端 API 封装与 mutationplatforms-api.ts、platform-hooks.ts查询参数常量licenseKeyroute-utils.tsplatformPlanModule的 edition 注册条件app.ts综上Activepieces 的 License Key 机制是一套密钥仅作句柄、权益全部来自 Autumn 投影的现代计费架构激活、恢复、试用与自助补发都围绕控制台展开而 AP 侧通过billingProvider接缝保持了 CE 与 EE 的清晰分界。理解上述调用链与边界条件是排查自托管激活失败、试用期异常缩短或功能被静默降级等问题的前提。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考