Organizations are the primary unit of ownership and access control in DepAegis. They group packages, manage members, and enforce security policies across your team.
What Are Organizations?
An organization(often shortened to “org”) is a shared workspace within DepAegis that owns one or more packages. Every package belongs to exactly one organization. Organizations provide:
Namespace isolation — packages live under @org/ (npm) or org- prefix (NuGet).
Access control — fine-grained roles determine who can publish, install, and manage packages.
Audit trail — every publish, permission change, and setting update is recorded.
Billing & quotas — storage, bandwidth, and token limits are tracked per organization.
When you sign up, DepAegis creates a personal namespace for you automatically. You can publish packages there without creating an organization. Organizations become essential once you collaborate with others.
Creating an Organization
Open the DepAegis dashboard and click New Organization in the sidebar.
Enter an organization slug (e.g. my-company). This becomes part of your package namespace.
Choose a display name and optional avatar.
Select a billing plan (free tier available for small teams).
Click Create Organization.
The org slug cannot be renamed after creation because it forms part of every package name published under it. Choose carefully.
Organization Settings
Organization owners and admins can manage settings from the dashboard:
Name & Avatar
Update the display name and avatar at any time from Settings → General. The org slug is immutable.
Billing
View storage usage, bandwidth consumption, and token usage under Settings → Billing. Upgrade or downgrade your plan as needed.
Security Policies
Organization-level policies apply to all packages within the org. Configure vulnerability scan thresholds, license allow-lists, and the dependency firewall from Settings → Security.
Teams let you group members and assign permissions at scale. Instead of granting access to individual users for each package, you assign packages to teams.
Creating a Team
Navigate to Organization → Teams.
Click New Team.
Enter a team name (e.g. backend, frontend, platform).
Assign an initial set of members.
Managing Team Members
To add or remove members from a team:
Go to Organization → Teams → [Team Name].
Click Add Member and enter the user's email or username.
Choose a role for the member within the team (see below).
Remove a member by clicking the × button next to their name. Removing someone from a team revokes their team-level permissions on all packages assigned to that team.
Removing a user from a team does not remove them from the organization. They may still have direct package-level permissions.
Roles
DepAegis uses a role-based access control (RBAC) model with five built-in roles:
Role
Manage Org Settings
Manage Teams
Publish Packages
Install Packages
View Audit Log
Owner
Yes
Yes
Yes
Yes
Yes
Admin
Yes
Yes
Yes
Yes
Yes
Maintainer
No
No
Yes
Yes
Yes
Developer
No
No
No
Yes
No
Viewer
No
No
No
No
No
Owner — Full control. Can delete the organization, transfer ownership, and manage billing. Every org must have at least one owner.
Admin — Can manage teams, invite/remove members, and configure org settings. Cannot delete the organization or change ownership.
Maintainer — Can publish and deprecate packages. Cannot manage org settings or teams.
Developer — Can install (pull) packages but cannot publish. Ideal for most engineers who only consume packages.
Viewer — Read-only access to the dashboard (package metadata, versions, scan results). Cannot install or publish.
Assign the minimum viable role to each member. Most engineers only need Developer access. Reserve Maintainer and above for CI pipelines and release managers.
Package Permissions
Access to packages is determined by a combination of org-level roles and package-level overrides.
Who Can Publish
Users with the Owner, Admin, or Maintainer role can publish packages to the organization.
CI/CD tokens inherit the permissions of the user who created them. Use a service account with the Maintainer role for automated publishing.
Who Can Install
Users with Developer role or above can install packages.
Organizations can optionally make specific packages public, allowing unauthenticated installs.
Package-Level Overrides
For finer control, you can restrict a specific package to a subset of teams. Navigate to Package → Settings → Access to change which teams can view or publish a given package.
Namespace Management
DepAegis maps organization slugs directly to package namespaces across all supported ecosystems.
# Scoped package — maps to the "my-org" organization
{
"name": "@my-org/ui-components",
"version": "1.0.0"
}
# Install
npm install @my-org/ui-components
# Prefix convention — maps to the "my-org" organization
# Package ID follows the pattern: MyOrg.PackageName
dotnet nuget push MyOrg.UiComponents.1.0.0.nupkg \
--source https://nuget.app.depaegis.com/api/v1/nuget/v3/index.json
# Install
dotnet add package MyOrg.UiComponents
The namespace is derived from the org slug automatically. You do not need to configure it separately.
Transferring Packages Between Organizations
To move a package from one org to another:
Navigate to Package → Settings → Transfer.
Select the destination organization.
Confirm the transfer.
Namespace changes break existing installs. After transferring @old-org/pkg to @new-org/pkg, all consumers must update their package.json or .csproj references. DepAegis does not redirect old names to new ones.
Audit Log
Every organization maintains an immutable audit log of significant events. Owners and admins can view it from Organization → Audit Log.