Organizations

An organization (org) is a group of Carolina Cloud users who share a single pool of compute credits and, optionally, a shared storage bucket. Orgs are the right fit for labs, classrooms, small teams, and anyone who wants one person funding compute on behalf of others.

The concept

Every Carolina Cloud user has their own personal trial credit balance and, if they’ve added one, their own Stripe payment method. That covers the single-person case fine.

When a user is added to an org, they gain a second credit pool alongside their personal one: the org balance, shared with every other member of the same org. Anyone in the org can spend from it. Org admins can see the full member roster, drill into running instances, top up credits, and invite new members.

An org also optionally has its own storage bucket (distinct from the member’s personal bucket), which admins can provision for team-wide datasets.

Getting started

Anyone can create an org from the dashboard — see Creating an Organization. Once you have one, the typical next steps are:

• Invite teammates by email.
• Top up the org’s prepaid credit balance at a volume discount.
• Manage admins, members, and runaway instances from the My Organization page.

The My Organization page (sidebar → Usage & Billing → My Organization) is the home base for everything org-related.

How org-attributed usage is paid

For every billable event (VM compute, storage), Carolina Cloud walks this chain in order:

1. Org prepaid credits — drained first whenever the user belongs to an org.
2. Org payment method — if the org has a card on file (see Organization Payment Method), it’s charged once org credits are exhausted.
3. Personal trial credits — the member’s own free-trial balance kicks in once both org-side sources are empty.
4. Personal Stripe card — final fallback if the member has a card on file.

Org-side funds (credits + card) are always exhausted before any member-side funds are touched. That means a member’s free trial credits are preserved while the organization is paying, and a member without a personal card on file can keep running indefinitely as long as the org has either credits or a card.

Org-owned storage (the optional shared org bucket) follows a shorter cascade because there’s no specific member to fall back to: org credits → org card → unbillable. When both org sources are exhausted, the bucket isn’t deleted — it’s logged as unbillable in the audit stream and admins decide how to resolve it (top up credits, attach a card, or delete the bucket).

Roles

Member

A member can see the name of their org and the current org credit balance. Members can’t see other members, buy credits on behalf of the org, or change any org settings. Their instances draw from the org balance automatically — there’s no opt-in step.

Admin

An admin sees everything a member sees, plus:

• The full member roster
• Each member’s personal credit balance, instance count, running instances, and combined hourly cost (including any deletion overage on their warm bucket)
• The org-shared bucket — current size and hourly cost — when one is provisioned
• Combined org-wide hourly cost: every member’s compute + storage plus the org bucket’s storage cost. This is the exact number being billed against the org’s funding sources at this moment

Admins can invite or remove members, promote or demote other admins, and remote-stop runaway instances, and top up the org’s credit balance. An org can have any number of admins.

Owner

The user who created the org is the owner. Owners have all the powers of an admin and are the primary billing contact. Unlike a regular admin, the owner cannot be demoted or removed from the org. Each org has exactly one owner.

What happens if every funding source is exhausted

The full chain — org credits, then org card, then personal credits, then the member’s personal Stripe card — has to be exhausted before billing fails. Once all four are gone, the member can no longer create new instances, and existing instances are stopped automatically to prevent further usage. Members without a personal card on file are never surprise-charged: they simply stop running at the moment the last funding source drains.

Org vs. personal storage

Members still have their own personal Wasabi bucket (mounted as ~/ccloud-s3/ on instances). If the org has a bucket provisioned, the Bucket Browser shows a My Bucket / {Org} Bucket tab switcher so members can move between the two. Org buckets are not auto-mounted on instances — they’re explicit to use.

Who can migrate into the org bucket

The S3 Migration tool copies a bucket from AWS, Wasabi, B2, R2, etc. into one of your Carolina Cloud buckets. The destination dropdown is gated by role:

• Owner and admins — can migrate into either their personal bucket or the org bucket.
• Regular members — can migrate into their personal bucket only. If a non-admin member picks the org bucket from the dropdown, the dispatch is rejected with a 403.

This matches how the rest of org-side actions work: provisioning, deleting, and now bulk-importing into the shared bucket are all admin-gated. Regular members are still free to use the org bucket (read/write through normal S3 paths from their instances) once an admin has loaded it.

See Carolina Cloud Storage for the shared mechanics, and Cold Storage for the archival tier.