Teams

One ACL for the whole team.

A team is a named group of users. Use it as a policy source — "ops can reach prod-db", not "savas can reach prod-db, ali can reach prod-db, leyla can reach prod-db..." One rule, one team, everyone covered.

  • Map teams from OIDC group claims — bring your own IdP
  • Use teams as policy source — one rule covers the whole team
  • Scoped visibility — hide resources teams can't reach
Get early access Pair with Policies →
Teams
3 of 8
ops4

via Okta · group:ops-team

sre3

via Okta · group:sre

devs12

via Okta · group:eng

ops

4 members · synced 2 min ago

Members

ASLK

Can reach

prod-app:443 :22
prod-db:22 :5432
monitoringall
IdP synced
Scoped view
Teams vs Organizations

Easy to confuse. Different jobs.

Teams

User groups used inside an organization to write ACLs. Multiple teams per org. "ops", "sre", "devs", "external-contractors".

  • Source / target of ACL rules
  • Synced from your IdP groups
  • Many per organization

Organizations

The tenant boundary. Separate billing, separate mesh, separate admin. An MSP has one org per customer; most teams have one.

  • Billing + plan unit
  • Owner / Admin / Member roles
  • One org = one isolated mesh
Read about Organizations →
In the workflow

Teams in the workflow.

Sync once, write rules against the team, then audit reach in seconds.

1

Map OIDC groups → teams

Connect your OIDC provider once and map its group claims to mesh teams. Add a person to the upstream group → they land on the mesh team on next sign-in. (SCIM and dedicated Okta / Azure AD connectors are on the roadmap.)

OIDC claim: ops-team → meshr team: ops
2

Write the policy against the team

One rule: "allow team:ops → group:prod-db". No per-user copy-paste, no rule explosion when a new engineer joins.

allow team:ops → group:prod-db :22, :5432
3

Audit what a team can reach

Click any team → see every destination group they can access, on which ports, via which rule. Security review answered in 30 seconds.

team:devs → 4 groups · 12 services · 0 prod
Capabilities

A team primitive that pays off.

Sync from the IdP you already run, target it from policy, scope what each team sees, and keep an auditable history.

Map groups from your OIDC provider

Bring your own OIDC provider and map its group claims to mesh teams. Your existing "ops-team" group becomes the "ops" team in meshr — refreshed on each sign-in. SCIM v2 and dedicated Okta / Azure AD connectors for continuous directory sync are on the roadmap.

OIDC group claimsGoogle Workspace (OIDC)Microsoft (OIDC)Manual / hybrid SCIM v2SoonOkta connectorSoonAzure AD / Entra connectorSoon

Teams as policy source

The Policies engine treats team:ops exactly like a device group. Write the rule once — every team member inherits it. New hire? Add to the IdP group, done.

# Before — per-user ACL hell
allow user:savas, user:ali, user:leyla → prod-db

# After — single team rule
allow team:ops → prod-db

Scoped visibility, not just access

A dev opens the device picker — they see exactly the peers their team can reach, not the whole production fleet. Same for SSH targets, tunneling targets, DNS lookups.

Device picker filtered by team reach
DNS resolution scoped to reachable peers
Search results respect team boundaries
Read-only "viewer" role for security audit

Membership history, auditable

Every team add and remove is recorded. Want to know who was in team:ops on March 17th when the incident happened? Click the team → time-travel slider → see the membership snapshot of that day. Pairs with Audit Logs.

Time-travel membership snapshots
Diff team membership between two dates
Membership deltas (joined / left / role changed)
Cross-link every change to the audit event

Write the rule once. Cover the whole team.

Free for every feature while we're in beta. Map your OIDC groups to teams and target them from policy in minutes.

Get early access See pricing →