For Platform Admins / Doable Owners

This guide is for the person (or small team) running a Doable instance. If you self-host Doable, control billing, or are the first account on a fresh install, this section is yours. It walks the entire /admin surface from the operator's seat: what each screen does, when you reach for it, and what you should not expect it to do.

If you are looking for workspace admin tasks (inviting collaborators, picking an AI model for one team, building knowledge bases), that lives under /workspace-settings and is documented separately in the User Guide.

Who is a platform admin?

A platform admin is a person whose account has been granted the platform-tier role of admin or owner. The /admin route is gated to that group only; everyone else who tries the URL sees an empty state.

There are two roles inside the platform tier:

• owner: the bootstrap account. Typically the person who installed Doable. Cannot be demoted by themselves and shows the crown icon in the user list.
• admin: granted by an existing platform admin via the Users & AI tab. Can do everything an owner can, except demote the owner.

Compare that with the workspace tier, which has its own role ladder (owner, admin, member) scoped to a single workspace. A workspace owner is not a platform admin. The two systems are orthogonal: you can be a platform admin without belonging to any workspace, and you can own a workspace without ever seeing /admin.

We use the neutral term platform admin throughout. Operators are accountable, not omnipotent. Every read or write on sensitive surfaces (audit logs, MFA resets, allocations) is recorded.

How platform admin status is granted

There are three ways to become a platform admin:

1. Bootstrap. On a fresh install the first account that signs up is promoted to platform_role = 'owner' automatically. The default account is set up by deployment/server-setup.sh. See First-time setup.
2. Promotion from the Users & AI tab. An existing platform admin opens /admin?tab=users, finds the target user, and changes the Role select to admin. The change is audit-logged. See Every /admin screen: Users & AI.
3. Direct DB update (last resort). Set platform_role = 'admin' on the user row when no admin is left to do the promotion from the UI. Treat this as a recovery path, not a routine one.

Self-protection: the API refuses to let a caller demote their own is_platform_admin or platform_role, so you cannot accidentally lock everyone out by demoting yourself.

Where the panel lives

The Platform Admin panel is at:

https://<your-doable-host>/admin

On the default install that is the same host as the dashboard (doable.me in production, 127.0.0.1:3000 in local dev). The panel is a tabbed dashboard plus a handful of dedicated side surfaces.

The full surface area

The tabbed dashboard at /admin has eleven main tabs:

Tab	Use it for
Feature Flags	Toggle product features on/off per plan and role; manage Frameworks
DNS	Cloudflare wildcard automation, CF API token rotation
Signups	Waitlist approval, blocklist, signup-gate message
Users & AI	Per-user role, plan, credits, AI allocation
Integrations	Platform-wide OAuth apps and credential vault
Plans	Per-plan quota caps and default AI configuration
AI Tools	Mode-to-allowed-tools registry
MFA	Per-user TOTP reset (cannot enforce yet)
Thumbnails	Backfill missing project thumbnails
Sessions	Live Copilot engine pool snapshot, terminate stuck engines
Email	Outbound email provider, broadcasts, retry dead-letter

Plus seven side surfaces that have their own URL:

URL	Use it for
/admin/audit	Search every AI conversation across the instance (audit logged)
/admin/audit/actions	Audit the auditors; every admin read recorded
/admin/chat	All AI chat sessions, redacted
/admin/dev-servers	Live sandbox processes (per-project preview servers)
/admin/moderation	Marketplace moderation queue
/admin/projects	Every project across every workspace
/admin/runtime	Published apps + dev servers with CPU/memory/uptime
/admin/trace	X-Ray / OpenTelemetry trace search

The deep walkthrough lives in Every /admin screen.

What a platform admin CAN do

• Promote and demote other platform admins (except themselves)
• Move any user between plans, set role, credits, AI source and model
• Approve, deny, or block any pending signup
• Allocate platform-owned Copilot accounts and AI providers into a user's workspace (cloned with re-encrypted tokens)
• Read every AI conversation in the instance via /admin/audit and /admin/chat
• Reset a user's MFA (clears TOTP and recovery codes; signs them out)
• Toggle every feature flag, change plan limits, edit the AI Tools registry
• Rotate the Cloudflare API token used for wildcard DNS
• Register global OAuth apps so workspaces can connect to Slack, Google Drive, GitHub, etc., without their own credentials
• Inspect live dev servers, terminate stuck Copilot engines, backfill thumbnails
• Send platform-wide email broadcasts

What a platform admin CANNOT do

These are deliberate boundaries, not gaps to file bugs against.

• Read another user's personal AI provider keys. AI accounts are split into personal scope (private to the user) and workspace scope (shared with the team). Only workspace-scope rows show up in admin tooling. See Personal vs workspace AI scope.
• Decrypt stored secrets in clear. OAuth client secrets, Copilot tokens, provider API keys, and the Cloudflare API token are encrypted at rest. The UI shows token suffixes only, never the full value.
• Demote themselves. Self-protection is enforced in the role and admin endpoints.
• Enforce MFA platform-wide. The schema supports it; the UI does not yet. MFA is opt-in (per project_mfa_implementation.md).
• Skip the audit log. Every audit read is itself audited at /admin/audit/actions. Every admin write that flows through recordAdminAction() (MFA reset, sandbox edits, OAuth app changes, AI allocations, plan-limit edits) is captured too.
• Bind services to public interfaces. The whole instance binds to 127.0.0.1 and goes through Cloudflare Tunnel; there is no admin toggle to expose ports.

Start with First-time setup on a fresh install. It covers bootstrap admin, default plan, AI providers, integration registry, MFA, DNS wildcard, email, and the first signup test. Then read Every /admin screen for the full walkthrough: one section per screen with URL, controls, common tasks, and what to watch for. Use it as a tutorial on day one, then as a tabbed reference forever after.

For quick reference once you know your way around, the per-screen pages under Operations → Platform Admin are intentionally short. Bookmark them for the screen you touch most often.

House style for operators

• We default to neutral, plain words. Plans are "Free / Pro / Business / Enterprise," roles are "member / admin / owner," destructive actions are spelled out before they fire.
• We never instruct you to weaken security as a workaround. If a rate limit is in your way during QA, the kill switch is short-lived and re-enabled afterwards.
• We mark unfinished surfaces as TBD rather than pretending they ship. Where the research file says TBD, this guide does too.