Teams and access overview
Share access through individual accounts instead of sharing your password. LabsPanel combines ownership, organization roles, project membership, and server subuser permissions.
Audience and availability
Section titled “Audience and availability”This guide is for server owners, team managers, and collaborators using cloud.8labs.id. Team controls depend on your permissions and the hosted configuration. If a control is unavailable, contact your organization owner or 8Labs support.
Before making changes, identify the server owner, the intended collaborators, and the minimum actions each person needs.
How effective access works
Section titled “How effective access works”A user’s effective permissions are the union of all applicable access sources. One limited grant does not reduce another broader grant.
| Access source | Scope and effect |
|---|---|
| Server owner | Full control of the owned server. |
| Platform root admin | Operator-level control across servers; not a customer organization role. |
| Server subuser | Selected permissions on one server. |
| Organization owner or admin | Full access to servers associated with that organization. |
| Organization member | Access through the projects they join, not every organization server. |
| Project membership | Selected permissions on every server inside that project. |
Owners, platform root admins, and applicable organization owners/admins have implicit wildcard (*) access. Other collaborators receive the permissions granted through their applicable sources.
Organization admin is not platform root admin. An organization role does not grant access to the platform’s admin area.
For example, removing control.power from a project grant does not prevent power actions if the user still has that permission as a server subuser. Removing one membership is not proof that all access has ended.
Choose an access method
Section titled “Choose an access method”- Use an organization to manage a team and its workspace.
- Use a project to grant selected actions across a folder of servers.
- Use a server subuser to share one server independently of an organization.
- Add existing accounts directly. Use an invitation for a person without an account.
- Use personal API keys for scripts, not another person’s browser credentials.
Project membership also adds the person to the linked organization as a member when needed. It does not make them an organization admin.
Confirm the result
Section titled “Confirm the result”Wait for the save or acceptance confirmation before closing the dialog. An invitation does not grant access until accepted.
Ask the collaborator to select the correct workspace and open the intended server. Confirm that the intended controls are available. Do not grant extra permissions merely to bypass an unexplained error.
Troubleshoot access safely
Section titled “Troubleshoot access safely”- A server is missing: check the active workspace, project membership, and whether the server is still in that project.
- A control is unavailable: compare the required permission with all current grants. Some management actions remain owner-only.
- Access remains after removal: review server ownership, organization role, project memberships, and direct subuser grants.
- A new person cannot join: check whether they already have an account. Registration and invitation availability depend on the deployment.
For suspected unauthorized access, remove the relevant grants and review account security. Contact support if platform-level access or an unexplained grant needs investigation. Provide resource identifiers and timestamps, not passwords or tokens.