Skip to main content
Nuphos is a shared DevOps platform for the AI agents your team already uses. It gives those agents infrastructure access and operational context under your team’s control. A few concepts run through everything else in these docs. Read this page once and the rest will make sense.

​
Teams

A team is the top-level container in Nuphos. Every connected account, agent session, plan, and memory belongs to a team. You create a team the first time you sign in, and you invite colleagues into it. Members have one of three roles: Connecting cloud accounts and other connectors requires the Administrator role. See Teams & members.

​
Scopes & the workspace

Nuphos organizes everything you can see into a hierarchy of scopes:
You navigate down into a scope (for example: your team → an AWS account → an EKS cluster → a pod) and the breadcrumb keeps your place. The workspace is tab-based, so you can keep several scopes open at once — an agent chat in one tab, a cluster’s pods in another.

​
Your agent and its runtime

Nuphos does not ask you to adopt a Nuphos-built model or agent. The agent is the one you connect; the runtime is the isolated environment where it runs. You describe what you want in natural language — “why is the checkout deployment crash-looping?” — and your agent investigates with the shell, cloud APIs, Kubernetes, and skills Nuphos makes available. Today Claude Code is the first agent enabled in Nuphos. The runtime is built on OpenAB, so the integration boundary is the terminal coding agents it supports—Claude Code, Codex, Gemini CLI, Kiro CLI, and others—while each agent keeps its vendor-provided harness. See Agent runtime. Two ideas make the agent safe to point at production:
  • The runtime only receives credentials you select for that session (see below).
  • Anything that changes your infrastructure is proposed as a plan that a human approves before it runs.
See Agent sessions.

​
Plans & approvals

A plan is the agent’s proposal for a change. It contains an overview, the key decisions, and a tree of steps → jobs → commands, plus a risk and cost assessment. Nothing in a plan runs until a team member approves it. A plan moves through a clear lifecycle:
Every approval is attributed and timestamped, giving you an audit trail of who let what happen. See Plans & approvals and Approvals & audit.

​
Shared memory

As you work, Nuphos records durable facts learned by your agent — service names, ownership, runbooks, how a deploy flows — as memory. Memory is shared across the team, so the next person’s agent already knows what the last one learned. You can review and prune what the agent remembers. See Agent memory.

​
Credentials & the IAM model

Nuphos does not place your long-lived cloud keys in an agent runtime. Instead, you connect an account once by establishing a trust relationship, and Nuphos mints short-lived, per-session credentials on demand:
  • AWS — Nuphos assumes an IAM role in your account via OIDC web-identity federation. Each session gets temporary credentials that expire in ~1 hour.
  • GCP — Nuphos impersonates a service account you designate, minting access tokens that expire in ~1 hour.
On top of that, administrators can restrict any connected account to specific team members with a member allow-list, and the agent only sees the credentials explicitly selected for the current session. This is the foundation of least-privilege in Nuphos — see Access control and the IAM trust model.

Quickstart

Put these concepts to work in a few minutes.

Connect an account

Establish the trust relationship for AWS, GCP, and more.