Skip to main content
Version: Next (nightly)

The operator console

Running the instance gives you a tier of access that no workspace role has: every workspace, every account, the instance's own health. That console lives at /admin.

  1. Put your email in SUPERADMIN_EMAILS in .env.
  2. Register with that address.
  3. Open /admin.

A workspace owner or admin controls one workspace. The operator sits above all of them. This is the admin surface for a self-hosted instance you run. It manages the people and workspaces on your box. It is not a hosted service anyone signs up for.

How you become the operator​

  1. Add your email to SUPERADMIN_EMAILS in .env:

    SUPERADMIN_EMAILS=you@example.com

  2. Register your account normally with that address.

  3. Already have an account? Add the email and recreate the api container. The existing account gains operator access with no re-registration:

    docker compose up -d
  • More than one operator: the value is a comma-separated list.
  • The setup builder fills this line from the email you enter.
  • Nobody reaches /admin by signing up. The flag is checked against your account's email. It is your email on the box that unlocks it.
  • Without a matching email, /admin answers Platform-admin only. Set SUPERADMIN_EMAILS to include your email.

A separate tier, not a bigger role​

  • The operator flag gates the /super-admin API and the /admin pages. It leaves the per-workspace roles untouched.
  • You are not a member of anyone's workspace. Being the operator does not raise your role inside workspaces you do belong to, either.
  • To act inside a workspace you don't own, use view-as, which is audited and read-only until you deliberately arm editing.

What /admin gives you​

The console is grouped into sections, navigated from a sidebar that matches the workspace shell.

  • Every group is visible at once in the sidebar, which stays put while a long table scrolls. On a phone the open section scrolls into view.
  • Every section opens with a page title and a line saying what it is for.
  • Wide tables get the whole screen.
  • A mistyped console address redirects instead of quietly showing the wrong page.

The sections a self-hoster reaches for:

  • Workspaces and users: see every workspace with its owner, member count, and last activity, freeze or remove one, and list every account across the instance.
  • Invites and signups: mint single-use join links and control whether public signup is open.
  • View-as: render a workspace as one of its members for support, read-only by default, with a banner the whole time.
  • Instance settings: read which switches are live on the instance, post announcements, send a targeted notice to affected members.
  • Metrics: the Overview counts, per-workspace product metrics, cross-workspace AI usage, and a health snapshot.
Sections you can ignore on a private instance

A few sections exist for an instance that also fronts a public signup form: a Waitlist tab that ingests submissions and a Feedback tab. If you run Cobblr for yourself or a known group, those stay empty and you can ignore them.