Platform Admin
The platform admin (super-admin) is the account responsible for the Miabi instance as a whole — the parts of the system that sit above any single workspace.
How the platform admin is created
The platform admin is seeded from configuration on first boot — not by the first person to sign
up. Miabi creates it from MIABI_ADMIN_EMAIL and MIABI_ADMIN_PASSWORD before anyone can register,
so an admin always already exists.
| Variable | Default | Purpose |
|---|---|---|
MIABI_ADMIN_EMAIL | admin@example.com | Login of the seeded platform admin |
MIABI_ADMIN_PASSWORD | — | Required in production. Miabi refuses to start outside dev while this is empty or left at its built-in default |
The one-line installer generates a password, writes it to /opt/miabi/.env, and prints it once at
the end of the run. Sign in with those credentials; every self-service sign-up afterwards is an
ordinary user until invited into a workspace.
Treat this account as a privileged operations identity. Change the generated password after first sign-in, enable any available SSO/MFA, and reserve it for platform tasks rather than day-to-day app work.
What the platform admin manages
Platform admins handle cross-workspace, instance-level concerns:
| Area | Responsibility |
|---|---|
| Nodes | View the fleet, check node status and health, and assign capacity. See Nodes & Capacity. |
| Platform settings | Manage the typed, cached key-value configuration that governs instance-wide behavior. See Platform Settings. |
| Capacity | Understand how much compute is available across the fleet and how workspaces consume it. |
| Upgrades | Roll the instance forward to a newer image. See Upgrades. |
These responsibilities are global. A platform admin is concerned with the server, the fleet, and the configuration that everything else runs on — not with the contents of any one workspace.
Managed containers are protected
The node view lists every container on a node, including the ones Miabi manages (apps, databases, gateways). By default a platform admin cannot stop or remove a Miabi-managed container from that list — those are operated through the resource that owns them, so the platform can't be desynchronised from what is actually running.
| Variable | Default | Purpose |
|---|---|---|
MIABI_SECURITY_ENFORCEMENT | true | Blocks raw stop/remove of managed containers in the admin node view. Set false as a break-glass escape hatch |
This is unrelated to MIABI_PLAN_ENFORCEMENT, despite the similar name: that one gates per-workspace
quotas and capability gates. Both default to true.
Platform admin vs workspace roles
Platform administration is separate from the per-workspace permission model. Inside a workspace, access is governed by the Owner, Admin, Developer, and Viewer roles, which control who can create apps, deploy, manage domains, and so on. Those roles are scoped to a single workspace and do not grant any platform-level access.
A user can be a platform admin and hold a workspace role — the two layers are independent and enforced separately.
For the full breakdown of workspace-level capabilities, see Roles & Permissions.
Where to go next
- Nodes & Capacity — the operational view of your fleet.
- Platform Settings — instance-wide configuration.
- Upgrades — moving to a newer release.