Page · Operators

The console your platform team lives in.

Kimezu is built for the person who runs a platform with one identity team. The console is one pane of glass for every tenant, every session, every payment route, every audit trail. No tab-switching between vendors.

Surface
One console, every tenant
Roles
Per-tenant, namespaced
Audit
HMAC-chained, queryable
The console

The console manages every tenant from one surface.

A real screenshot, not a marketing render. This is what your platform team looks at on a Monday morning.

Configure tenants, rotate keys, review audit chains, set payment routes.

Each module below is built in, none of them assume you've integrated a third-party.

01 Authentication healthLogin success rate, failed-login spikes, active sessions per tenant. live
02 Application usagePer-app login volume over the recent window, switchable by tenant. window
03 Platform statisticsTotal tenants, webhooks, payments, gross revenue, at a glance. €
04 App distributionActive vs dormant apps, with one-click revocation of stale credentials. ops
console.kimezu.com/rozuro/statistics
Kimezu operator console, statistics overview
Person scanning a QR code on a phone with a laptop open behind it (moving between devices in the same session)

The operator's day, one console, many tenants

An operator runs Kimezu the way an editor runs a magazine, one surface, all the brands. The console is the only thing they need open.

Tenant configuration

Set up once, propagated everywhere.

A tenant is configured in a single screen. The protocol underneath provisions DNS, certificates, signing keys, OIDC discovery and theming in one go.

Identity

Tenant ID
rozuro · UUID t_8f2b3e1c…
Primary domain
id.rozuro.com
Region
EU-west · TODO
Created
2024-08-12 · TODO days ago
Status
Active, TODO connected apps

Brand

Display name
Rozuro
Logo
rozuro-logo.svg · uploaded
Primary colour
#0F766E deep teal
Support email
help@rozuro.com
Footer copy
"Rozuro is a finance OS for solo operators."

Authentication

Methods enabled
Password · Magic link
MFA policy
Required for admins, optional for users
Session lifetime
15 min access · 30 day refresh
JWKS rotation
Every 24 hours

Payments

Profile
prf_rozuro_eu
Providers
Stripe (cards) · Mollie (iDEAL, SEPA)
VAT country
NL · 21% standard rate
OSS scheme
Registered · NL OSS
Reverse charge
B2B with valid VIES VAT ID
Laptop and smartphone side by side — the operator moving between devices

Hands moving between devices, the operator's daily surface

Operating identity for someone else's tenants is an administrative job, not a marketing one. Most days look like clicking through a tenant configuration, signing a key rotation, and exporting an audit slice. The work the console makes routine is the work the brief calls boring on purpose.

Theming kit

White-label that holds up to the brand team.

Sign-in screens, magic-link emails, OAuth consent pages, OIDC discovery, payment receipts and audit-log dashboards all carry the tenant's brand. Configure once, and never look at it again.

The theming kit is a single JSON document per tenant. It lists colour roles (primary, surface, ink, line), typography overrides (only system fonts, by policy), logo URLs, copy strings, and a small set of feature flags that turn methods on or off per tenant.

The document is versioned, lives in your git repository if you want it to, and can be deployed by your existing change-management process. Operators on the Self-hosted plan often manage tenants as code (a pull request adds a tenant, CI deploys the JSON, production reflects it on the next request).

The brand team should never have to talk to the auth team to change a button colour.

For tenants that don't want to engage with JSON at all, the operator console exposes the same fields as a form. The data structure is identical; only the editing surface differs. Same end result, same audit trail.

THEME   tenants/rozuro.theme.json 
{
  "tenant": "rozuro",
  "brand": {
    "name": "Rozuro",
    "logo": "https://cdn.../rozuro.svg",
    "support_email": "help@rozuro.com"
  },
  "palette": {
    "accent": "#0F766E",
    "accent_soft": "#E5F2F0",
    "ink": "#1F1B16"
  },
  "copy": {
    "signin_title": "Welcome back.",
    "signin_lede":  "Sign in to Rozuro."
  },
  "methods": [
    "password", "magic-link"
  ]
}
i
System fonts only. Kimezu's policy is to never load a third-party font on a sign-in surface. The cost of a Google-Fonts call on the login screen is privacy theatre that customers can see, and we'd rather not pay it.
Observability

The audit log is the source of truth.

Every authentication, authorization decision, administrative action and tenant change is recorded into a HMAC-chained log. Operators can query, export, and verify it externally, nobody (including us) can quietly rewrite history.

a. Tamper-evident chainEach entry is HMAC-SHA-256 over the previous entry's hash plus the new event. A single tampered byte breaks the chain at that point and every entry after. verifiable
b. Per-tenant exportCSV or JSONL, signed with the tenant's audit key. Pipe into your SIEM, your S3 bucket, your accountant. The format is documented and stable. CSV · JSONL
c. Canary tokensDeliberately-issued tokens that should never be used. Any validation attempt triggers an alert and is recorded as a security event (a tripwire for stolen-credentials scenarios). on by default
d. Webhook alertsFailed-login spikes, key rotations, agent revocations, suspicious permission grants. Sent to your incident channel (Slack, PagerDuty, Teams, plain HTTP). real-time
e. External verificationThe chain head is published hourly. Any operator can independently verify their own audit log integrity without trusting us. hourly
Two people at a table working on a laptop together (operator and brand lead reviewing a tenant's surface)

Operator and brand lead reviewing a tenant's surface

Theming, copy, sign-in routes, reviewed in the console before they reach a single user. The operator is the audience; the tenant team is the second pair of eyes.

Tenant support

Operators help tenants without reading their data.

Most tenant support questions don't need access to user records. Kimezu gives operators a workflow surface that resolves the common ones, with the principle that no operator should ever read a tenant's user data.

The operator support surface is intentionally narrow. From it, operators can: trigger a password reset email, send a magic-link email, end an active session, revoke an agent token, look up an audit entry by ID, and re-issue a confirmation. None of these expose user PII.

Tenants who need deeper support (account merges, region transfers, GDPR exports) raise a ticket through Kimezu's tenant-support API. The operator can see that the request was made and approve it; only the user themselves can authorize the action by clicking through a signed link in their email.

Helping a user shouldn't require reading their data.

Every support action is recorded into the audit log with the operator's identity, the target tenant, and the affected user (by opaque sub claim, never by email). Operators can prove what they did and didn't see. Compliance teams stop having uncomfortable conversations.

SUPPORT   POST /v1/support/reset 
// Operator asks Kimezu to email a reset link.
// The operator never sees the user's email.

POST /v1/support/reset
Authorization: Bearer <op_token>

{
  "tenant": "rozuro",
  "sub": "usr_8f2b3e1c",
  "reason": "ticket #4119"
}

// → 202 Accepted
//   Audit: op_reset · masked sub · ticket id
See it live

Walk through the console with an engineer.

Thirty minutes, no slides. Pick a workflow above and we'll show it on a real instance. Bring your platform questions.

Book a walk-through → Read the docs first
Sandbox
No card required

One tenant, the full console, real audit log. Start →

Migration
A human pair-programmer

Operator tier includes paired migration time.