Teams

Work on the same servers as a group. A team shares a server inventory, SSH keys in an end-to-end encrypted team vault, a secrets provider, encrypted server memory, an AI tool policy and an AI balance, with roles for who can change what and an activity log of every change. 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 team's servers in the TUI, the CLI and the web.
• Servonaut Team Vault — the team's SSH keys, end-to-end encrypted inside Servonaut. New members get access automatically, nobody handles key files, and when someone leaves you see exactly which keys to replace. See Servonaut Vault.
• Or an external vault — keep the keys in a Bitwarden collection instead and give each shared server its key item (details).
• Team secrets — a Bitwarden Secrets Manager project for the non-SSH secrets your scripts use. See Secrets & Integrations.
• Roles — owner, admin, member and viewer. Permissions are checked on the server for every request.
• Shared server memory — share what Servonaut has learned about a server with the team, end-to-end encrypted. See Server Memory.
• MCP tool policy — choose which MCP tools teammates' AI clients may use, and who may run destructive ones.
• One team AI balance — every seat adds £14.50 a month to a single balance the whole team spends from; owners and admins can set a monthly limit per member. See Servonaut AI.
• Activity log — membership, server, access, policy and billing changes, with who made them and when.

Roles

Getting started

1. Subscribe to the Teams plan on the pricing page. You take one seat yourself, so choose at least two seats if you want to invite someone straight away.
2. Open your team. A team named after you is created with the subscription; find it under My Teams. (If you deleted it, create a new one from the same page.) Rename it on its Settings tab. The team's URL name (its slug, e.g. @acme-ops) is set when the team is created and stays the same after a rename. The team's Overview shows a setup checklist for the steps below.
3. Invite teammates from the Members tab: one or more email addresses and a role. Each person gets an email with a link.
4. Add shared servers on the Servers & Access tab, or from the CLI or API.
5. Share SSH access with Servers & Access → Share SSH access. The recommended way is the team vault: you import keys and link them to servers from Servonaut (details). To use Bitwarden instead, choose Advanced: use an external vault and pick the key item for each server (details).
6. Share server memory (optional) on the Memory tab, and review the Policies tab for which AI tools your teammates' AI clients may use.

The team page

Each team has one page with a tab per area. People only see the tabs their role can use:

Using your team in the Servonaut app

Day to day, your team lives inside the regular Servonaut app — there is no separate "team mode". Open the app (servonaut with no arguments) and:

• Sign in once per machine. Open Account / Login in the sidebar and choose Login with servonaut.dev (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 Servonaut app, 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 (members, admins and the owner).
• See your teams on the Account → Teams screen, with your role in each. Invitations, roles and seats are managed on the web, on the team's page.
• Shared memory follows you. Once a server's memory is shared with the team and you have set up your memory key (Memory Sync → Unlock Memory Sync), it shows up in the memory screen and in AI chat context for that server.

Invitations & seats

Owners and admins invite people by email from the Members tab. The invitee opens the link, signs in or creates an account with the invited email address, and accepts. Invitations expire after a few days (7 by default); owners and admins can resend, copy the link, or cancel them while they're pending. A signed-in person with a pending invitation sees it on their dashboard and under My Teams.

After accepting, a new member signs in to Servonaut (Account / Login → Login with servonaut.dev in the Servonaut app, or servonaut login) and the shared inventory appears on the next refresh. With the team vault, they also set up their vault once (Vault → Setup in the app, or servonaut vault setup) and access to the team's keys arrives automatically (see below); with an external vault they need access to the team's Bitwarden collection (see below). Reading shared memory needs a memory key. The team's Overview shows each person what is still missing.

Seats are checked when you invite and again when the invitation is accepted, so an old invitation can never push the team over the seats you pay for. When the team is full, invitations are refused until the owner adds a seat in Billing or someone's invitation is cancelled.

Leaving a team and transferring ownership

• Leave — any member, admin or viewer can leave from the team's ⋯ menu. They lose access straight away.
• Remove — owners and admins remove people from the Members tab (admins can't remove other admins).
• What happens to keys — someone who leaves, is removed or becomes a viewer loses team vault access at once; the vault gets a new key and every secret they could read is listed under Vault → Exposures so you can replace it (details). An external vault is not synced with team membership: remove them in Bitwarden too.
• Transfer ownership — the owner hands the team to a member who has accepted their invitation. Because seats are billed to the owner, the new owner needs their own active Teams subscription with enough seats, and must not own another team. The previous owner becomes an admin.

Shared servers

A shared server is an entry in the team's inventory: a name, the host, an optional SSH user and port, and an optional key reference. Owners and admins add, edit and remove them on the Servers & Access tab (or through the CLI and API); changing the host, user or port resets the server's SSH check. Every member sees the inventory in the Servonaut app and the CLI, and can connect from Instances (select the server, then SSH Connect) or with servonaut ssh <instance-id>; viewers see the inventory but don't connect with the team's keys.

SSH access through the Servonaut Team Vault

The team vault keeps the team's SSH keys end-to-end encrypted: keys are locked on an owner's or admin's computer before upload, and only teammates' Servonaut can open them. Servonaut never stores your keys in a form we can read. In short:

1. an owner or admin sets up their vault and creates the team vault: Vault → Setup, then Create vault, in the Servonaut app, or servonaut vault setup and servonaut vault create --team <team>;
2. they import keys (select the vault, then Import SSH; or servonaut vault import ssh) and link each one to its servers (Instances → select the server → Use Vault Key; or servonaut vault bind <server> <item>);
3. each teammate signs in and sets up their vault once (Account / Login → Login with servonaut.dev, then Vault → Setup; or servonaut login and servonaut vault setup), and an owner's or admin's Servonaut grants access automatically.

The Vault tab shows who has access, lets owners and admins approve members and resolve exposures, and says whether an owner's or admin's Servonaut is online to grant access. Read Servonaut Vault for devices, recovery keys and what happens when someone leaves.

SSH access through Bitwarden (external vault)

The team's SSH keys stay in your Bitwarden organisation. Servonaut only stores where each key is: the team's Bitwarden server (cloud US, cloud EU or self-hosted), a default collection, and the key item for each shared server. Set them up with Servers & Access → Share SSH access → Advanced: use an external vault — you can paste an item's link from the Bitwarden web vault instead of its ID. Bitwarden membership is not synced with the team: when someone leaves, remove them from the collection yourself. If a server has both a vault key and a Bitwarden item, Servonaut uses the vault key.

Each teammate who connects with the team's keys then:

1. gets access to the team's collection from your Bitwarden organisation admin (Servonaut can't grant this);
2. installs the Bitwarden CLI, runs bw login and unlocks it;
3. signs in (Account / Login → Login with servonaut.dev in the Servonaut app, or servonaut login) and checks access: select the server under Instances in the Servonaut app and choose Verify SSH, or run servonaut servers verify. The server's SSH check turns green on the team page once it succeeds.

Team secrets

On plans that include secrets management, owners and admins connect a Bitwarden Secrets Manager project on the team's Secrets tab. Members see which project the team uses and how to connect: each person sets their own access token in their shell (BWS_ACCESS_TOKEN unless the team chose another variable name) and restarts Servonaut. See Secrets & Integrations.

Shared server memory

Server memory is what Servonaut has learned about a server (its setup, services and findings). The person who synced a server shares it with the team from the Memory tab; owners and admins can update or stop any share. It stays end-to-end encrypted: each teammate decrypts it with their own memory key, which they set up once in the Servonaut app (Memory Sync → Unlock Memory Sync; there is no CLI command for this, and headless machines use the SERVONAUT_MEMORY_PASSPHRASE environment variable). People who join later, or set up their key later, get access when someone with sharing rights clicks Update access. Members can read shared memory in the Servonaut app, in AI chat context, and on the team's Memory tab. See Server Memory.

MCP tool policy

On the Policies tab, owners and admins decide which Servonaut MCP tools teammates' AI clients may call through the team:

• All tools except the ones you block, or only the tools you allow — pick tools from a searchable list grouped by what they act on, with a Read-only / Standard / Destructive label on each. You can also edit the lists as text.
• Max connections — how many AI clients may be connected to the hosted MCP server at once, up to what your plan allows.
• Destructive AI tools — a team-wide default and per-member exceptions, set by the owner. Each destructive action still asks for confirmation.
• Approval rules set through the API are shown there read-only.
• The AI balance page, linked from Policies and Billing, shows the team's one pooled balance and lets owners and admins set a monthly spending limit per member.

The same policy is available to scripts through GET/PUT /api/v1/teams/{slug}/mcp-policy (allowed_tools, blocked_tools, require_approval, max_connections). Members can read it; owners and admins can change it, and every change is recorded in the activity log.

Billing & seats

The Billing tab is for the team owner, whose subscription pays for the team.

• Change the number of seats with the seat control on the Billing tab. Adding seats is charged straight away for the rest of the billing period; for removed seats, the unused time comes off your next invoice.
• You can't go below the seats in use — remove a member or cancel a pending invitation first.
• Payment methods, invoices, monthly or yearly billing and cancelling are in Stripe's billing portal, opened from the Billing tab.
• Cancelling takes effect at the end of the billing period, followed by a short grace period. After that, members keep read access to the team's servers and settings, but changes are paused until the owner subscribes again. Personal data and personal credentials are not affected.

Activity log

Team changes are recorded: team creation, renames and deletion, ownership transfers, seat changes, invitations, joins, role changes, removals and people leaving, shared servers, SSH and secrets settings, the MCP tool policy and destructive-AI settings, member AI spending limits, and memory sharing. Each entry keeps who made the change, when, the before and after values where there are any, and the IP address.

Owners and admins read it on the team's Activity tab as plain sentences, grouped by day, with filters for who, what and when, and can export the matching entries as a CSV file. Scripts can read the same log through GET /api/v1/teams/{slug}/audit.

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 balance 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 balance 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 tool policy. The tools a teammate's agent may call through the team follow the team's policy and the person's role (see MCP tool policy).
• 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. Having the Servonaut app open on a machine (it connects automatically) or running servonaut connect there 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.
• Destructive tools additionally need the destructive-AI permission (the team default or the person's exception, set by the owner) — without it they are hidden from chat and refused server-side.

Data isolation across teams

Every team's server inventory, SSH config, secrets config, AI balance, and activity log is 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.