Permissions and Authentication

Overview

Nebuly uses two distinct authentication mechanisms depending on the type of access. End-user authentication is handled through your enterprise identity provider (Google, Microsoft, Okta or built-in basic autnetication). Users log into the Nebuly UI via SSO or basic authentication. Ingestion authentication uses API keys. Any service sending data (interactions, traces) to Nebuly must include a project API key in every request:

Authorization: Bearer <api-key>

API keys are scoped to a project and can be created under Settings → Project → API keys.

Default admin user on first startup

On first startup, you should create an initial admin user through the Helm values under auth.

auth:
  adminUserEnabled: true
  # -- The username of the initial admin user.
  adminUserUsername: "admin@nebuly.ai"
  # -- The password of the initial admin user.
  adminUserPassword: "securePassword"

Use a strong password that follows your organization’s security standards (minimum length, mixed character types, and no reused credentials). The initial admin user is intended for bootstrap access: use it to create additional users and assign roles, then disable it if your security policy requires removing the default admin account after setup.

Roles and permissions

Nebuly has four built-in roles. Role assignment is managed directly in Settings → Members. Admins can create users with specific roles and update both roles and project/organization access at any time.

Role	Description
`admin`	Full platform access. Manages members and all projects.
`projectadmin`	Full access within a subset of projects. Can manage project members, API keys, and settings.
`member`	Can view and interact with data within assigned projects. Cannot manage members or settings.
`viewer`	Read-only access within assigned projects. Cannot modify any data or settings.

Configuring SSO for self-hosted deployments

SSO is configured at the infrastructure level via the Nebuly Terraform module. Pass your identity provider credentials as a module input and Terraform will automatically inject them into the generated Helm values. Supported providers: google, microsoft, okta.

module "platform" {
  source = "nebuly-ai/nebuly-platform/azurerm" # or /aws, /google

  google_sso = {
    client_id     = "<your-client-id>"
    client_secret = "<your-client-secret>"
  }
}

After terraform apply, re-run terraform output helm_values to pick up the updated values before upgrading the Helm chart. Terraform module references: AWS · Azure · GCP

​Overview

​Default admin user on first startup

​Roles and permissions

​Configuring SSO for self-hosted deployments

Overview

Default admin user on first startup

Roles and permissions

Configuring SSO for self-hosted deployments