Permissions

OEC.sh uses a two-level access control system. Organization roles determine what a member can do at the organization level (manage servers, invite people, access billing). Team-based project roles determine what they can do within specific projects (deploy, create environments, restore backups).

The Two Levels

Organization Level

Every member has exactly one organization role: Owner, Admin, Developer, or Viewer. This role governs access to organization-wide features like server management, storage configuration, billing, and member invitations.

Project Level

Project access is granted through Teams. You create a team, add members to it, and assign the team to one or more projects with a role: Admin, Developer, or Viewer. A member who is not on any team with access to a project simply cannot see that project.

These two levels are independent. An organization-level Viewer who belongs to a team with Admin access to a project will have read-only access to the organization settings but full Admin access within that project.

Organization Roles

Owner

There is one Owner per organization -- the person who created it. The Owner has unrestricted access to everything, including billing and the ability to close the organization. The Owner also has automatic Admin access to every project, regardless of team membership. This is a safety net so the Owner can never be locked out.

Admin

Admins manage the organization's infrastructure and people. They can add servers, configure DNS and storage providers, invite and remove members, and create teams. They can do almost everything the Owner can, except access billing and close the organization.

Developer

Developers can create projects and work within the projects their teams have access to. They cannot manage servers, invite members, or change organization settings. This is the right role for engineers who need to build and deploy but should not be changing infrastructure.

Viewer

Viewers have read-only access to whatever their role and teams allow them to see. They cannot create, modify, or delete anything. Use this for clients, stakeholders, or anyone who needs to check on progress without touching anything.

Project Roles via Teams

When you assign a team to a project, you pick one of three roles:

See Teams for how to create teams and assign them to projects.

How Access Resolution Works

A member can belong to multiple teams, and those teams might have different roles on the same project. When that happens, the member gets the highest role from any of their teams.

Admin > Developer > Viewer

Example:

• Sarah is on "Backend Team" which has Developer access to Project Alpha
• Sarah is also on "Lead Engineers" which has Admin access to Project Alpha
• Sarah's effective role on Project Alpha is Admin

This means you do not need to worry about conflicting assignments. Add someone to multiple teams freely -- they always get the most permissive access from their combined memberships.

Owner Override

The organization Owner always has Admin access to every project, even if they are not on any team assigned to that project. This is intentional. The Owner is the last line of defense -- if a team structure is misconfigured, or everyone with Admin access to a project leaves, the Owner can still get in and fix things.

You cannot remove this access. It is built into the platform.

Permission Caching

To keep things fast, OEC.sh caches permission lookups for up to 5 minutes. This means that after you change someone's role or team membership, it can take up to 5 minutes for the change to take full effect.

In practice, most changes are reflected within seconds because the cache is invalidated on common operations. But if a member reports that they still see the old permissions after a change, tell them to wait a few minutes or log out and back in.

Granular Permissions (Pro and Agency Plans)

On the Free and Starter plans, the four organization roles and three project roles cover all access control. On the Pro and Agency plans, you get access to the full permission matrix with 55+ individual permissions.

What Granular Permissions Add

• Fine-grained control over specific actions (e.g., allow a role to create backups but not restore them)
• Permission audit: see exactly which permissions each role has
• Audit logs (Pro: 30-day retention, Agency: 1-year retention) that record who did what and when

Custom Roles (Agency Only)

Agency plan organizations can create custom roles beyond the four built-in ones. This is useful when the standard roles do not fit your team structure -- for example, a "Backup Manager" role that can manage backups across all projects but cannot deploy.

Where to View Permissions

Permissions Tab

Go to Settings > Permissions tab to see the full permission matrix for your organization. This shows every role and every permission, so you can verify exactly what each role allows.

Members Tab -- Role Permissions

In the Members tab, expand the Role Permissions section to see a comparison table. Permissions are shown with checkmarks (allowed) and X marks (denied) for each role side by side.

Common Patterns

Agency with multiple clients

Create one team per client project. Add the client's developers to their team with Developer access. Add your own senior engineers to a "Lead Team" with Admin access across all client projects. The Owner oversees everything.

Small team, shared responsibility

If everyone on your team needs the same access to all projects, make one team, add everyone, and assign it to all projects with the appropriate role. No need for complex team structures.

External auditor or investor

Invite them with the Viewer organization role. Add them to a team with Viewer access to the specific projects they need to see. They get read-only access with no ability to change anything.

Troubleshooting

Member can see the organization but not a specific project

They need team membership. Organization roles do not grant project access (except for the Owner). Assign their team to the project.

Member has the wrong permissions on a project

Check which teams they belong to and what role each team has on the project. Remember, the highest role wins. If "Team A" gives them Viewer access but "Team B" gives them Admin access, they have Admin.

Permission change is not taking effect

Permission caching can delay changes by up to 5 minutes. The member should refresh their browser. Logging out and back in clears the cache immediately.

Need finer control than the four built-in roles allow

Upgrade to Pro for the full 55+ permission matrix and audit logs. Upgrade to Agency if you also need custom roles.