Skip to main content

Teams and custom domains

raba is multi-tenant from the ground up, not bolted on. Every project belongs to a team, every team has its own members and roles, and a team can bring its own domain with fully automated TLS — no manual certbot step, and raba never needs your DNS provider's credentials.

Teams and roles​

Every account gets a personal team automatically on signup. Teams have three roles — owner, admin, member — mirroring the instance-wide role shape:

  • member — can view the team's projects and create new ones.
  • admin — can also delete/regenerate-secret existing projects, manage team membership, and set the team's custom domain.
  • owner — full control; a team can't be left without at least one owner.
raba team list

Project creation resolves which team automatically: pass --team <name-or-id> explicitly, or let it default to your oldest team membership if you only belong to one. You can also resolve a team by domain ownership instead — raba http 3000 --domain tunnel.acme.com picks whichever of your teams owns that domain (this lookup is scoped to your own teams, never a global "who owns this domain" search, so it can't be used to probe other teams' configuration).

Instance-wide administration​

There's no separate "instance admin" role sitting outside the team system — instance-wide authority (managing every team's projects, instance settings, user accounts) is derived from team membership instead of being a second, parallel permission system. One specific team is flagged as the instance team, and owner/admin-tier membership of that team is what grants instance-wide access. The very first account to sign up on a fresh instance has their personal team automatically flagged this way — enforced at the database level so only one team can ever hold that flag at a time.

Practically, this means granting someone instance-wide admin access is just adding them to the instance team at admin tier or above — the same invite/membership flow you'd use for any other team, reused rather than duplicated. There's currently no way to move the instance-team flag to a different team after the fact (no "transfer" API exists yet) — it stays with whichever team was flagged on that first signup.

Custom domains with automated TLS​

raba team domain-set tunnel.acme.com

This prints two DNS records to add:

  1. A CNAME pointing your domain (or a subdomain of it) at this raba instance.
  2. A second CNAME, for the ACME DNS-01 challenge — pointed at a record raba's own DNS zone controls, not yours. This is the key design decision: your team never has to hand over your DNS provider's API credentials. raba only ever needs to write TXT records into its own zone, and your one-time CNAME delegates challenge validation there permanently.

Once both records are in place:

raba team domain-verify

confirms the routing CNAME actually resolves here, marks the domain verified, and TLS issuance kicks in automatically on the next renewal pass (a periodic background task, not something you have to trigger). Renewal happens the same way, indefinitely, with no further manual steps.

What "team-scoped" actually means​

Project visibility and mutation follow team membership, not who happens to have created a project — any member of a team can see and act on every project that team owns (subject to the role tiers above), not just ones they personally created. Deleting or changing a team's domain also transactionally revokes any of that team's projects still snapshotted under the old domain string, so an old, no-longer-owned domain can never keep quietly routing traffic to a project you've moved on from.