HostingGuru
Members & roles.
Every resource on HostingGuru — services, deployments, domains, databases, billing — lives inside a workspace. Workspaces are how teams collaborate. This doc explains how to invite people, what each role can do, and how ownership transfers work when someone leaves the team.
A workspace is the unit of isolation
One workspace per project (or team)
Workspaces are cheap — create one per company, per product, or per client. Resources don't cross workspaces. A user can belong to many workspaces with different roles in each: owner of their personal sandbox, admin in the company workspace, developer in a client's workspace.
Always exactly one owner
The user who creates a workspace becomes its owner. There is always exactly one owner — the role can be transferred but not duplicated, and never demoted while still being the only owner. Owners are the only people who can manage billing or delete the workspace.
Plan limits are per-workspace
Service count, member count, hosting tier, Postgres and Redis subscriptions — all tracked at the workspace level. Hobby gives a workspace 3 services and 3 members; Pro gives 10 services and 5 members. Need more? Upgrade the workspace plan, or create a second workspace on its own plan.
Member caps by plan
Each plan includes a fixed number of seats: Starter 1, Hobby 3, Pro 5, Custom unlimited. Need more seats than your plan allows? Upgrade — there's no add-a-seat-for-$X option, the seat count is part of the plan.
Four roles, designed around real workflows
Owner
The person responsible for the account. Can do everything: deploy, configure, invite, remove members, change billing, delete the workspace. There can only be one owner at a time. The role transfers but never disappears.
Admin
Trusted operators. Can do everything an owner can except manage billing, transfer ownership, or delete the workspace. Right role for senior team members, ops engineers, and cofounders who shouldn't have access to your card on file.
Developer
The default role for engineers. Can deploy and configure services, manage environment variables, view logs and metrics. Cannot delete services, manage domains, change roles, or invite members. Right role for most contributors.
Viewer
Read-only. Can see deployments, logs, metrics, and configuration — but cannot deploy, edit, or trigger anything. Right role for stakeholders, support staff, auditors, or non-technical founders who just want to see "is the site up."
Who can do what
| Action | Owner | Admin | Developer | Viewer |
|---|---|---|---|---|
| View services, logs, metrics | ✓ | ✓ | ✓ | ✓ |
| Create / deploy a service | ✓ | ✓ | ✓ | — |
| Manage environment variables | ✓ | ✓ | ✓ | — |
| Trigger an on-demand script run | ✓ | ✓ | ✓ | — |
| Delete a service | ✓ | ✓ | — | — |
| Manage custom domains | ✓ | ✓ | — | — |
| Invite / remove members | ✓ | ✓ | — | — |
| Change member roles | ✓ | ✓ | — | — |
| Manage Postgres & Redis subscriptions | ✓ | — | — | — |
| Manage billing & plan | ✓ | — | — | — |
| Transfer ownership | ✓ | — | — | — |
| Delete the workspace | ✓ | — | — | — |
Common operations
Invite a member
Settings → Members → Invite. Enter their email, pick a role (default: developer), send. They receive an invite email valid for 7 days. If they don't already have a HostingGuru account, the invite link walks them through signup, then drops them straight into the workspace.
Change someone's role
Settings → Members, click the role dropdown next to their name, pick a new role. Changes take effect immediately. Promoting someone to owner uses the transfer ownership flow instead — the existing owner becomes admin in the same step.
Remove a member
Click the trash icon next to their name. They lose access immediately and any active dashboard session is invalidated. Their previous deployments and configurations stay — only their access is revoked.
Transfer ownership
Settings → Members → … → Transfer ownership. Pick an existing member as the new owner, confirm with your password. The new owner gets billing access; the previous owner becomes an admin and can still operate everything except billing. Useful when a founder hands off finance to a CFO, or when a freelancer hands a project to the client.
Leave a workspace
From Settings → Members, click Leave workspace. Owners cannot leave directly — transfer ownership first, then leave. We confirm with a modal so you don't accidentally orphan yourself out of your own production account.
Delete a workspace
Settings → Danger zone → Delete workspace. Owner-only. Type the workspace slug to confirm. All services are stopped immediately. Add-ons (database, redis) are scheduled for deletion at the end of the current billing period — you have 30 days to back up data or restore the workspace if it was a mistake.
API tokens for CI & automation
Workspace API tokens
Tokens belong to the workspace, not the user. Generated from Settings → API tokens. Each token has a label, a role (matches the four roles above), and an optional expiry. Use them in CI pipelines, deploy scripts, or webhook receivers to trigger on-demand scripts and read deployment status.
How requests are scoped
Send the token as Authorization: Bearer <token> and the workspace ID as X-Workspace-Id: <uuid>. The middleware validates the token, checks it belongs to the workspace, and applies the role's permissions exactly the same way it would for a logged-in user.
Token rotation
Tokens can be rotated from the dashboard — generate a new one, deploy it to your CI, then revoke the old one. The full token value is shown only once on creation; we store a hash and a 4-character prefix for display.
Common questions
Do I pay per member?
No, but each plan includes a fixed seat count: Starter 1, Hobby 3, Pro 5, Custom unlimited. There's no per-seat add-on — to grow the team you upgrade the plan.
Can a member belong to multiple workspaces?
Yes — and have a different role in each. A user can be the owner of their personal sandbox, an admin in their team's workspace, and a developer in a client's workspace, all with the same login.
Can a developer see the value of secret env vars?
Developers can view non-secret variables and update both. Variables marked as secret show only the last 4 characters in the dashboard. Logs strip values that match a secret variable. Owners and admins see everything.
What happens to deployments triggered by a removed member?
Nothing — they keep running. Removal revokes access, not deployments. Their commits are still in your repo and the deployments are still live until someone else changes them.
Can I require SSO?
SAML SSO is on the roadmap for Custom plans. For now, GitHub OAuth is the supported sign-in method, which gives you de-facto SSO if your team already requires SSO on their GitHub org.
Ship together.
Four roles, simple permissions, no per-seat surprises. Invite your team in seconds.
Key takeaways
A workspace member on HostingGuru is a user with explicit access to a workspace's deployments, env vars, and billing — assigned one of four roles: owner, admin, developer, or viewer.
- Starter: 1 member. Hobby: 3 members. Pro: 10 members. Custom: unlimited.
- Invitations are emailed and valid for 7 days.
- Only the owner can change the billing payment method or transfer ownership.
- Developers can deploy and read/write env vars; viewers can only read logs and metrics.