Teams

Share a server inventory, an SSH-key vault, secrets configuration, and an AI budget across a group of people. Per-seat billing, role-based access, a full audit trail. Once your team is set up, everyone works from the same fleet — in the TUI, from scripts, or through AI agents.

What you get

• Shared server inventory — every member sees the same fleet, sorted, filtered, and searchable.
• Team SSH-key vault — point the team at a single Bitwarden vault so credential rotation is one update, not n.
• Team secrets config — same idea, for non-SSH secrets (DB passwords, API keys) used in scripts. See Secrets & Integrations.
• Role-based access — owner / admin / member. Permissions are enforced on every request; there is no client-side trust.
• Audit trail — every membership, config, and credential change is logged.
• Shared server knowledge — server-memory annotations and agent-discovered findings sync within the team, so notes written on one machine are available to everyone. See Server Memory.
• Per-seat AI budget — each seat gets its own Servonaut AI quota; see Servonaut AI.
• Hosted MCP connections — higher per-seat allowance than the Solo plan. See Pricing for the current numbers.

Roles

Creating a team

1. Subscribe to the Teams plan. Pick a seat count on the pricing page — start with 1 if you're unsure, you can add seats later. Stripe handles the checkout.
2. Open /account/teams and create the team. Pick a name and a URL slug — the slug identifies your team in invite links, dashboard URLs, and team API endpoints. (You never type it to switch context in the CLI — context is resolved automatically; see team context.)
3. Invite teammates by email. They get a one-click join link; their account is created on accept if they don't already have one.
4. Configure shared SSH via /account/integrations — the "Team SSH Key Config" card only shows up when you're the owner or admin of a Teams subscription. Team secrets for scripts are configured the same way; see Secrets & Integrations.
5. Add shared servers to the team inventory. Each shared server can have its own credential ref (per-server Bitwarden item), independent from the team default.

Using your team in the TUI

Day to day, your team lives inside the regular TUI — there is no separate "team mode". Launch servonaut and:

• Sign in once per machine. Open Account → Login in the sidebar (or run servonaut login beforehand). Sign-in uses a device flow: you get a URL and a short code to approve from any browser, on any device — handy on remote boxes. The sidebar shows ● connected once the session is live, and the same session is shared by the TUI, the CLI, and the MCP server.
• Shared servers appear in your instance list alongside your own AWS, OVHcloud, Hetzner, and custom servers. Select one to open its Server Actions dashboard — SSH, run commands, browse files, stream logs, and transfer files exactly as you would on a personal server, using the team SSH credentials.
• Manage membership from the Account → Teams screen: see which teams you belong to and your role in each. Invites, role changes, and seat management happen in the web dashboard.
• Team knowledge follows you. Server-memory annotations written by any teammate sync to your machine and show up in the memory screen and AI chat context for shared servers.

A newly joined member just needs to accept the email invitation and sign in (Account → Login or servonaut login) — the shared inventory appears on their next refresh, no extra setup.

Invitations & seat limits

Inviting a member counts a seat toward your cap — both at invite time and at accept time. Seat caps are checked again on acceptance, so a member who accepts an old invitation can never push you over your paid seat count. If you're already at the cap, the invite is rejected and you're pointed to Billing to add seats.

Shared servers

A shared server is an entry in the team's inventory: name, provider (aws / ovh / hetzner / custom), instance id, optional username + port, optional credential ref. Once added, every team member sees it in their TUI instance list and CLI, and can run servonaut ssh <instance-id> — provided the team SSH config points at a vault they can also unlock.

Billing & seat management

• Add seats — /account/billing, "Add seats" button. Proration is handled by Stripe.
• Remove seats — same place. You can't go below the current head count without first removing members.
• Switch monthly ↔ yearly — yearly saves two months. Stripe prorates the in-flight period.
• Cancel — cancellation takes effect at period end. Members lose Teams-only features (shared servers, team SSH config) but keep their personal data and personal credentials.

Audit log

Every team-level state change is recorded: invitations, role changes, seat-cap bumps, SSH and secrets config rotations, member removal, plan switches. Each entry keeps actor, action, before/after diff, IP, and timestamp.

Owners and admins review the trail on the team's Audit page in the account dashboard: open /account/teams, select your team, then Audit. The page is filterable, and you can export the matching entries as a CSV for compliance or offline review.

Automating with the CLI: team context

The CLI resolves which team you're acting as automatically — there is no switch command. If you own a team, that team is your active context; otherwise your first team membership is used, and users with no teams operate in their personal context. If your membership changes, the CLI re-resolves on the next request.

Server inventory, SSH config resolution, and AI quota all respect the active context. That makes team-aware scripting boring in the best way — the same commands work for every member:

servonaut login works on headless boxes and CI runners: it prints a verification URL and a short code you approve from any browser. Tokens are stored at ~/.servonaut/auth.json (mode 0600) and shared by every CLI subcommand, the MCP server, and the TUI.

For AI agents

AI agents see your team the same way you do. The MCP server (local servonaut --mcp or the hosted one) operates under your active team context, so team-scoped inventory, SSH resolution, and AI budget apply to agent tool calls too. An agent can verify the active session and team context at any time with the whoami tool. The MCP page covers the full tool catalogue and guard levels.

• Team MCP policy. Owners and admins can control which MCP tools team members' agents may use via the team policy API: GET/PUT /api/v1/teams/{slug}/mcp-policy. The policy supports an allowed_tools list, a blocked_tools list, a require_approval list, and a max_connections cap. Members can read the policy; only owners and admins can change it, and changes are audit-logged.
• Shared agent findings. Agents can persist discoveries about shared servers with the remember_server_finding / recall_server_findings tools. Findings sync alongside server memory, so what one teammate's agent learns is recallable by everyone's — recalled results carry a provenance notice so models treat them as reference data, not instructions.
• Remote dispatch via the relay. Running servonaut connect on a machine (or letting the TUI start the listener after login) lets hosted AI chats dispatch tool calls to it over the internet. With no human present to confirm, approval is policy-driven: relay.ai_tool_auto_approve in ~/.servonaut/config.json sets the maximum guard tier auto-approved (readonly, standard — the default — or dangerous). Tools above the tier return a denial the model can relay back, and every execution is audit-logged.
• Dangerous-tier tools additionally require the dangerous-AI-tools entitlement on the account — without it they are hidden from chat and refused server-side, regardless of team role.

Data isolation across teams

Every team's server inventory, SSH config, secrets config, AI budget, and audit log is fully isolated. A member of Team A cannot see Team B's data even when they belong to both — every request is checked against the active team context before any data is returned.