Each organization is an independent namespace, which means "Data Repositories" and "Computing Containers" have independent access permissions under the organization. At the same time, "Storage" and "Computing Resources" under the organization are also independent.

Organization Resource Permissions

Permission Description

Click on any computing container under the organization and switch to the "Settings" page to see the resource visibility settings.

Resource visibility under an organization is divided into three types:

Similar to "Computing Containers," "Data Repositories" also have the permissions shown above.

Default Permissions

The permissions when creating resources (computing containers, data repositories, etc.) within an organization are derived from the default resource permissions in "Organization Settings." Organization administrators can modify the default resource permissions in "Organization Settings."

Use Cases

Teaching Scenario

A teacher creates an organization and becomes the organization owner, inviting students to join the organization.

Set the default resource permission to "Personal Visible" to ensure each student can only see their own computing containers and not those of other students.

The teacher creates a "Data Repository" and sets the permission to "Organization Read-only" to ensure students can use the data repository while preventing data loss due to accidental operations by others.

The teacher creates a "Computing Container" and sets the permission to "Organization Read-only" as teaching materials. Students can clone it into their own computing containers using the "Clone" function.

Project Collaboration

Two members within an organization work on the same project and want to access each other's execution content.

Member A creates a "Data Repository" and sets the permission to "Organization Read-write" to ensure not only they can edit data content, but also allow Member B to add new data versions.

Member B creates a "Computing Container" and sets the permission to "Organization Read-write," so both Member A and Member B can create executions in the same computing container and access each other's running execution content. Additionally, JupyterLab itself supports real-time collaboration, allowing Member A and Member B to see each other's operations when they both open JupyterLab simultaneously.

Organization "Resource Usage"

When creating resources (computing containers, data repositories, etc.) under an organization, storage resource and computing usage will be recorded in the organization's "Resource Usage."

Similar to "Resource Usage" under personal accounts:

• "Overview" displays the organization's total storage resources, used resource quantity, and remaining available resources;
• "Usage" records the type, date, product type used (computing resource type, storage space), duration of use, and storage space consumption for each task under the organization;
• "Resource Change Details" records the change status of each resource (for example: subscribing to storage space);
• "Quota Limits" records the quota limits for each resource, which are shared among organization members;

Organization Member Limitations

In addition to the organization's own limitations, administrators can set individual limitations for members to further restrict the maximum resources a specific user can consume within the organization.

Scope of Impact

Currently, member limitations are primarily used to restrict the concurrent usage upper limit of various compute resources (such as rtx-5090, rtx-pro-6000, etc.) by a member within the organization.

This restriction strictly applies to resources created and run by the member within the organization, and does not affect the resources under the member's personal account.

Relationship with Organization Limitations

Member limitations do not replace organization limitations; instead, both take effect simultaneously.

This means that when an organization member attempts to start a resource, the following conditions must be met concurrently:

• The member's individual limitation.
• The organization's overall limitation.
• The organization's currently remaining available resources and allowances.

A member limitation can only tighten the restrictions; it cannot loosen or exceed the organization's total cap.

For example:

• The organization's concurrent limit for rtx-5090 is 4.
• Member A's individual limitation for rtx-5090 is 1.

In this case, Member A can run a maximum of only 1 instance of that resource at any given time, even if the organization as a whole has remaining idle quota.

Common Use Cases

Member limitations are typically applied in the following scenarios:

• Educational Environments: Instructors want to ensure that each student can only use a maximum of 1 GPU resource simultaneously.
• Team Collaboration: Administrators want to prevent a few heavy users from monopolizing the organization's shared resources.
• Shared Budget Management: When multiple users share an organization's budget, administrators can allocate finer-grained resource caps per member to control costs.

Organization "Finance Center"

Each organization has an independent financial account that is not shared with the organization creator's account. This means the balance under a personal account cannot be used for the organization account.