Code ownership & membership

Roles are enforced. A role is an access boundary, not a label: actions are checked against the role on every request, and an unrecognised role is denied rather than defaulted. A viewer cannot change configuration or deploy. See the security page for what that covers.

Role

Intended for

admin

Manages the organisation, members, and billing. The first admin created at registration is treated as the org owner for billing and notification emails.

developer

Builds and deploys applications across the organisation, including adding, editing or removing the organisation's own validation prompts.

viewer

Read-oriented access to the org's applications, deployment history and billing, for stakeholders who want visibility. Does not include service control, logs, the database audit trail, or authoring validation prompts — those need the developer role. Pushing to a syntica-hosted repository needs the developer role as well. A viewer's git credential can clone but not push.

1

Click Invite member and enter an email and the role they'll receive. An invite link is emailed to them.

2

They open the link, set their name, and a membership is created with the invited role.

3

Pending invites can be resent, copied, or cancelled from the members screen until they're accepted or expire.

Change a role via the inline dropdown.

Remove a member, which frees their seat and retains history. It doesn't delete their account. You can't change or remove your own membership. Removing a member does not revoke any git credential they minted, and today there is no organisation-admin control that does — a departed member's credential can still clone the organisation's repositories until they revoke it themselves. It can no longer push, because every push checks the member's current role. Weigh that when deciding who to invite, and contact us if you need a credential revoked and the person who minted it isn't able to do it.