items.organization.title

The Organization page (/organization/:code) is where you manage everything that applies to your organization as a whole, rather than to a single cluster or application: who has access, how you pay, and the credentials your deployments use.

Overview#

The page is organized into tabs:

• Subscription - your current plan, wallet balance, payments, invoices, and billing history.
• Users - the people who belong to the organization and the role each one holds.
• Container Registry - the custom image registry used for deployments across all your connected git providers.
• Backup Storage - the S3-compatible destination cluster backups are written to.
• API Keys - Stack API and Nebua Agent authentication tokens.

Roles & Capabilities#

Every organization member holds exactly one role: Owner, Admin, User, Billing, or Read Only. Roles are assigned from the Users tab and control what a member can see and do across the organization, its clusters, and its deployments.

Capability	Owner	Admin	User	Billing	Read Only
Manage organization settings	✅	✅	–	–	–
Delete organization	✅	–	–	–	–
Manage members & assign roles	✅	✅	–	–	–
Configure container registry	✅	✅	–	–	–
Manage API keys	✅	–	–	–	–
Manage billing & subscription	✅	–	–	✅	–
View clusters	✅	✅	✅	✅	✅
Manage clusters	✅	✅	✅	–	–
View multi-cluster nodes	✅	✅	✅	–	✅
Manage / approve multi-cluster nodes	✅	✅	✅	–	–
View multi-cluster audit log	✅	✅	✅	✅	✅
Manage GitOps enforcement	✅	✅	✅	–	–
Trigger backup & restore	✅	✅	✅	–	–
View application stacks	✅	✅	✅	✅	✅
Deploy application stacks	✅	✅	✅	–	–
View monitoring	✅	✅	✅	✅	✅
View logs	✅	✅	✅	✅	✅

A few things worth calling out:

• Owner is the only role that can delete the organization or manage API keys - keep at least one trusted Owner on every organization.
• Admin covers day-to-day organization administration (settings, members, registry) plus full operational access to clusters and deployments, without the two Owner-only actions above.
• User is the default role for day-to-day operational work - it grants the same cluster and deployment access as Admin, just without any organization-administration capability.
• Billing and Read Only are intentionally narrow: Billing can manage the subscription and wallet but only view everything else; Read Only can't manage anything - it's meant for auditors or stakeholders who need visibility without operational access.

Subscription#

The Subscription tab is where you manage the organization's plan and payment activity:

• Plan - shows your active plan, or lets you choose one if the organization has none yet. Changing plans schedules the change for the next billing cycle - your current plan stays active until then.
• Wallet Activity - your prepaid wallet balance, recent transactions, and top-up orders, alongside your configured payment provider.
• Payments - the organization's payment orders, with the ability to pay any order still pending.
• Invoices - issued invoices for the organization.
• Billing Timeline - a chronological history of subscription changes (upgrades, downgrades, cancellations).

A billing health indicator at the top of the tab flags whether the organization has an active paid subscription in good standing, is in a warning state (e.g. a payment issue), or is blocked.

Container Registry#

By default, deployments push images to the provider's own registry: GHCR for GitHub, ACR for Azure DevOps, GitLab's Container Registry for GitLab. Bitbucket has no native registry, so a custom one is required for Bitbucket-backed deployments.

The Container Registry tab lets an organization override this and route every deployment, regardless of git provider, through one custom registry instead - Docker Hub, AWS ECR, Google GCR, Azure ACR, GitHub GHCR, or any other OCI-compliant registry. Once a registry provider is chosen, you provide the registry host (auto-filled for known providers), a username/service account, and an access token or password. Leaving the token field blank on a later save keeps the existing stored token.

See the full Container Registry Configuration guide for provider-by-provider setup steps (Docker Hub, GHCR, Azure ACR, GitLab).

Backup Storage#

By default, cluster backups are written to NebuaCloud's own managed storage. The Backup Storage tab lets an organization bring its own S3-compatible bucket instead - every backup for every cluster in the organization is written there once configured. If no bucket is configured, backups silently keep using the platform default, so this is entirely opt-in.

Supported providers: Amazon S3, MinIO, Cloudflare R2, Wasabi, Backblaze B2, DigitalOcean Spaces, Ceph Object Gateway, or Custom / S3-compatible for anything else that speaks the S3 API.

Fields:

• Name - a label for the configuration, shown wherever it's referenced.
• Provider - choosing one auto-fills a sensible default Endpoint, Region, and path-style setting below; all three can still be edited afterwards.
• Endpoint - the S3 API URL, e.g. https://s3.amazonaws.com for AWS, or your provider's regional endpoint.
• Region - defaults to us-east-1 (auto for Cloudflare R2).
• Bucket - the bucket name. It must already exist - it isn't created for you.
• Prefix - an optional key prefix so multiple environments or organizations can share one bucket without colliding.
• Path-style access - toggles between virtual-hosted-style (bucket.endpoint) and path-style (endpoint/bucket) addressing. Amazon S3 uses virtual-hosted-style; most non-AWS providers - MinIO, Ceph Object Gateway, Contabo, and S3-compatible services in general - require path-style. Selecting one of those providers switches this on automatically, but double-check it if the connection test fails with a DNS-style error (ENOTFOUND ...).
• Use SSL - use https:// against the endpoint. Leave this on; most S3-compatible providers reject or redirect plain HTTP requests, which surfaces as a failed connection test rather than a clear error.
• Verify TLS certificate - disable only for an endpoint using a self-signed or internal certificate.
• Storage Class - optional. Leave it blank unless your provider explicitly documents support for AWS storage-class values (STANDARD, STANDARD_IA, etc.) - leaving it blank lets the provider apply its own default. Sending an AWS storage class to a provider that doesn't recognize it (Contabo, for example) fails the save with an InvalidArgument error.
• Server-Side Encryption - None, AES256, or aws:kms. Choosing aws:kms requires a KMS Key ID.
• Access Key ID / Secret Access Key - credentials for the bucket. The secret key is encrypted at rest and never shown again after saving - leave it blank on a later edit to keep the existing stored value.

Saving runs a connection test against the bucket automatically; the tab shows Connected or Disconnected, the time of the last test, and the provider's own error message when it fails.

API Keys#

The API Keys tab issues authentication tokens for two different audiences:

• Stack API - a single, organization-wide key used to call the NebuaCloud Stack API. Generating a new Stack API key immediately replaces the previous one for that audience, so anything still using the old value (a running integration, a CI job) needs to be updated.
• Nebua Agent - one token per node. Every control-plane or worker host that runs the Nebua Agent needs its own token, generated for the cluster currently selected in the sidebar's cluster context panel. Generating a new agent token adds it as a new node token rather than replacing an existing one - use the revoke action next to a specific token to retire it.

When a Nebua Agent token is generated, the dashboard also shows the --agent-id it's bound to. That agent ID and token are a matched pair - the install command must use exactly that pair, since the agent rejects a token whose embedded agent ID doesn't match the --agent-id it was started with. Reusing a token/agent-id pair across two different hosts will make NebuaCloud treat both hosts as the same agent reconnecting, and nodes will go missing from the dashboard unpredictably.

Both key types can be given an expiration (1 month up to 1 year, or no expiration) at generation time. Tokens are masked in the UI after creation - use the copy action to retrieve the full value, since it isn't shown again in full once you navigate away.