Skip to main content

Platform Settings

Platform settings are the instance-wide configuration knobs that control how Miabi behaves across every workspace. They're stored as typed, cached key/value entries and managed centrally by the platform administrator.

Platform settings

Typed and cached​

Each setting is typed — string, int, bool or json — and the type decides how its stored value is read. The console renders each type with a matching control: a switch for booleans, a number field for integers, and a list for settings with a fixed set of values, such as the control manager mode, so a near-miss can't be typed in. The API itself does not check a value against its type, so use the console or send well-formed values.

Settings are also cached in memory, so they're read on the hot path without a database lookup every time. Saving refreshes the cache of the process that handled it at once; other control-plane processes pick the change up within 15 seconds. No restart is needed.

PropertyMeaning
TypedEach key has a type that decides how its value is read
CachedValues are served from memory for fast, low-overhead reads
Key/valueSimple, addressable configuration entries

Who can change them​

Platform settings are instance-wide, not workspace-scoped, so they are managed by the platform administrator rather than by individual workspace members. This keeps cross-tenant configuration in one trusted place. See Platform administration for the full admin surface and who holds that role.

note

Platform settings differ from a workspace's own configuration. A workspace member (Owner, Admin, Developer, Viewer) manages resources inside their workspace; platform settings sit above workspaces and apply to the whole instance.

Notable settings​

Admin → Platform → Platform Settings groups the settings into cards:

CardSettingEffect
Registration & accessRequire email verification (require_email_verification)New self-service accounts must confirm their address before signing in
Allowed signup domains (allowed_signup_domains)Comma-separated allow-list for self-service sign-up; blank admits any domain
Let invitees create their account from the invitation (invitation_signup_enabled)An invitee without an account can sign up from the invitation, even while self-service sign-up is closed (default on)
Who can create workspaces (workspace_creation)anyone, except_invited (default) or admins_only — see Who can create workspaces
PlatformMaintenance mode (maintenance_mode)API requests are refused with HTTP 503, except sign-in, health checks and the platform admin endpoints, so admins can still operate the platform
Allow custom container labels (custom_labels_enabled)Fleet-wide kill-switch for custom container labels. When off, the feature is disabled everywhere regardless of any plan capability; when on, the per-plan capability decides
Allow pipelines from .miabi/pipeline.yaml (repo_pipelines_enabled)Fleet-wide kill-switch for adopting a pipeline from a repository; when off, git apps always build directly
Control manager (control_manager_mode)off, observe (default) or enforce — see Reconciliation
Limits & retentionDefault max workspaces per user — owned / — joined as memberThe per-user caps for the whole install. With an Enterprise licence an organization may carry its own instead. Defaults: 10 owned, unlimited joined. -1 = unlimited, 0 = none
Audit log retention (days) (audit_log_retention_days)See Audit Log (default 90; 0 keeps entries forever)
Resource limitsMax CPU cores per app / Max memory per app, MBPer-application caps (0 = unlimited)

Some keys are handled specially:

  • Set by environment. require_email_verification, allowed_signup_domains, invitation_signup_enabled, workspace_creation and control_manager_mode can be pinned from MIABI_REQUIRE_EMAIL_VERIFICATION, MIABI_ALLOWED_SIGNUP_DOMAINS, MIABI_INVITATION_SIGNUP_ENABLED, MIABI_WORKSPACE_CREATION and MIABI_CONTROL_MANAGER_MODE. A pinned key is re-applied on every boot, shown as set by environment, and can't be edited.
  • Boot-time access controls. Allow self-service sign-up (MIABI_REGISTRATION_ENABLED) and Allow self-service password reset (MIABI_PASSWORD_RESET_ENABLED) aren't stored settings. The Registration & access card shows them read-only — see Authentication.
  • Read-only. The Install ID is system-managed and shown under Deployment. The Encryption and Networking cards are read-only too: they report what boot configuration produced — encryption posture, and the address family, subnet pool and shared proxy network of Networks & subnets.
  • Reserved. Keys named cluster_name or starting with app., image. or brand. belong to other admin pages. They are hidden from this list and refused by the settings API.

Settings vs. environment variables​

Some configuration is supplied at boot through environment variables (for example the metrics scrape interval and retention covered in Configuration), while platform settings are managed live in the console.

  • Environment variables — set at startup; good for deployment-level and infrastructure values.
  • Platform settings — changed at runtime through the admin UI; good for operational values you want to adjust without redeploying.
tip

Prefer platform settings for values you expect to tune over time, and environment variables for values that belong to how the instance is deployed.