Organizations and Members
- An organization is the top of the model. Projects, configs, snapshots, bindings, registry tokens, and the plan that entitles them all belong to one organization.
- Every account gets a personal organization at first sign-in. It has no alias, and it cannot be addressed as a registry host.
- A team organization carries a globally unique alias, which becomes a registry host:
<alias>.compliance.tf. Creating a team organization and assigning its alias is operator-run today — there is no self-service endpoint for it. - There are three roles:
owner,admin, andmember. The owner is fixed when the organization is created; an invitation can only ever grantadminormember. - People join by invitation to an email address. The invited person must sign in with that exact, verified address to accept, and the role comes from the stored invitation rather than from anything they send.
- Inviting a team requires an active trial or a paid plan.
What an organization owns
An organization is the tenancy boundary. Everything the platform holds hangs off exactly one of them: the projects that group workloads, the configs that author a compliance posture, the snapshots those configs publish, the bindings that point an environment at a snapshot, and the registry tokens that let Terraform or OpenTofu fetch modules.
It is also the unit of entitlement. A plan is held by the organization, not by each person in it. When your access to the registry comes from an organization, every member draws on that one organization's allowance — headcount does not multiply it.
You can belong to more than one organization at a time, with a different role in each.
Personal and team organizations
| Personal organization | Team organization | |
|---|---|---|
| Created | Automatically, at first sign-in | By compliance.tf, on request |
| How many | Exactly one per account | As many as you have been given |
| Name | Derived from your profile | Chosen at creation |
| Alias | None | Required, globally unique |
| Registry hosts | The canonical and framework hosts | Those, plus <alias>.compliance.tf |
| Owner | You | Named at creation |
The personal organization is created the first time you sign in, and creating it is idempotent — signing in repeatedly does not produce a second one. It exists so that a single user has somewhere to author configs and hold tokens without any team setup at all.
A team organization is what you want for shared work: several people, one plan, one alias, one audit trail.
Be aware of how team organizations come into being today. There is no endpoint that creates one, and no screen that does it either. The only path is an administrative command run by compliance.tf, which names the organization, assigns its alias, and installs the first owner in a single step. Ask for one during onboarding. Alongside that, three things the product does not do: it cannot convert a personal organization into a team organization, it cannot delete an organization, and it cannot change an alias once assigned.
The alias, and the URL it creates
An alias is a DNS label, and assigning one to an organization brings up a registry host for it. That host is not a cosmetic vanity domain — it changes how a module source is read.
On a framework subdomain, the three path segments after the host mean what they mean on any Terraform registry — namespace, module name, provider:
source = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"On an organization's alias host, the same three segments are read as project, environment, module:
source = "bobthecorp.compliance.tf/payments/prod/s3-bucket"The environment segment is what tells the two apart. It must be dev, staging, or prod — the three environments every project has. A source on an alias host therefore names a specific project environment, and what it resolves to is whatever snapshot that environment is currently bound to. That is the point of the alias: your Terraform code stops naming a compliance framework and starts naming your own project and environment, and the binding decides the posture.
Membership is enforced on every request to an alias host. A caller with no active membership in the addressed organization is refused outright rather than quietly served at their own personal tier, and removing someone takes effect within seconds rather than at the end of their session.
The three roles
| Role | What it is for |
|---|---|
member | Read access to the organization and its active-member roster. No management permissions at all. |
admin | Everything a member can do, plus managing the roster, projects, configs, and the organization's registry tokens. |
owner | Everything an admin can do, plus billing, the organization-level approval settings, and — by default — approving snapshots and promoting them. |
Approving a snapshot and promoting it to an environment are separate capabilities rather than part of the admin role. An admin can be granted them individually. A member never receives them, whatever flags are set on their membership.
One thing to be deliberate about before you hand out admin: for member management, admin and owner are the same grant. An admin can change roles and remove people — including the owner — as long as at least one other admin or owner remains. There is no ownership transfer action, and the owner role cannot be granted to anyone after the organization is created. Treat admin as a full-trust grant, and keep more than one person holding it.
Joining an organization
The lifecycle, in order:
- An admin invites an email address and picks the role,
adminormember. This requires the organization to be on an active trial or a paid plan; a free organization cannot invite. - compliance.tf records a pending invitation and emails a link. The invitation is good for a fixed window, and the email states it.
- The invited person opens the link. They can see who invited them and what role they are being offered without having an account yet — the link itself is what authorizes that preview.
- They accept. This requires signing in with the exact address the invitation was sent to, and that address must be verified. An invitation sent to one address cannot be accepted by an account using another.
- The role comes from the stored invitation. Nothing in the accepting request can influence it.
Declining works straight from the email and needs no account, which matters for the case that motivates it: an invitation sent to the wrong person.
Three operational facts worth knowing while an invitation is outstanding:
- Re-inviting the same address replaces the link. The previous link stops working immediately.
- A repeat invitation inside a brief cooldown is a no-op. Nothing is re-sent and the existing link stays valid, so a double-click does not invalidate the link already in someone's inbox.
- An admin can revoke a pending invitation at any time, and revoking one that is already gone is harmless.
Pending invitations are visible on the roster to admins and owners only. An ordinary member sees active members.
Working in more than one organization
Accepting an invitation does not replace your personal organization. You belong to both, and you switch which one you are acting in. The switch is scoped to your session, and it re-checks your membership at the moment you make it — so a session cannot be pointed at an organization you do not belong to, whatever it was pointed at before.
Your role is per organization. Being an owner of your personal organization says nothing about your standing in a team you were invited into.
Managing membership
The rest of this page is the operator's half: the exact permission each role carries, who may act on the organization and its roster, every state an invitation can end in and the status it returns, how the last-admin guard behaves under concurrency, why invitation responses are deliberately uninformative, and the rules an alias must satisfy.
Related
- Projects and environments — what sits inside an organization, and the three environments an alias host addresses
- Access control — the permission model in full, including tenant isolation
- Registry tokens — personal and organization-owned tokens, and wiring them into Terraform
- Plans and entitlements — tiers, trials, and what gates on plan