One tenant, four roles
An organization is the top-level tenant — every server, app, service, and secret belongs to exactly one org. Roles are granted at the org level only; a Project inside an org is pure grouping, not a second permissions boundary.
Roles
Rank runs OWNER > ADMIN > MEMBER > VIEWER. A few load-bearing rules apply everywhere: nobody can grant or assign a role above their own, and only an OWNER can grant OWNER, demote an OWNER, or remove one — an org always keeps at least one OWNER.
| Role | Can do |
|---|---|
| OWNER | Everything ADMIN can, plus grant or demote another OWNER, remove an OWNER, and the billing hand-offs (subscribe / manage billing). |
| ADMIN | Enroll, delete, or transfer a server; provision a new backing service; invite, resend, revoke, and change members' roles (never above their own rank, never touching an OWNER); mint or revoke scoped API keys; manage notification channels and routing; connect a Slack workspace; approve AI-proposed destructive changes. |
| MEMBER | The default working role: create and deploy apps, roll back, edit secrets (including revealing an existing value in the dashboard editor), bind an existing service to an app, trigger a manual backup, edit firewall rules, connect a GitHub repo. |
| VIEWER | Read-only: servers, apps, deployments, secret names (never values), and the Alerts view (firing + history). Can't create, change, or trigger anything. |
See Secrets & env for exactly what MEMBER vs. VIEWER means for a secret value, and Observability & alerts for the ADMIN-gated notification settings.
Invitations
An ADMIN or OWNER invites by email and a role; the invitee redeems it themselves:
Invite
A single-use token is minted and shown once in the dashboard. If SMTP is configured, the invite is also emailed with a direct accept link; if not, you copy the token yourself. Either way expires in 7 days.
Accept
The invitee signs in and opens the link. Acceptance requires an exact email match against the invited address — a forwarded or leaked token isn't redeemable by the wrong identity.
Resend
Still pending? Resend reissues a fresh token and expiry and invalidates the old link — no need to revoke and re-invite.
Revoke
An ADMIN can cancel a pending invitation outright at any time.
Seats are checked when the invite is created, against your plan's seat cap — not again at accept.
Pin your default org
Belong to more than one org? Click the star next to any org in the org switcher to pin it as the one that opens first the next time you sign in.
Scoped API keys
An ADMIN or OWNER can mint a key (sk_…) bound to one org and one role — capped at the minter's own rank, same as an invite. Optionally scope a key to a single server or project instead of the whole org, and opt it in to auto-applying non-destructive writes (destructive ones always stay approval-gated regardless). Keys are revocable, track a last-used timestamp, and the plaintext token is shown exactly once at creation.
Every CLI and MCP call rides this same key against the same audited API a human uses — there's no privileged AI-only path.
Plans & usage
Caps are per-organization and enforced where the resource is actually created:
| Plan | Price | Servers | Apps | Services | Seats | Releases kept |
|---|---|---|---|---|---|---|
| Free | €0 | 1 | 3 | 2 | 2 | 1 |
| Pro | €19/mo | 3 | ∞ | 10 | 5 | 5 |
| Team | €29/mo | ∞ | ∞ | ∞ | ∞ | 10 |
| Enterprise | Contact us | ∞ | ∞ | ∞ | ∞ | 10 |
At cap, creating resource #N+1 is refused with an upgrade link — nothing existing is ever touched. Downgrade the same way: over-cap resources keep running (grandfathered); you just can't add more until you're back under the cap. The usage bars on the “Plan & usage” settings screen turn warning-colored at 80% of a cap so you see it coming. Full numbers and FAQ live on Pricing.
Billing, handled by Stripe
Sproobo never sees your card. The “Subscribe” and “Manage billing” actions are OWNER-only and open a Stripe-hosted page (Stripe acts as Merchant of Record, so VAT/GST/sales tax is calculated, collected, and remitted for you). Your plan updates automatically from Stripe's webhook the moment a subscription changes.
Sproobo staff have a separate operator console for cross-org health, user, and audit views — gated behind a platform-staff flag and invisible (a 404, not a login wall) to everyone else. It doesn't change what staff can see of your data: no app secrets, no server access, no telemetry. Staff can grant a complimentary plan override for an org, and doing so always writes to that org's own audit log — it's never an invisible change.
Next
- See who can reveal a secret value versus just its name on Secrets & env.
- Notification channels and alert routing are ADMIN-gated — see Observability & alerts.
- Read the full trust-boundary and encryption model on Security model.