Skip to content
Cinatra Docs

Admin Guide

This guide is for platform administrators — the people working inside /administration/* on a running Cinatra instance. Admins configure LLM providers, manage the marketplace and extensions, grant and revoke permissions, watch telemetry, and tune instance-wide settings.

If you are an end user, see the User Guide. If you install or operate Cinatra, see the Hosting Guide. If you work on the code, see the Developer Guide. For the MCP server, see the MCP Guide.

The /administration area

Section titled “The /administration area”

The administration surface at /administration groups the platform-level controls into clearly scoped pages. Most are admin-only by default.

  • LLM providers — configure provider credentials and per-provider model selection. Provider routing is centralised in the orchestration layer, so a provider change applies to every agent.
  • MCP — settings for the external MCP server: tool exposure, OAuth client registration, server-level options.
  • Assistants — chat-assistant configuration: system prompts, tooling defaults, the function-tool list for built-in chat.
  • Marketplace — see Marketplace for the full reference. Install agents and skill packages from the shared registry, archive or restore them, promote private packages to public.
  • Extensions — the installed-extensions lifecycle: install, archive, restore, force-delete, plus GitHub-URL skill upload. See the Extensions reference for protocol-level details on installation and origin tracking.
  • Permissions — the generic co-owner / access-policy model for agents, agent runs, skill packages, and individual skills. Invite members, change roles, manage per-resource grants.
  • Network — registry connections and A2A peer URLs for cross-instance collaboration.
  • Environment — per-instance environment knobs surfaced through the UI. The Registries tab is where you submit a registry-connection request, see its status, and verify the credential round-trip. Other tabs cover agent install paths and instance-scoped runtime settings.
  • Telemetry — cost and usage rollups by agent and by provider. The same data feeds the metrics dashboard.
  • Instance — instance-level identity: the namespace under which this instance publishes packages, the canonical origin, the trusted-origin list.
  • Workspace — Better Auth’s organisation/team management surface (note: the URL says “workspace” but the underlying entity is the Organization ownership level).
  • Operations — background-job monitoring (BullMQ dashboard), queue health, failed-job triage.

Common admin tasks

Section titled “Common admin tasks”
  • Managing the marketplace — install, update, archive, restore; private vs public; promotion to public
  • The Hosting Guide → Configuration page documents the environment variables behind the in-app settings; admins sometimes need to coordinate with whoever operates the deployment

How admin actions are audited

Section titled “How admin actions are audited”

Every install, update, archive, restore, force-delete, and promote writes a row to audit_events. The actor is the admin who took the action; the resource type and ID identify what changed; the event timestamp is set in the same transaction as the underlying mutation. See Security for the full audit-trail model.

Permissions and the admin role

Section titled “Permissions and the admin role”

The Better Auth admin plugin grants the platform-level admin role. The first user to register on a fresh deployment becomes admin automatically; subsequent admin grants are issued through /administration/permissions. The admin role is global to the instance — it gates the /administration/* surface and the admin-only MCP primitives.

Per-resource permissions (co-owners on individual agents, dashboards, skill packages) are independent from the admin role. An admin can override per-resource permissions; a non-admin co-owner cannot.

Where to go next

Section titled “Where to go next”