Workspace settings & teams
Workspace settings (workspace switcher → Workspace settings, or the Runner settings links around the app) manage the active workspace. Most tabs are admin-only; other members see read-only or explanatory views.
General
- Workspace name — admins can rename the workspace.
- Plan — the workspace's plan. Every workspace is on the free plan while OpenV is in alpha, with every feature included; the hosted-runner limits in force are listed on the pricing page.
- Details — workspace ID, slug, and creation date.
Members
The people in the workspace. Admins add members by email and manage each member's workspace role (member or admin; new members default to member). Note the distinction:
- Workspace membership gets someone into the workspace.
- Project access is granted per project (Project Settings → Access) — directly or via teams.
Who gets told
Membership changes are not silent, because nobody should discover their access changed by noticing a button has gone.
- The person affected is notified when they are added to a workspace or project, when their role changes, and when they are removed. Someone who leaves of their own accord is not told they left.
- Workspace admins are notified when somebody joins, leaves, is invited, or has their workspace role changed — who it was, and what changed. This is a governance record, so it goes to every admin except the one who made the change.
- Project role changes reach the member but not the workspace admins: they happen often enough that reporting them would bury the arrivals and departures that matter.
- An address with no account yet cannot be notified in the app — the invitation email is their notification, and the admins are told the invitation went out. They are told again when it is accepted, which is the join.
These notifications email by default as well as appearing in the bell, since losing access to a workspace is not news that can wait. Turn email off in personal settings if you would rather only see them in the app.
Inviting someone who has no account yet
Adding an email that already has an OpenV account joins that person straight away — if they are already in the workspace, OpenV says so rather than adding them twice; change their role in the members table instead. An email with no account gets an invitation, so you never have to ask someone to sign up first:
- The invitation is valid for seven days and can be used once. It names the workspace and the role you chose.
- If the server has email configured, the invitation is sent to that address. If it does not, OpenV shows you the invitation link once, right after you create it — copy it then and send it yourself. It cannot be shown again; create a fresh invitation if you lose it.
- Opening the link signed out starts sign-up with the address filled in, and the link carries through whether they create an account or sign in to one they already have. Opening it while already signed in shows the invitation with a Join button, so nobody is put into the workspace without seeing it — and if that browser is signed in as somebody else, it says which address to sign in as instead. The link is what grants the membership, and only to the address it was sent to: signing up for the invited address without the link joins nothing.
- An invitation never changes a role somebody already has. If you invite an existing admin as a member, they stay an admin — use the members table to change a role.
- Re-inviting an address is how you resend: the previous link stops working, expired or not, and only the newest one lets them in.
- Pending invitations are listed above the Add member form while any are outstanding, with who they were sent to and when they expire. Revoke stops a link working immediately.
On a server where the operator has closed public registration, an invitation is the only way in besides single sign-on — the sign-in page then says so instead of offering Create a new account.
Limits
Settings → Limits shows everything this workspace is allowed to do, with how much of each is used. It is there so you find out before you are stopped, rather than at the moment something refuses you.
| Limit | What it counts |
|---|---|
| Workspace members | People in the workspace. Invitations you have sent but nobody has accepted count towards it, so a seat is reserved from the moment you invite somebody. A personal workspace always seats exactly one person — you — and no plan changes that. |
| Projects | Projects in this workspace. |
| Shared workspaces | Shared workspaces you have created. Your personal workspace is never counted. |
| Test evidence storage | Total size of the evidence files uploaded for physical and manual tests. |
| Largest figure | The biggest single file you can attach to an artifact — a drawing, a datasheet or a CAD model. |
| Cloud runner lease | How long a leased cloud runner lasts before it is reclaimed. |
| Cloud runner idle window | How long a leased cloud runner may sit unused before it is reclaimed. |
| Hosted runner memory / CPUs | What an always-on hosted runner gets. |
Anything shown as No limit has no ceiling at all. A bar turns amber at 80% and red when it is full — except where the number is simply a fact rather than a ration, like your personal workspace's single seat, which is shown in grey because nothing raises it.
When you hit one
The message says what stopped you, how close you are, and what to do about it — for example "Workspace members: this workspace allows 5 and already has 5 (including invitations not yet accepted)." Nothing is deleted and nobody loses access: a full workspace refuses the next member, project or upload, and everything already there keeps working exactly as before. The same is true if a limit is ever lowered beneath you.
Your personal workspace is the exception: it is only ever you. Adding somebody to it is refused however much you pay, because a personal workspace with two people in it is a shared workspace. Create a shared workspace instead, and invite them there.
On the hosted service, upgrading the workspace's plan raises these; if you are not an admin, the message tells you to ask one. On a self-hosted OpenV there is no plan — whoever runs the server sets the limits, and the message names the setting they need to change.
Teams
Teams are named groups of workspace members (e.g. "Design engineering", "QA"). Their purpose is project access management: a project can grant a team access as a unit (Project Settings → Access → team access), with a role per grant. Admins create teams, add/remove members, rename, and delete them — deleting a team also removes its project access grants.
Not to be confused with Crews, which are graphs of AI agents (and people) that execute work — see the Crews chapter.
AI Providers (admin only)
Per-provider configuration for agent runs:
- Detection status — whether the provider's CLI was found on a worker host, whether it is logged in, and its version ("never detected" means no worker has reported yet).
- Default model — the model agents use when set to provider default.
- Connect — start a workspace-targeted CLI sign-in that any of the workspace's shared workers can pick up. (Personal sign-ins live in your user settings instead — see Runs & runners.)
- Enable/disable providers for runs.
Runners
Everything that executes agent work:
- Hosted runner — admins can provision the always-on, platform-managed runner container by entering the org's provider API keys. Status, stop/start and remove (optionally purging its data volume) are managed here. Non-admins see read-only status.
- My runner — your personal runner key and online status, with the Agent Connector pairing flow. Also reachable from your user settings.
- Worker keys — shared workspace keys for self-managed always-on workers. The plaintext key is shown once, right after creation — store it safely. Keys can be revoked at any time.