Organizations & Teams

An organization is noBGP's sharing and billing boundary. Networks, nodes, and services belong to an organization; every member of the organization can work with them, and the organization receives one bill.

Personal organizations

Every account gets a personal organization automatically at signup — you are its Owner, and everything you create lands there by default. If you only ever use noBGP solo, you never need to think about organizations at all.

A personal organization carries no name of its own until you give it one. What you see beside it is derived: your profile name, or — if you have not set one — the email address you sign in with. Set your profile name and the label follows it immediately, with nothing to rename; a social login that supplies a name fills an empty profile name in for you the next time you sign in that way.

Naming the organization itself is the other way to fix the label, and it is the one that sticks: rename it and that explicit name wins over the derivation from then on, whatever your profile name later says.

Team organizations

Create a separate, shared organization when you want a team to operate the same infrastructure:

Create an organization called "Acme Corp"

Your AI assistant uses the org_create tool; you become the new organization's Owner. You can also manage organizations in the web app under Account.

New networks go to your personal org unless you target the team org (org_id on network_create, or select the organization in the app). Nodes are billed to the organization that owns the network they registered in.

Which network a call lands in

Once you belong to more than one organization, "my network" stops being obvious — and the tools resolve it so that a shared organization's network is something you name rather than something you land in:

• Omitting the network name means your sole network, judged inside your personal organization. One personal network wins even when the team orgs you belong to hold a dozen more. Only an ambiguous personal side — two personal networks, or none at all alongside several shared ones — gets you the invalid_args asking which network you meant.
• A name that exists in two of your organizations resolves to the personal one first. Network names are unique per creator rather than globally, so you and a teammate can each have a home.
• An id means exactly that network. Passing a network id reaches the network it identifies, in whichever organization that is — no name lookup happens, so it can't be rebound to a personal network sharing the name.

Nothing changes for a solo account, or for anyone whose networks all live in one organization: a single network is still picked automatically. The MCP Reference lists which parameters this covers.

Roles

Organization membership is tiered. Roles gate which operations a member may perform:

Role	Capabilities
Owner	Everything — including billing, SSO, transferring ownership, and deleting the organization
Admin	Manage members and invites, create/delete networks, label nodes and delegate node roles, plus all Member capabilities. An Admin cannot manage Owners or grant the Owner role
Member	View infrastructure, register and manage nodes, run commands and move files on them, and publish/manage services — all as the node's configured account, and all authenticated

The full matrix, cell by cell, is on Roles & Permissions — including the two capabilities that are gated at the field level rather than the tool level, which is where this summary is easiest to read wrong:

• Running as the superuser is an Owner/Admin capability. A Member operates a node fully — commands, files, services — as the account that node's owner configured. What a Member cannot do is ask for the node's root identity: the admin flag on command, command_subscribe, the file tools and terminal services is refused below Admin, and refused rather than quietly downgraded. The reasoning matches node_grant: running something on a machine is operational, handing yourself root on it is administrative. The node's own allow-admin setting still applies on top — see Execution identity.
• Turning a service's authentication off is an Owner/Admin capability. A Member publishes, updates, deletes and shares services freely. Setting auth_required: false — on service_update or at publish time — is refused below Admin, because it changes who can reach the service from anyone in your organization to anyone with the URL. Turning authentication back on is never gated, and editing a service that is already unauthenticated is not gated either.

Labelling a node is an Owner/Admin capability too, and for a less obvious reason: node_grant writes its targets as label pairs, evaluated live, so relabelling a machine changes which peers a granted node may reach. Roles & Permissions has the detail.

You can check which side of that line you are on without spending a call on it: whoami reports can_elevate, plus your role in each organization you belong to. If you hold different roles in different organizations it reports the per-organization detail instead of a single verdict, since elevation is decided by the organization that owns the node you are aiming at — join it against org_id on the network from network_directory.

One consequence worth knowing before someone reports it as a bug: a node with no working user configured refuses unelevated work too, rather than running it as root (unelevated never means root). A Member on such a node has no path left — they cannot elevate, and the unelevated call is refused — so the fix is on the machine, nobgp config --user <account>, not a role change.

An organization always retains at least one Owner. Ownership is handed off explicitly: the current Owner transfers it to another member and becomes an Admin.

Inviting members

Invite teammates by email from Account → Members in the web app. Each invite:

• Emails a one-time link that expires after 7 days
• Grants a role you choose on acceptance (member by default)
• Can be resent — resending rotates the link, so the previously issued one stops working

Admins may invite Members or Admins; only an Owner can bring in another Owner.

Renaming an organization

Organizations are renamed by an Owner or Admin — inline on the Members page in the app, or through the org_update tool.

A personal organization can be renamed too, from router 0.4.78, and you are always its Owner so nothing gates you. The name you set replaces the derived label permanently: editing your profile name afterwards no longer moves it. Earlier routers refused the call and the label could only be changed by editing your profile.

Audit log

Every tool invocation against the organization's infrastructure is recorded in a per-organization audit log, visible to Owners and Admins in the app under Account → Audit (filterable and paginated).

Each event captures who called which tool, the target it acted on, when, and the outcome. Tool arguments are not recorded — they can contain secrets.

Single Sign-On (SSO)

Organizations can require members to sign in through the company identity provider. Both OIDC and SAML providers are supported.

Setup is Owner-only:

1. Connect an identity provider — the Owner opens an ephemeral admin-portal link and completes the connection (see org_sso_setup in the MCP Reference).
2. Optionally turn on enforcement — members must then log in via SSO; password and social logins are rejected. Enforcement can only be enabled after a provider is connected, so an organization can't lock itself out.

Members signing in through the organization's IdP for the first time are provisioned automatically.

Billing

Plans, allowances, and usage are all per organization — see Plans & Billing.