拓冰网站定制 
Cate Cloud路线图解读EC2工作区、mTLS网关与持久化终端的云端IDE蓝图【免费下载链接】cateAn infinite zoomable canvas for coding. Editor, terminal, and browser panels in a spatial workspace.项目地址: https://gitcode.com/gh_mirrors/cate5/cateCate Cloud 是 Cate一款无限画布代码编辑器即将推出的云端开发工作区基于 EC2 虚拟机、mTLS 安全网关和持久化终端构建让开发者不必在本地机器上运行多个终端 CLI、AI 智能体和开发服务器。本文完整解读这份云端 IDE 蓝图的架构设计、安全策略与交付里程碑帮助你提前理解远程终端与云工作区将如何工作。三个核心概念云工作区、运行时段与客户端连接在理解 Cate Cloud 云端 IDE 之前先分清三个容易混淆的概念也常常被混为一谈的对象云工作区Cloud Workspace拥有持久化的机器身份、文件系统、仓库、worktree、设置和计费归属工作区运行Workspace RunEC2 实例实际运行的时间段客户端连接Client Connection当前正附着到工作区的 Cate 桌面端这份设计里最关键的产品决策是断开连接永远不会停止工作区。完整的行为矩阵如下用户操作EC2 状态进程文件计算计费关闭 Cate运行中继续持久化继续断网运行中继续持久化继续重连运行中重新附着持久化继续停止工作区已停止终止持久化停止删除工作区已终止终止保留期后删除停止这意味着你可以挂着五个 AI 智能体跑代码安心合上笔记本——云端 EC2 工作区里的进程和文件都还在计费按秒继续直到你主动停止。每个工作区一台 EC2简单优先的云端架构Cate Cloud 刻意避开了构建完整 PaaS 的诱惑不运营 hypervisor、不做分布式存储、不上裸金属集群。架构刻意窄小正如官方路线图 plan.md 中描绘的拓扑Cate 桌面端 ├── HTTPS ── Cate Cloud API认证 / 生命周期 / PostgreSQL / 计费 └── WSS ──── Cate 区域网关 │ 出站 mTLS 连接 ▼ EC2 工作区实例 ├── cate-runner监督进程 │ └── cate-runtime │ ├── PTY 终端 │ ├── 智能体 │ ├── git │ └── 隧道 └── 加密 EBS 数据卷每个工作区的标配是一台 On-Demand EC2 实例 加密的 EBS 卷。产品层面只暴露三种机器规格而不让用户直面 EC2 实例名Standard2 vCPU / 4 GB / 30 GBLarge2 vCPU / 8 GB / 50 GBCompute4 vCPU / 8 GB / 50 GB一个值得注意的工程细节根卷与工作区卷分离。根卷存放操作系统和cate-runner工作区卷/workspace、仓库、.cate状态、智能体会话才是用户数据。这样工作区可以无损重建到打过补丁的新 AMI 上不用复制仓库。mTLS 网关不暴露 VM 的桌面连接方式这是整个云端 IDE 安全模型的核心。网关Gateway负责把桌面端和云端的 runner 连起来但工作区实例没有任何入站安全组规则没有 SSH 服务没有实例 IAM 角色没有 AWS 凭据——外界完全够不到这台 VM。连接方向是反过来的实例上的cate-runner提交其签名的 EC2 实例身份文档instance-identity document控制平面验证 AWS 签名、账户、区域、实例 ID、工作区标签和代际控制平面签发一张短生命周期的 runner 证书Runner 主动发起一条出站 mTLS WebSocket连接到区域网关之后桌面端与 runner 之间的所有通信都经网关转发。连接票据connection ticket的设计同样讲究30–60 秒过期、一次性使用、绑定用户/组织/工作区/代际/客户端 ID并且明确授予交互式或只读访问。网关不解释文件系统或终端操作只做协议帧转发并对字节数和连接数施加限制——终端内容永远不会被记录日志。持久化终端断网 30 分钟终端进程不掉线对云端 IDE 来说终端断连不杀进程是生死线。现有本地守护进程在 stdin 关闭时会退出并杀掉所有子进程——这在本地开发无所谓但在断网随时会发生的云端不可接受。路线图的解法是让cate-runner永久持有 runtime 的 stdin并为协议新增一组持久化终端能力pty.list/pty.attach(ptyId, afterSequence)/pty.detach终端输出带序列号每个 PTY 有界回卷建议 4 MB每工作区缓冲上限 64 MB先丢最旧的握手时携带 runtime 代际可显式接管现有写入者各故障场景的预期行为设计得非常克制且清晰故障预期行为桌面端断网RPC 客户端重连进程继续网关重启runner 与桌面端重连进程继续Cate 应用重启面板按持久化 PTY ID 重新附着EC2 重启PTY 消失面板打开替补 shell显式停止工作区PTY 消失文件保留对 Agent 面板智能体框架可以在应用完全重启后从持久化的会话状态恢复附着到正在执行中的智能体回合是后续扩展。端口预览与 GitHub 仓库接入云端跑的开发服务器如何预览答案依然绕开入站端口Cate 检测到监听端口 → 用户点Open preview → 网关经 runner 打通隧道 → 浏览器面板拿到 Cate 认证的 URL。预览默认私有、短命、HTTPS、限流工作区停止时自动吊销网关每次连接都校验成员资格。仓库接入则选择 GitHub App 而非个人访问令牌用户为选定仓库安装 Apprunner 按需领取短生命周期的安装令牌仓库克隆到/workspace之后的 fetch/push 由 Cate 凭据助手实时换新。v1 只支持 GitHub HTTPS一个工作区一个主仓库worktree 在工作区卷内正常管理。计费与安全防护姿态计费采用用量段usage segment模型EC2 进入 running 时开启stopping/stopped/terminated 时关闭靠 EventBridge 事件驱动、每分钟与 EC2 对账、账本事件幂等。产品承诺绝不在预算阈值上悄悄停掉正在运行的智能体——只发警告让用户自己选择限额是建议性的还是强制性的。安全基线可以概括为一句话控制平面与工作区数据平面分账户、分网络且工作区实例永远无法反向触达数据库。其他要点包括IMDSv2 强制、非 root 的cate用户无 sudo、EBS 默认加密、每工作区独立 mTLS 证书、禁止跨工作区访问、阻断 SMTP、磁盘配额告警以及终端内容零日志。四个交付里程碑路线图怎么看官方把落地切成四个可验收的阶段详见 plan.md 的 Delivery milestones 一节里程碑 1 · 垂直切片单区域、固定机型、公开 GitHub 仓库跑通创建→启动→连接→停止→删除全链路。验收标准包括仓库在停止和启动后依然存活、实例不存在任何入站端口里程碑 2 · 持久化终端runner 监督、网关重连、PTY 列表与附着、序列号回卷。验收标准很硬核——10 个终端 CLI 在桌面端断开 30 分钟后全部存活网关重启零进程丢失里程碑 3 · 付费私测登录、GitHub App、私有仓库、密钥注入、端口预览、Stripe 账本、消费告警、加密快照。验收标准是用户无法访问他人的工作区、预览、卷或 runner里程碑 4 · 生产加固多可用区网关、第二区域、AMI 金丝雀发布、容量回退、滥用检测、混沌测试以及可选的休眠Hibernation而 v1明确不做的清单同样有价值Kubernetes、Spot 实例、GPU、Windows 工作区、Docker-in-Docker、root/sudo、团队协同编辑、自动闲置停止、多云调度全部被推到之后。写在最后这份蓝图想证明什么路线图最后一节初始商业品质目标其实是一句话产品定义用户可以创建一台 EC2 支撑的工作区运行多个 CLI 智能体关闭 Cate之后重连回同样的 PTY然后停止工作区——确信计算计费已经结束而仓库和 worktree 完好无损。Cate Cloud 的野心不是再造一个云端 IDE而是把桌面端已经打磨好的那套运行时终端、git、智能体、画布面板原样搬上云桌面端新增Ec2ManagedTransport复用现有 RuntimeTransport 抽象文件系统、git、终端、编辑器消费者一律不改。对普通用户而言这意味着本地连不上大项目、本地机器跑不动五个智能体的场景未来可能只需要点一下创建云工作区。如果你对智能体面板、worktree 空间画布等桌面端能力也有兴趣可以查看 README.md 与 CONTRIBUTING.md 了解项目的完整面貌与贡献方式。【免费下载链接】cateAn infinite zoomable canvas for coding. Editor, terminal, and browser panels in a spatial workspace.项目地址: https://gitcode.com/gh_mirrors/cate5/cate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cate Cloud路线图解读：EC2工作区、mTLS网关与持久化终端的云端IDE蓝图
Cate Cloud路线图解读EC2工作区、mTLS网关与持久化终端的云端IDE蓝图【免费下载链接】cateAn infinite zoomable canvas for coding. Editor, terminal, and browser panels in a spatial workspace.项目地址: https://gitcode.com/gh_mirrors/cate5/cateCate Cloud 是 Cate一款无限画布代码编辑器即将推出的云端开发工作区基于 EC2 虚拟机、mTLS 安全网关和持久化终端构建让开发者不必在本地机器上运行多个终端 CLI、AI 智能体和开发服务器。本文完整解读这份云端 IDE 蓝图的架构设计、安全策略与交付里程碑帮助你提前理解远程终端与云工作区将如何工作。三个核心概念云工作区、运行时段与客户端连接在理解 Cate Cloud 云端 IDE 之前先分清三个容易混淆的概念也常常被混为一谈的对象云工作区Cloud Workspace拥有持久化的机器身份、文件系统、仓库、worktree、设置和计费归属工作区运行Workspace RunEC2 实例实际运行的时间段客户端连接Client Connection当前正附着到工作区的 Cate 桌面端这份设计里最关键的产品决策是断开连接永远不会停止工作区。完整的行为矩阵如下用户操作EC2 状态进程文件计算计费关闭 Cate运行中继续持久化继续断网运行中继续持久化继续重连运行中重新附着持久化继续停止工作区已停止终止持久化停止删除工作区已终止终止保留期后删除停止这意味着你可以挂着五个 AI 智能体跑代码安心合上笔记本——云端 EC2 工作区里的进程和文件都还在计费按秒继续直到你主动停止。每个工作区一台 EC2简单优先的云端架构Cate Cloud 刻意避开了构建完整 PaaS 的诱惑不运营 hypervisor、不做分布式存储、不上裸金属集群。架构刻意窄小正如官方路线图 plan.md 中描绘的拓扑Cate 桌面端 ├── HTTPS ── Cate Cloud API认证 / 生命周期 / PostgreSQL / 计费 └── WSS ──── Cate 区域网关 │ 出站 mTLS 连接 ▼ EC2 工作区实例 ├── cate-runner监督进程 │ └── cate-runtime │ ├── PTY 终端 │ ├── 智能体 │ ├── git │ └── 隧道 └── 加密 EBS 数据卷每个工作区的标配是一台 On-Demand EC2 实例 加密的 EBS 卷。产品层面只暴露三种机器规格而不让用户直面 EC2 实例名Standard2 vCPU / 4 GB / 30 GBLarge2 vCPU / 8 GB / 50 GBCompute4 vCPU / 8 GB / 50 GB一个值得注意的工程细节根卷与工作区卷分离。根卷存放操作系统和cate-runner工作区卷/workspace、仓库、.cate状态、智能体会话才是用户数据。这样工作区可以无损重建到打过补丁的新 AMI 上不用复制仓库。mTLS 网关不暴露 VM 的桌面连接方式这是整个云端 IDE 安全模型的核心。网关Gateway负责把桌面端和云端的 runner 连起来但工作区实例没有任何入站安全组规则没有 SSH 服务没有实例 IAM 角色没有 AWS 凭据——外界完全够不到这台 VM。连接方向是反过来的实例上的cate-runner提交其签名的 EC2 实例身份文档instance-identity document控制平面验证 AWS 签名、账户、区域、实例 ID、工作区标签和代际控制平面签发一张短生命周期的 runner 证书Runner 主动发起一条出站 mTLS WebSocket连接到区域网关之后桌面端与 runner 之间的所有通信都经网关转发。连接票据connection ticket的设计同样讲究30–60 秒过期、一次性使用、绑定用户/组织/工作区/代际/客户端 ID并且明确授予交互式或只读访问。网关不解释文件系统或终端操作只做协议帧转发并对字节数和连接数施加限制——终端内容永远不会被记录日志。持久化终端断网 30 分钟终端进程不掉线对云端 IDE 来说终端断连不杀进程是生死线。现有本地守护进程在 stdin 关闭时会退出并杀掉所有子进程——这在本地开发无所谓但在断网随时会发生的云端不可接受。路线图的解法是让cate-runner永久持有 runtime 的 stdin并为协议新增一组持久化终端能力pty.list/pty.attach(ptyId, afterSequence)/pty.detach终端输出带序列号每个 PTY 有界回卷建议 4 MB每工作区缓冲上限 64 MB先丢最旧的握手时携带 runtime 代际可显式接管现有写入者各故障场景的预期行为设计得非常克制且清晰故障预期行为桌面端断网RPC 客户端重连进程继续网关重启runner 与桌面端重连进程继续Cate 应用重启面板按持久化 PTY ID 重新附着EC2 重启PTY 消失面板打开替补 shell显式停止工作区PTY 消失文件保留对 Agent 面板智能体框架可以在应用完全重启后从持久化的会话状态恢复附着到正在执行中的智能体回合是后续扩展。端口预览与 GitHub 仓库接入云端跑的开发服务器如何预览答案依然绕开入站端口Cate 检测到监听端口 → 用户点Open preview → 网关经 runner 打通隧道 → 浏览器面板拿到 Cate 认证的 URL。预览默认私有、短命、HTTPS、限流工作区停止时自动吊销网关每次连接都校验成员资格。仓库接入则选择 GitHub App 而非个人访问令牌用户为选定仓库安装 Apprunner 按需领取短生命周期的安装令牌仓库克隆到/workspace之后的 fetch/push 由 Cate 凭据助手实时换新。v1 只支持 GitHub HTTPS一个工作区一个主仓库worktree 在工作区卷内正常管理。计费与安全防护姿态计费采用用量段usage segment模型EC2 进入 running 时开启stopping/stopped/terminated 时关闭靠 EventBridge 事件驱动、每分钟与 EC2 对账、账本事件幂等。产品承诺绝不在预算阈值上悄悄停掉正在运行的智能体——只发警告让用户自己选择限额是建议性的还是强制性的。安全基线可以概括为一句话控制平面与工作区数据平面分账户、分网络且工作区实例永远无法反向触达数据库。其他要点包括IMDSv2 强制、非 root 的cate用户无 sudo、EBS 默认加密、每工作区独立 mTLS 证书、禁止跨工作区访问、阻断 SMTP、磁盘配额告警以及终端内容零日志。四个交付里程碑路线图怎么看官方把落地切成四个可验收的阶段详见 plan.md 的 Delivery milestones 一节里程碑 1 · 垂直切片单区域、固定机型、公开 GitHub 仓库跑通创建→启动→连接→停止→删除全链路。验收标准包括仓库在停止和启动后依然存活、实例不存在任何入站端口里程碑 2 · 持久化终端runner 监督、网关重连、PTY 列表与附着、序列号回卷。验收标准很硬核——10 个终端 CLI 在桌面端断开 30 分钟后全部存活网关重启零进程丢失里程碑 3 · 付费私测登录、GitHub App、私有仓库、密钥注入、端口预览、Stripe 账本、消费告警、加密快照。验收标准是用户无法访问他人的工作区、预览、卷或 runner里程碑 4 · 生产加固多可用区网关、第二区域、AMI 金丝雀发布、容量回退、滥用检测、混沌测试以及可选的休眠Hibernation而 v1明确不做的清单同样有价值Kubernetes、Spot 实例、GPU、Windows 工作区、Docker-in-Docker、root/sudo、团队协同编辑、自动闲置停止、多云调度全部被推到之后。写在最后这份蓝图想证明什么路线图最后一节初始商业品质目标其实是一句话产品定义用户可以创建一台 EC2 支撑的工作区运行多个 CLI 智能体关闭 Cate之后重连回同样的 PTY然后停止工作区——确信计算计费已经结束而仓库和 worktree 完好无损。Cate Cloud 的野心不是再造一个云端 IDE而是把桌面端已经打磨好的那套运行时终端、git、智能体、画布面板原样搬上云桌面端新增Ec2ManagedTransport复用现有 RuntimeTransport 抽象文件系统、git、终端、编辑器消费者一律不改。对普通用户而言这意味着本地连不上大项目、本地机器跑不动五个智能体的场景未来可能只需要点一下创建云工作区。如果你对智能体面板、worktree 空间画布等桌面端能力也有兴趣可以查看 README.md 与 CONTRIBUTING.md 了解项目的完整面貌与贡献方式。【免费下载链接】cateAn infinite zoomable canvas for coding. Editor, terminal, and browser panels in a spatial workspace.项目地址: https://gitcode.com/gh_mirrors/cate5/cate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考