Skip to main content
Access in LocalOps works in three layers:
  1. Organization roles - Owner, Admin or Member - decide what someone can do across your whole LocalOps account.
  2. Project roles - Member, Maintainer or Read-only - decide what someone can do inside a project.
  3. Protected environments can give someone a different role on one environment, overriding their project role there.

​
Organization roles

Pick an organization role when you invite someone to your LocalOps account.

​
Owner

  • Has unrestricted access to all features and settings, including billing.
  • Has full access to every project, unless restricted in a specific project.

​
Admin

  • Can do everything the Owner can, except manage billing.
  • Has full access to every project, unless restricted in a specific project.
  • Ideal for team leads who need full operational control without billing oversight.

​
Member

  • Sees only the projects they’ve been added to.
  • What they can do in each project depends on their project role.
  • Can’t access projects they aren’t part of.
Organization-level pages follow the organization role only - project roles and restrictions don’t change them. Organization Members can see cloud connections, registries, license tokens, connected GitHub and GitLab accounts, the audit log and who’s in the organization, but only Owners and Admins can change them. Helm charts and integrations such as Slack are for Owners and Admins only, to view as well as to manage, because Helm charts carry configuration values. Billing is for the Owner.

​
Project roles

Every organization Member in a project has one of three project roles.

​
Permissions in detail

✅ allowed · ✕ shown, but greyed out · Hidden not shown at all

​
Project

​
Project members

​
Environments

Generating a Helm chart is for Owners and Admins only, since a chart carries the environment’s configuration values.

​
Services

When an action is greyed out, LocalOps shows “Your role in this project doesn’t allow this.” The ops CLI follows the same roles: ops logs needs Maintainer, while ops connect, ops proxy and ops update-kubeconfig need Member. See who can run which command.

​
Managing project members

Project Members manage who else is in the project, from the project’s Settings → Members: they add existing organization members, set or change their project role, and remove them. Anyone can leave a project on their own. See Project members for the steps. Inviting someone who isn’t in your organization yet, and cancelling pending invites, is done by Owners and Admins. See Invite team members.

​
Owners and Admins in a project

Owners and Admins have full access to every project. To scale that back in a particular project - say, to keep an Admin from accidentally changing production config - an Owner, Admin or project Member can restrict them to Member, Maintainer or Read-only in that project. They then act with that role there. Owners and Admins can’t be removed from a project, only restricted. A restricted Owner or Admin still keeps a few organization-level abilities in that project: Restrictions can only be tightened afterwards. To restrict someone who is already restricted, pick a lower role. To give them more access, lift the restriction instead. See Owner and Admin restrictions for the full rules, including restrictions on a single protected environment.
A restricted Owner or Admin can lift their own restriction at any time. Restricting is a guard against mistakes, not a security boundary - to truly limit someone’s access, give them the organization Member role instead.

​
Protected environments

Some environments need tighter control than the rest of the project. Mark an environment as protected - production is the usual one - and you can give people an environment role on it: Member, Maintainer or Read-only. On a protected environment, a person’s environment role replaces their project role, whether it’s higher or lower. People without an environment role can’t see a protected environment at all - it’s hidden from them - unless they’re an unrestricted Owner or Admin.

​
Example

In the project Payments, production is protected and staging isn’t: Priya builds freely in staging but can only look at production. Dev normally deploys only, but owns production while on call. Sam has no environment role on production, so production is hidden from them; on staging their project role applies.

​
Protect an environment

Anyone who can change an environment’s settings - unrestricted Owners and Admins, project Members, and Owners or Admins restricted to Member - can protect it. If they don’t have full access, they’re added to it with their current role, so they keep access. Once it’s protected, managing its members needs the Member role in that environment, or full access.
  1. Open the environment and click Protect at the top of the page, then confirm.
  2. Go to the environment’s Members tab, which appears once it’s protected.
  3. Add the people who need access to this environment, and pick an environment role for each.
Unrestricted Owners and Admins keep full access to protected environments too, unless they’ve been restricted in that environment.
Unprotecting an environment deletes every environment role in it, Owner and Admin restrictions included. Everyone goes back to their project role.
See Protected environments for adding people, changing their roles and who can do what.