Skip to main content
The admin panel at port 3200 is for the person who runs the Ragen installation — not for the people who use it. It gives you a cross-organisation view of everything: who is on the platform, how much they’re using, which connectors are failing, and what security events have occurred. The main app at :3000 handles day-to-day work inside a single organisation; the admin panel handles the infrastructure around all of them.

​
Who can access the admin panel

Access to the panel is controlled by the platform administrator role. This is different from being an organisation owner or admin inside the main app. The panel re-reads the role on every request, so revoking it takes effect immediately rather than waiting for a session to expire.

​
Getting in

1

Create the first account

Create your platform administrator account by completing the first-run setup screen when you first deploy Ragen. That account is automatically granted the platform admin role.
2

Open the admin panel

Navigate to http://localhost:3200 (or your deployed admin URL). Sign in with the same email and password you use for the main app.
3

Grant access to others

From the Users section of the panel, find the account you want to promote and grant it the platform admin role. The account must already exist — the panel does not create accounts.
Google sign-in is available as an optional convenience. The sign-in button appears only when GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are configured. Password sign-in always works for the platform administrator regardless. See OAuth Sign-In for setup details.

​
Panel sections

​
Managing organisations

The Organizations section shows every organisation on your installation. Each organisation’s detail page lets you:
  • View and edit membership (add a user who already has an account, change their role, or remove them)
  • Review the organisation’s settings, subscription limits, and storage usage
  • Browse recent audit log entries for that organisation
Two membership changes are permanently refused: you cannot remove or demote the last owner of an organisation, and you cannot add an account that doesn’t exist yet. The panel manages membership — it does not create accounts.

​
Managing API keys

The API Keys section lists every key across the installation. The Last Used column is the most important one: a key that has never been called is a good candidate for revocation. Two separate controls let you act on a key:
Revoking a key requires RAGEN_TOKEN_VAULT_URL and RAGEN_TOKEN_VAULT_SERVICE_SECRET to be configured on the admin panel. Without them, the panel still lists and deactivates keys but shows a warning explaining why Revoke is unavailable. If the vault is unreachable mid-revoke, the key is left deactivated with its record intact — the panel tells you the secret survived rather than deleting the only record of it.

​
Applying limit defaults to existing organisations

When you update a platform-wide default in Limits & Models, that default applies only to newly created organisations. Use Apply Defaults to propagate a change to existing organisations. The panel shows you exactly which values would change before writing anything.
Apply Defaults raises and lowers values but never removes them — a blank default cannot be distinguished from “leave this organisation alone.” The fields it will skip are listed by name in the preview.

​
Exporting data

The Activity log, AI usage, disk usage, API keys, connectors, and incidents each export to CSV, honouring the filters currently on screen rather than dumping the whole table. Downloading an export is itself recorded in the activity log. CSV cells are protected against formula injection, so values beginning with = or @ cannot execute when the file is opened in a spreadsheet.

​
Activity log and security incidents

Every mutating action in the panel is recorded with before-and-after values. Sensitive fields (masked API key values, tokens) are redacted before the entry is written. Incidents is the security-event view. It shows failed sign-ins, brute-force detection, connector authorisation failures, rate-limit breaches, and cross-organisation access attempts. You can mark events as resolved, and that resolution is recorded too.
Configure email alerts for security events with SECURITY_ALERT_EMAIL and SECURITY_ALERT_SEVERITY. The severity threshold defaults to critical. Alerts are deduplicated over 15 minutes and capped per hour to prevent alert flooding during an incident.

​
What the panel deliberately cannot do

Read anyone’s conversations. The panel has no message viewer and no impersonation capability. An operator does not need to read customer messages to run the platform. Thread content is encrypted per organisation, and the panel holds no path to decrypt it. This is enforced at the permission level, not merely absent from the UI. Platform administrators are explicitly denied impersonation rights — the route rejects such requests regardless of whether a UI button exists. This ensures that removing a UI element cannot accidentally re-expose the capability. Create user accounts. The panel grants roles and manages membership. The account must exist first, created by the user themselves through the main app. Export everything at once. Thread export is per-thread, scoped to one organisation, and requires ownership or org-admin access. There is no bulk export-everything route — this is a deliberate decision, not an oversight. Undo a propagation. Applying defaults to existing organisations writes customer-visible settings with no revert path. The preview step before applying is the only undo mechanism. These constraints exist because operator convenience and user privacy are in tension at the platform level. The panel is designed to give you everything you need to run the installation without giving you everything that exists in it.