Admin settings

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. For role definitions and invites, see 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

​

Admin vs Owner cheat sheet

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. Audit log & Security Center (Business)
12. 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/@<handle>.
• 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.

​

People & roles

Most member management is documented under 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.

​

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 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.

​

Workspace templates (Business)

Mark any project as a workspace template so members can spin up new projects from it. Admins manage the catalogue:

• Mark a project as a template, or unmark.
• Set one template as the default that’s pre-selected on the New project screen.
• Any member can use a workspace template; only Admin and Owner manage them.

See Project settings → Templates for the per-project view.

​

Audit log (Business)

Every workspace-sensitive action is recorded with the actor, timestamp, and IP. The panel supports filtering by action type — useful when you only need the role changes from last quarter, or every connector authorisation from a specific week. Logged events include:

• Project creation, archive, delete, and moves between workspaces.
• Member invites, role changes, removals, and self-leaves.
• Plan and cap changes (visible to Admins, recorded against the Owner who made them).
• Connector authorisations and revocations, BYO OAuth changes.
• Secret reads — yes, accessing a connector secret is logged.
• Sign-in events.
• SSO config changes and domain-restriction edits.

The log exports to JSON or CSV. Business plans support streaming export to a SIEM (Datadog, Splunk, S3).

​

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.

​

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.
• 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.

​

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.

---

​

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

​

Next