Workspaces & roles

A workspace owns everything: its own private network, its instances, and its API tokens. Signing up creates a personal one for you; create more from the workspace switcher when you want to separate a team or a client from your own work.

Members and invitations

Members lists everyone in the workspace. Invite by email and the invitation is sent with a role attached; the recipient accepts it from the link and lands in the workspace. Pending invitations can be revoked from the same page, and you can change or remove a member's role there too.

Membership is per-workspace, so being an owner of one grants nothing in another.

Roles

Developer is the role for people who build: full lifecycle over instances, web apps and Kubernetes clusters, including deleting them — but no changes to what the whole workspace shares (networks, domains, load balancers, certificates, membership) and no deleting a web app outright. Viewer reads the workspace's metadata — what runs, where it answers, how it is doing — and writes nothing. It never reaches the data inside an instance or the secrets that open it: no SQL (a SELECT included), no passwords or secret environment values, no exports, backups or file downloads.

Inside a Kubernetes cluster, what someone can do follows their role on that cluster, not their workspace role: see Kubernetes cluster access. A cluster's own admins can also give and revoke access to it.

These aren't only UI affordances for instances and tokens: the control plane re-resolves your role on every request and rejects the ones your role doesn't carry, so a hidden button can't be worked around by calling the API directly.

Require two-step verification

Owners and admins can require every member to use two-step verification — an authenticator app or a passkey: Settings → Security → Require two-step verification for every member.

• You need it on your own account first, so turning this on can't lock you out. The page shows how many members don't have it yet.
• A member without it can't use the workspace until they set it up. The console shows them a page that links to setting it up, and their other workspaces stay open. Their API tokens and connected apps are refused too, with 403 TWO_FACTOR_REQUIRED.
• Turning it on or off emails every owner and adds an entry to the workspace's Notifications.
• Invitations to the workspace say it's required. The person invited can accept first and set it up after.

If every owner has lost their authenticator app and backup codes, write to support from an owner's address. Once support has confirmed it's you, they can lift the requirement; every change support makes is recorded and emailed to the owners. A support session opened on a member's account is held to the same rule as the member.

Plan and quota

The plan sits on your account, not on each workspace, and sets the quota that instances are carved out of — vCPU, memory, and disk in one pool. A workspace takes its quota from its owner's plan, and every workspace gets its own: an owner on a paid plan has the full quota in each workspace they own, and what one workspace uses never counts against another. An invited developer's own plan doesn't change what the team can launch. Within a workspace, Kubernetes volumes draw on the same pool as its instances, and so does the space its backups take. Kubernetes workers of a paid size draw on it too until usage billing is on for the workspace; from then on they are billed by the hour instead.

Quota is checked inside the write itself, so two launches racing each other can't both squeeze past it. A workspace can also start at most 30 new billable resources — instances, restores, apps, clusters, load balancers — in any ten minutes; past that, the API answers 429 and says when to retry.

Usage shows the full picture: what's allocated against the workspace's quota, what the running instances are actually consuming, and which tier its owner is on. When you need more, request an increase from the same page — it goes to a review queue, and the page shows the request as pending until it's decided. One pending request at a time.

The workspace overview and Usage also show this month at list prices: the owner's plan plus what the workspace has used so far this calendar month (UTC), such as load balancer and Kubernetes hours. It's an estimate at the published prices, not an invoice. When the workspace or its owner isn't billed, the card says Not billed — complimentary; the usage is still counted and shown, so you always know what the month would cost.

Deleting a workspace

Only an owner can delete a workspace, and only once it holds nothing: every instance, virtual machine, game server, app, Kubernetes cluster, load balancer, volume, reserved public IP address and backup has to be deleted first, and deletions still in progress have to finish. Until then the delete is refused with a list of what is left, so nothing keeps running — or billing — after the workspace that owned it is gone. Deleting the workspace then removes its members, tokens and settings.

Notifications

Notifications is the workspace's feed of what the platform did: instances that finished provisioning, ones that failed and on which step, deployments that shipped. It's the place to look when something you started earlier should have landed by now.

Next steps

• API tokens — scope a token to a subset of what your role can do
• Instances — what your team can launch
• Web apps — deploying apps from GitHub