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.

  • Sync from your IdP — Google Workspace, Okta, Azure AD, SCIM
  • 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

Sync IdP groups → teams

Connect Okta / Azure AD / Google Workspace once. Your existing groups become mesh teams. Add a person to the IdP group → they're on the mesh team within minutes.

IdP: 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.

Sync from the IdP you already pay for

SCIM + group mapping for every major IdP. Your existing "ops-team" group becomes the "ops" team in meshr — and stays in sync as people join and leave.

Google WorkspaceOktaAzure AD / EntraSCIM v2OIDC group claimsManual / hybrid

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
IdP sync 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. Sync your IdP groups and target them from policy in minutes.

Get early access See pricing →