> ## Documentation Index > Fetch the complete documentation index at: https://docs.vibely.sh/docs/llms.txt > Use this file to discover all available pages before exploring further. # Admin settings > The Admin role, what lives under Admin settings, and what each section controls. Admin settings is where workspace-wide controls live — identity, billing, connectors, security, audit. This page covers what the **Admin** role can do, what each section is for, and what's reserved for the **Owner**. For per-project settings, see [Project settings](/docs/workspace/project-settings). For role definitions and invites, see [People](/docs/workspace/people). ## The Admin role The Admin role exists on **Pro** and **Business** plans. Free workspaces only have **Owner**, **Editor**, and **Viewer**. Admins handle day-to-day workspace operations so the Owner doesn't have to. They can manage members, configure security, run audits, set up connectors, and view billing — but they **can't** change the plan, buy top-ups, transfer ownership, or delete the workspace. ### Role hierarchy | Role | What they do | Plan | | ------ | ------------------------------------------------------------------------- | ---- | | Owner | Everything, including billing, ownership transfer, and workspace deletion | Any | | Admin | All workspace settings except billing changes and ownership | Pro+ | | Editor | Create and edit projects | Any | | Viewer | Read-only access to projects | Any | ### Admin vs Owner cheat sheet | Capability | Owner | Admin | Editor | Viewer | | ---------------------------------- | :---: | :-----: | :----: | :----: | | Invite members | ✓ | ✓ | — | — | | Change Editor / Viewer roles | ✓ | ✓ | — | — | | Change Admin / Owner roles | ✓ | — | — | — | | Remove Editor / Viewer | ✓ | ✓ | — | — | | Remove Admin | ✓ | — | — | — | | Manage member groups | ✓ | ✓ (Biz) | — | — | | Workspace name / slug / avatar | ✓ | ✓ | — | — | | Default project visibility | ✓ | ✓ | — | — | | Domain-restricted invites | ✓ | ✓ (Biz) | — | — | | SSO config | ✓ | ✓ (Biz) | — | — | | Workspace connectors | ✓ | ✓ | read | — | | MCP server policy | ✓ | ✓ (Biz) | — | — | | Manage workspace templates | ✓ | ✓ (Biz) | use | — | | Security Center | ✓ | ✓ (Biz) | — | — | | Branded subdomain | ✓ | ✓ (Biz) | — | — | | View billing & invoices | ✓ | ✓ | — | — | | Change plan / cancel / buy top-ups | ✓ | — | — | — | | Member usage view | ✓ | ✓ | self | — | | Per-member credit limit | ✓ | ✓ | — | — | | Move project into workspace | ✓ | ✓ | — | — | | Create / publish projects | ✓ | ✓ | ✓ | — | | Transfer ownership | ✓ | — | — | — | | Delete workspace | ✓ | — | — | — | No one — not even the Owner — can change their own role; ownership transfers in one step instead. *** ## What's under Admin settings The left-nav under **Admin settings** collects every section the Editor and Viewer roles shouldn't touch. 1. Workspace (name, slug, avatar, defaults) 2. People (invites, roles, pending) 3. Connectors (workspace-level) 4. Knowledge 5. Skills 6. Billing (read-only for Admin) 7. Usage 8. Workspace domains 9. Privacy & security 10. Groups *(Business)* 11. Permissions 12. Security Center *(Business)* 13. Git The rest of this page walks through each. ## Workspace identity Open **Admin settings → Workspace**. * **Name** — shown in the sidebar, share links, and member lists. * **Slug** — URL identifier used in share and deploy links. Changing it updates URLs immediately, so existing links stop resolving — plan renames when you're not mid-handoff. * **Avatar** — image shown next to the workspace name. * **Public handle** — used in profile links like `vibely.sh/@`. * **Default credit limit per member** — applies to new members on join; existing members keep their current cap unless edited individually. For the user-facing version of these fields, see [Customize → Workspace](/docs/customize/workspace). ## People & roles Most member management is documented under [People](/docs/workspace/people). Admins can: * Invite members at any role except Owner. * Flip members between Editor and Viewer. * Remove Editors and Viewers (not other Admins). * Revoke pending invitations. * Set per-member credit limits. Admins **cannot** promote anyone to Admin or Owner, change another Admin's role, or remove another Admin — those are Owner actions. ## Privacy & security Workspace-wide policies that gate how members sign in, invite each other, and share work. * **Default project visibility** — sets what new projects start as. **Workspace** is the default; **Restricted** (Business) means every new project is private to its creator until access is explicitly granted. * **Domain-restricted invitations** *(Business)* — only allow invites to specified email domains (e.g. `@your-company.com`). Off-domain invites are blocked at send time. * **Default website access** *(Business)* — controls who can visit a project's published site by default: **Public**, **Workspace**, or **Group-only**. * **Who can publish externally** *(Business)* — restrict the **Publish** button to **Everyone**, **Admins**, or **Owners**. * **Two-factor authentication enforcement** — require every member to enable 2FA on sign-in. * **Session timeout** — auto sign-out after a configurable period of inactivity. * **Data collection opt-out** — disables workspace-wide product telemetry. * **Workspace discovery / public profile** *(Business)* — show or hide the workspace on its public profile page. ## Single sign-on (Business) Bind a corporate email domain to your identity provider so every member signs in through it. * Supports **SAML** and **OIDC** — Okta, Google Workspace, Microsoft Entra, or any conforming IdP. * Domain binding is **one-to-one**: a domain can be bound to a single workspace at a time. If the domain is already bound elsewhere, setup is blocked. * Admins can configure SSO — this is one of the few "global trust" settings the Owner doesn't have to handle personally. ## Member groups (Business) Groups are named buckets of members for bulk access management — e.g. `client-acme`, `eng-mobile`, `design-leads`. * Admins create, rename, and delete groups, and add or remove members. * Each group has an internal role: **group admin** or **group member**. Group admins can edit the group's roster. * Admins can export the full group / member matrix to CSV for compliance. * Group → project grants give a whole group **Admin / Editor / Viewer / read-only Viewer** access to a project in one step. See [People → Team access](/docs/workspace/people#group-project-grants). ## Connectors & integrations Workspace-level OAuth and API-key auth for the third-party connector catalogue (Slack, HubSpot, Notion, Google, Stripe…). Set up once here, available to every project in the workspace. * **Add a connector** — pick from the catalogue and complete OAuth or paste the API key. Credentials are encrypted at rest. * **List / disconnect** — manage individual connections without removing the connector. * **Rotate credentials** — replace an API key without re-creating the connector. * **Revoke** — disconnects every project in the workspace from that service. See [Connectors](/docs/connectors/overview) for the full catalogue. ### Bring your own OAuth app Admins can register a custom OAuth client per connector — your own client ID and secret instead of Vibely's default app. The panel shows the **redirect URI** you need to copy into the provider's developer console. Changing the credentials forces every connected member to re-auth. Use this when: * Your security team requires every outbound integration to come from an app you own. * You've hit a vendor's rate limits or scope ceiling on the shared app. * You want the OAuth consent screen to show your brand instead of "Vibely". ### MCP server policy (Business) Admins can disable specific MCP servers across the entire workspace. Blocked servers don't appear in the agent's connector list, even if a member tries to add one at the project level — useful when an MCP exposes tools your security policy hasn't reviewed yet. ## Knowledge & Skills Two workspace-wide libraries the design and build agents pull from. * **Knowledge** — text and document snippets the agent can cite or follow as instructions across every project. Add product context, brand guidelines, or naming conventions once instead of pasting them into each prompt. * **Skills** — reusable agent recipes (design templates, scaffolds, custom workflows). Admins curate what's available; members pick from the workspace catalogue when starting work. ## Permissions The Permissions section gates who in the workspace can do what beyond the role default. It's where the workspace **Owner** and **Admin** dial member capabilities up or down without inventing a new role. Typical knobs: * Who can author workspace **Skills**. * Who can publish projects externally. * Who can connect new workspace connectors. * Per-action overrides for sensitive flows. ## Security Center (Business) A workspace-wide rollup of every security finding across every project, in one dashboard. Findings are grouped by source: * **RLS** — Supabase row-level-security gaps. * **Database** — public tables without policies, exposed Edge Functions. * **Code** — secrets in source, unsafe SQL, eval of untrusted input. * **Dependencies** — vulnerable npm packages with CVE detail. Each finding has a severity (**error / warning / info**), an owning project, and a link straight to the file or row that triggered it. Admins typically check after a deploy and on a weekly cadence. ### Basic vs Deep scan modes Vibely's security engine runs in two modes: * **Basic** — fast, high-signal pass. The default for everyday iteration and the pre-deploy gate. * **Deep** — exhaustive analysis that follows data flow across files and flags subtler issues. Slower; use before a production release. Both modes feed the same Security Center dashboard. See [Web security](/docs/web-app/security) and [Mobile security](/docs/mobile-app/security) for how the scan integrates into deploy and publish flows. ## Workspace domains & branding * **Workspace domains** — the pool of apex domains available to projects in this workspace. Visible to Editor and above; manageable by Admins. * **Branded subdomain** *(Business)* — replace the default short ID in share and deploy URLs with the workspace slug. Default URLs look like `https://k2m9p4.vibelyagent.com/...`; with branding they become `https://acme.vibelyagent.com/...`. Per-project custom domains still work on top. * **Custom domains on projects** are available on Pro and Business. ## Billing & usage (read-only for Admin) Admins can **view** subscription, plan, monthly credit grant, invoices, and per-member usage — but **cannot** change plans, cancel, or buy top-ups. Those are reserved for the workspace **Owner**. * **Plan & renewal** — current plan, billing cycle, next renewal date. * **Credit balance** — monthly grant, current usage, rollover (Pro+), top-up history. * **Per-member usage** — see who used what across the workspace this period. * **Per-member credit caps** — Admins set these. See [People → Per-member credit limits](/docs/workspace/people#per-member-credit-limits). * **Invoices** — downloadable receipts. * **Tax settings** — GST / VAT ID and billing address; required in some regions. Top-ups, plan changes, and cancellation live with the **Owner** under [Plans and credits](/docs/introduction/plans-credits). ## Marketplace Admins manage which workspace projects are eligible to be **published as public templates** to the Vibely marketplace, and which marketplace templates are installable from this workspace. * Publish a project as a public template (Pro+). * Edit or unpublish existing marketplace listings. * Browse and install community templates from inside the workspace. For private, workspace-only templates, use [Workspace templates](#workspace-templates-business). *** ## Owner-only operations Admins do **not** get these. Even on Business. * **Transfer workspace ownership** — only the Owner can promote a member to Owner. * **Delete the workspace** — and the cascade that follows it. * **Promote anyone to Owner**, or demote an Owner. * **Change another Admin's role**, or remove another Admin. * **Change the plan**, cancel the subscription, or buy top-up credits. For agency handoffs, prefer **Transfer ownership** over **Delete** — the workspace and its published URLs move to the client without rebuilding anything. ## Workspace lifecycle * **Transfer ownership** — moves ownership to another Admin. The previous Owner stays as an Admin unless they choose to leave. * **Delete workspace** — irreversible after a 30-day grace period. Archives every project for the grace window, revokes every connector at the third party, and returns custom domains to 404 within about an hour. ## A few things worth knowing * The workspace credit pool is funded by the **Owner's plan**. Admins can cap individual members, but only the Owner buys top-ups. * Workspace templates are visible to every member; only Admin and Owner can manage what's in the catalogue. * Admins **can't** force themselves into projects they don't already have access to — project-level access still gates them. Use ownership transfer or the project Owner's invite instead. ## Plan gates at a glance | Setting | Free | Pro | Business | | ------------------------------------- | :--: | :-: | :------: | | Admin role exists | — | ✓ | ✓ | | Workspace connectors | — | ✓ | ✓ | | Bring-your-own OAuth app | — | ✓ | ✓ | | Per-member credit caps | — | ✓ | ✓ | | Member groups + group access | — | — | ✓ | | Domain-restricted invitations | — | — | ✓ | | SSO (SAML / OIDC) | — | — | ✓ | | MCP server policy | — | — | ✓ | | Workspace templates | — | — | ✓ | | Security Center | — | — | ✓ | | Branded subdomain | — | — | ✓ | | Restricted default project visibility | — | — | ✓ | ## Next Roles, invites, groups, and per-member credit limits. Per-project config that complements these workspace controls. What each plan unlocks at this level. The user-facing version of workspace identity settings.