Admin
Admin is the console of whoever runs the installation. The menu entry only appears for a user whose global role is admin, and every API call behind it is gated by that same right: an ordinary editor gets nothing, even by typing the address by hand.
The screen has three tabs: Users, Plans and Audit log.
Tariffs & users
Users
1–50 of 214
| Role | Plan | Credits | Status | |
|---|---|---|---|---|
| ada@example.com | admin | paid | 1,240 | active |
| boris@example.com | editor | free | 18 | active |
| carol@example.com | editor | paid | 0 | suspended |
Users
Search by email or name, 50 rows per page. The table carries the account role, the assigned plan, the credit balance and the subscription status. Clicking a row opens the user’s card, which has four blocks.
Account role. An editor / admin switch. The role is read from the database on every request, so promoting and demoting take effect at once, with no token re-issue. An admin bypasses tariff limits — do not hand out the role as a substitute for raising them.
Subscription. Plan, credit balance and status (“active” or “suspended”). The “Apply subscription” button writes all three at once.
Quotas & usage. Balance, credits used and credits included in the plan, bars for the space taken by the knowledge base, files and database, plus the effective concurrency and timeout values. Under that is the full list of limits in force; the ones set personally carry an “override” badge.
Per-user overrides. A form layered on top of the plan: any field can be changed for this user alone, and a blank field falls back to the plan. A plan has to be assigned first — overrides do not save without one.
Plans
A plan is a template of limits, later assigned to users on the Users tab. The list shows the code, name, description, how many limits are configured, and badges: “system”, “active” or “inactive”.
“Edit” opens the plan editor, “New plan” creates one. The code (free, paid, custom
…) is set at creation and immutable afterwards — it is how the plan is found in code and
migrations. System plans cannot be deleted; the rest have a trash icon with a
confirmation.
Limits are grouped by meaning: credits and the period they renew over, concurrency and
execution, storage quotas (0 = unlimited), per-item caps (workflows, collections,
knowledge bases, files, members) and feature switches (public chat, custom LLM
connections, white-label, credit overage). A separate “Advanced” block is edited as raw
JSON: the allow-lists of node types, models and connection kinds, and per-node parameter
caps. Malformed JSON is refused by the form, an unknown key by the server.
Audit log
A timeline of sensitive actions, searchable by action name, 50 rows per page. The table
shows time, action, outcome (success or failure), the actor and the workspace.
Clicking a row opens a card with the target, the IP address and the full JSON of details.
Recorded actions include sign-ins and registrations (auth.login, auth.register),
account-role changes (user.role_changed), plan and subscription work (plan.created,
plan.updated, plan.deleted, subscription.assigned), secrets and connections
(secret.*, connection.*), workspace changes (workspace.member.*,
workspace.brand.updated, workspace.db_quota_changed), billing
(billing.*), Telegram history erasure (telegram.history.erase) and moderation actions
(telegram.moderate.*).
A failed sign-in is logged too — with a failure outcome — so password guessing is
visible without extra tooling.