Three roles, and what each one may do
Access is per Project, not per company. Every member of a Project holds exactly one of three roles, and they rank: owner outranks editor, editor outranks viewer.
- Viewer: sees the Project, its Components, deployments, logs, routing and activity. Changes nothing.
- Editor: everything a viewer sees, plus the daily work. Deploy, roll back, start and stop a Component, set environment variables, create and link databases and buckets, manage routing and domains.
- Owner: everything an editor does, plus the decisions that cannot be undone. Only an owner invites and removes members, changes someone's role, deletes the Project, and requests the migration bundle.
Note
Deleting a Project and exporting it both ask for your two-factor code on top of the owner role, exactly as the console does. An owner without 2FA on their account is let through, because there is nothing to verify against; turning 2FA on is what closes that gap.
Inviting people
An owner creates an invite link for a Project and shares it. The link carries the role the invitee will get, and you decide up front how long it lives and how many people may use it.
- An invite link grants editor or viewer. It cannot grant ownership, so a leaked link can never hand away the Project.
- Set an expiry, a maximum number of uses, or both. Both are optional; a link with neither stays open until you revoke it.
- Revoke a link at any time. Revoking stops future use and leaves the people who already joined in place; remove them separately if that is what you meant.
There is no separate seat to buy and no minimum team size. Adding a member does not change what the Project costs.
Who pays
One wallet pays for a Project: the wallet of the account that owns it. Every Component bills per minute against that wallet, no matter which member triggered the deploy. Members do not need their own balance to work on the Project.
- Pricing is usage, not seats. The team size never appears in the bill.
- The owner sets the spend cap for the Project, and the alerts on it reach the owner.
- Usage and wallet balance are read on the owning account, not per member, so the owner is the one who can see what the Project is costing.
The practical consequence: put the Project under the account that should carry the invoice before the team grows around it. Moving the bill later means moving ownership.
Support
Support runs on tickets from inside your account, so a reply lands with the person who filed it and the history stays attached to the account rather than to one inbox. Tickets can also be opened, answered and closed by an AI assistant over MCP if you grant it the support scopes.
Read the service levels we actually commit to on the SLA page, and the current state of the platform on the status page. Both are public and neither is a sales document.
What does not exist yet
Said plainly, so you can judge the fit instead of finding out during a migration:
- There is no organisation or workspace above the Project. Collaboration is per Project, so a team with ten Projects manages membership ten times.
- There is no shared or pooled billing across accounts. One wallet per Project owner, as above.
- There is no SSO, SCIM or directory sync. People sign in with their own Sarpius account.
- There are no custom roles. The three above are the whole model.
- Audit history is the Project activity log, not a separate exportable audit trail.
Heads up
If one of these is a hard requirement for you, say so before you start migrating. We would rather tell you it is not there than have you discover it at the wrong moment.