Skip to content
DreadnodeDreadnodeDreadnode

Users and organizations

Manage organizations, user accounts, platform roles, and signup protection for a self-hosted deployment.

User and organization administration is an in-product setting. It lives under Admin, applies at runtime, and never requires a chart change or a redeploy — on Helm or on Embedded Cluster alike.

Manage organizations

Section titled “Manage organizations”

Use Admin → Organizations to view, create, or delete organizations across the deployment. When creating an organization, set its owner and maximum member count.

If the owner email has no account, Dreadnode creates the organization and active owner membership, then emails a one-time account setup link. The owner sets a password through that link and signs in to the organization you created. Account setup preserves the existing organization, workspace, roles, and credits instead of creating a second organization during onboarding.

Use Settings → General for changes that belong to one organization, such as its display name.

To add or remove an organization’s owners, open the organization and use Owners in the Membership section. Adding an existing member promotes them to owner. If no user has the email you enter, you’re asked to confirm it before a new account is created for that address. An organization always keeps at least one owner. Owner changes take effect immediately. When you remove an owner, the person loses access to the organization, and workspaces they solely own in it are deleted. Their account is kept; to remove the account itself, delete the user from Admin → Users.

Manage users

Section titled “Manage users”

Enterprise deployments accept internal email domains such as company.local, including special-use domain suffixes, for signup, account setup, password recovery, and membership invitations. Addresses must still have valid email syntax and a domain containing a period. Your configured mail server must be able to deliver verification, setup, and recovery messages to those addresses. SaaS deployments retain public-domain email validation.

Use Admin → Users to search across the deployment and inspect a user’s account state, organization memberships, and platform role.

From a user detail page, you can:

  • verify an email address
  • grant or revoke platform-admin access
  • delete the account

You cannot change your own platform role or modify a platform owner’s role. Only a platform owner can revoke platform-admin access from another administrator.

Protect signups

Section titled “Protect signups”

Use Admin → Security to:

  • turn Allow new signups off to stop all self-service account creation
  • limit signups from one IP address within a 24-hour period
  • block signup traffic from specific IPv4 or IPv6 CIDR ranges
  • allow signup traffic only from specific IPv4 or IPv6 CIDR ranges
  • allow or block individual disposable email domains

The signup IP policy defaults to Deny configured networks. Select Allow only configured networks to require every self-service email or OAuth signup to match an allow rule. Deny rules remain active in both modes and take precedence when an address matches both lists. Requests that pass the network policy still count toward the rolling 24-hour signup limit.

Enterprise deployments allow 1,000 signups per IP address in each rolling 24-hour window by default. This higher limit supports teams that share one public address through a corporate NAT. SaaS deployments default to 3 signups per IP address. Change the limit under Admin → Security; the saved value persists across restarts and redeployments.

Allow new signups is on by default. When you turn it off, nobody can create an account with email or OAuth sign-in, and the sign-in page shows no sign-up option. Existing users keep signing in, and platform admins can still create accounts. The change applies to the next request, with no restart. An invitation to an email address that has no account cannot be accepted while signups are off.

Section titled “Related”