云基础设施管理太复杂？Nimbus 让 AI Agent 对话式管理 AWS/GCP

作为开发者，你有没有遇到过这样的场景：凌晨两点，线上告警响了——数据库连接池耗尽，需要扩容。你打开 AWS 控制台，点开 EC2、RDS、ElastiCache，在几十个菜单间来回切换。查了 15 分钟文档才找到正确的 IAM 策略，然后 SSH 登录，手动执行命令。第二天早上你查账单，发现昨晚的临时扩容忘了关，多花了 $87。

更常见的问题是，你的项目用着 AWS 和 GCP 两家云，每次部署新服务都要同时登录两个控制台，对比两套 CLI 命令，记忆不同的服务端点名。每次要读代码、看日志、拉监控、查成本，然后再翻 IaC 文件改配置。一套流程下来，半小时是快的。

这就是 Nimbus 要解决的痛点——一个以对话为核心交互方式的 AI 云控制平面。你只需要用自然语言描述想要的结果，Nimbus 会生成执行计划，你审批后自动完成。读操作全自动，写操作需确认。

⚠️ 许可证说明：Nimbus 使用 BSL 1.1（Business Source License），可自由阅读、自托管、修改，非商业用途免费。商业服务需向维护者申请许可。源码在 github.com/hritvikgupta/nimbus，不是 OSI 批准的开源许可证。

用传统方式有多麻烦？

我们用一个非常常见的场景来量化传统方式的痛点——为现有项目添加缓存层。

这还只是加一个缓存。如果是跨服务重构、数据库迁移、混合云部署，可能需要 2-3 天。而在 Nimbus 里，你只需要说一句：「为我的 Web 应用添加 Redis 缓存，用 t4g.small，只允许应用层访问。」

Nimbus 简介：跟你的云「聊天」

Nimbus 是一个AI 驱动的云控制平面，核心思想非常简单——你用自然语言描述想要的云基础设施状态，Nimbus 生成执行计划、你审批、它自动执行。整个过程中，它是通过 per-user MCP 服务器操作你的云账号，使用你的真实 AWS STS 或 GCP 令牌。

它的设计围绕三个核心理念：

• 意图驱动操作（Intent-driven operations）：说你要什么结果，而不是具体的 CLI 命令。Nimbus 自动生成计划。
• 单一工作空间：每个项目一个共享空间，频道、云连接、机器和架构图都在里面。你和团队的私聊隔离。
• 证据驱动（Real execution, with evidence）：每个回复都基于真实的文件、日志或云资源，而不是模型猜测。写操作有完整审计链。

技术上，Nimbus 是一个 React SPA + Express API，后端有 SQLite 持久化、AES-256-GCM 加密凭证库、以及一套 per-user MCP 服务器（封装了 AWS CLI 和 gcloud 的完整操作面）。

快速上手：Docker 部署

Nimbus 推荐 Docker 方式运行，一条命令启动（完整流程需先克隆仓库并配置）：

git clone https://github.com/hritvikgupta/nimbus.git
cd nimbus
cp .env.example .env

echo "NIMBUS_ENC_KEY=$(openssl rand -base64 32)" >> .env


docker compose up --build

关键的 .env 配置变量：

NIMBUS_ENC_KEY=<生成的密钥>

LLM_PROVIDER=openrouter
OPENROUTER_API_KEY=sk-xxx

COMPOSIO_API_KEY=xxx

启动后访问 http://localhost:8788，登录后即可连接你的云账号——AWS 通过 IAM STS 或密钥，GCP 通过 service-account JSON 或 OAuth。

核心功能：Nimbus 怎么帮你管云？

1. 对话式运维

Nimbus 的核心交互方式就是聊天。你在界面里输入：

检查所有 EC2 实例的 CPU 使用率，列出超过 80% 的。

Nimbus 的 ReAct 循环会调用对应的 MCP 工具，从 AWS 拉取实时数据，返回一个带证据的答案。你不需要记 aws ec2 describe-instances，不需要装 jq 解析 JSON。Nimbus 自动生成查询、返回结构化结果、附带数据来源。

对于写操作，Nimbus 会先展示一份执行计划（plan-then-act）：

计划：创建 1 个 t4g.small ElastiCache 节点（估算成本：$12.45/月） 修改 app/config/database.php 添加 Redis 连接配置 重新部署到 staging 环境 需要你审批后才执行

2. 实时架构画布

当你要设计新架构时，Nimbus 可以实时渲染架构图——告诉它「一个负载均衡器接两个应用实例，后面跟一个 RDS 读写分离」，它会在 React Flow 画布上动态生成节点。你可以看到负载均衡器 → App A → 数据库的连线实时渲染出来：

┌─────────────┐
│  Load Balancer │
└──────┬──────┘
   ┌────┴────┐
┌──▼───┐ ┌──▼───┐
│ App A │ │ App B │
└──┬───┘ └──┬───┘
   └────┬────┘
   ┌────▼────┐
   │  RDS RW  │
   └─────────┘

这个画布不是静态截图——它是可交互的。你可以拖拽、缩放、点选节点查看详细信息。每次对话的新设计都会在画布上叠加，而不是清空重绘。

3. 代码仓库修复（Shared-Compute Repairs）

Nimbus 的独特功能之一是连接你的本地机器或 CI 运行器，通过 @nimbus/cli 拉取代码修复任务。流程是这样的：

1. Nimbus Agent 分析发现数据库连接池需要调整连接数
2. 它使用你的本地 Claude Code 读取代码、修改配置文件
3. 修改完成后自动推分支、开 PR
4. 你在 PR 上 Review 确认

这相当于 Nimbus 不仅是云管理员，还是一个能实际修改项目代码的「平台工程师」。配置通过 @nimbus/cli 连接工作机器：

npm install -g @nimbus/cli
nimbus start 

工作机器需要已安装并登录 Claude Code，以及 git 和 gh 命令行。

4. 多云 + 安全设计

Nimbus 同时支持 AWS 和 GCP，连接方式各有不同：

安全方面，Nimbus 的设计有几个值得注意的点：

• 凭据加密存储：AES-256-GCM，主密钥（NIMBUS_ENC_KEY）只在环境变量中，永不打印或记录
• Plan-then-act：任何创建、修改、删除收费资源的操作都需要你手动审批
• 成员级别访问控制：每个操作都按项目成员权限隔离
• 审计追踪：所有写操作都有服务端记录

适用场景总结

Nimbus 最适合中小团队的多云运维场景——你已经在用 AWS/GCP，团队不超过 20 人，日常运维任务繁重但模式固定（扩缩容、查日志、配基础设施、简单修复）。它不是 K8s 集群管理员工具，也不是 Infra-as-Code 的替代品——它是介于「手动运维」和「全自动化 IaC」之间的一个人机协作层，通过 AI 对话降低重复操作的认知负担。

如果你的痛点恰好是「每次查个云资源都要翻好几个控制台」「每次配基础设施都要查半小时文档」，Nimbus 值得一试。

相关链接：

• GitHub 仓库
• 文档站
• 官网