Fleet · Servers
Every node, registered and observed
Servers, cluster topology and replica health from one screen. A node that joins registers itself ; a replica that fails leaves the rotation.
Platform · Studio
One cockpit for the entire estate.
Every node, tenant, user, credential, database, pool, scheduled task and AI provider the platform serves, administered from one authenticated session under the same role model as the applications it runs. Adding a node is a registration ; removing one is a deregistration ; the cluster redistributes. The same catalogue is exposed to administrators as a separate MCP world of 96 tools, so the estate can be operated by a person, by a script, or by a supervised agent — with every act recorded.
The Studio manager : application servers, database servers, databases, users and identity, security and scheduled tasks in the sidebar ; a user record open on its database grants, with connection users, environments and write verbs.
The fleet
Servers registered from one interface ; cluster topology — primaries, replicas, health checks — managed centrally. A node discovers its configuration from the configuration database ; failed replicas are excluded from the read rotation automatically.
Identity and grants
Companies, departments, users, administrators and identities. Platform roles gate the tooling ; per-database grants open a database through a pool with the verbs and ceilings the keeper sets. Without a grant, no application role applies.
Data
Database servers with their credential pairs, database registrations with their dictionary stacks, connection pools with limits profiles, engine users, environments and keepers. A six-step health chain proves a database reachable before anyone depends on it.
Governance
Authentication mechanisms, authorisation, security roles, the key vault, IP and CIDR access rules, query limits, the program sandbox, mail and Redis services, scheduled tasks, AI providers and ceilings, and the audit — queryable as SQL.
Server and cluster management
Adding capacity is a registration. The runtime's supervisor is what an external orchestrator would otherwise have to be.
Registration, not provisioning
A new node is a JVM with the platform artefact and a connection string to the configuration database. It registers, discovers the metadata repository, the engines, the pools, the microservice mesh, the AI providers and the tenants, and joins the cluster. Removing it is a deregistration.
Topology and replicas
Primaries, replicas and health-check configuration are managed centrally. Read load distributes across healthy replicas by a configurable strategy ; a failed replica leaves the rotation and returns when it recovers, without an operator coordinating either.
Federated monitoring
One queryable catalogue across every node : pools, memory, caches, sessions and live SQL, read through one SELECT with node-identity columns. The cluster is observed as a single table, not node by node.
Bringing a system up
A guided setup wizard, an administration console, and upgrades that list what they will change before they are authorised. A boot pre-flight refuses weak keys and reports drift rather than applying it.
Databases, pools and engine users
A database is registered on a server, reached through a pool, and opened by a grant. Studio keeps the three apart, because each fails differently.
Database servers and credential pairs
The catalogue row with its group, environment and administrative credential pair ; registration, change, and a reachability check with the pairs it stores. The pairs that pools bind to are the server's, and are written there.
Registrations and dictionary stacks
A database as the platform sees it : its server, its environment, the ordered stack of dictionaries that define it, physical creation when it does not exist yet, the ping, the health chain, and an unregistration whose backup is journalled. The stack is what every other surface resolves against.
Connection pools and limits profiles
Pools on a credential pair, with limits profiles for connection tiers. A grant names a pool ; a pool that does not materialise is the most common reason a granted database resolves to nothing, and the check says so before a user does.
Physical engine users
Users inside the database engine, as opposed to platform users : created, granted and revoked CONNECT, listed, dropped — with the plan naming every pool a drop would break before it does.
Identity, roles and permissions
The same role model that governs the application governs the management surface itself. Administrators see what their role permits, no more.
Users, companies, departments
The profile, its department and company, the platform roles that gate the tooling, the database grants that open a database through a pool, the sessions, and the check that says whether it all resolves. Everything the application role system filters inside of starts here.
Eight authentication mechanisms, configured per user or integration
HTTP Basic, Digest, Form with two-factor, JWT, OAuth 2.1, OpenID Connect, SAML 2.0 and mTLS, assignable per user or per integration and switchable without a redeploy. Multi-factor enrolment and device reset are administered from the same record.
Security operations, one act at a time
Block and unblock with the reason recorded, reset a password, reset two-factor, revoke tokens, end sessions. Each is its own act because each has a different consequence : a block does not end sessions, and ending sessions does not block.
Security answers, computed by the enforcement code
What one user may do on one database ; who reaches a database and with what ; who can open one object and why ; what one user may do to one table, verb by verb and row by row ; the menu exactly as one user sees it ; and a lint that finds what is wrong without being told where. Granted apart from administration, so an auditor reads without being able to change anything.
Per-database application roles — seven families
Where security is applied inside an application once a user holds a grant on a database. Definitions are database-independent ; assignments are per user, per database.
What opens
The application family decides which objects open, as a grant list or a deny list, deny winning. A grant role with no items denies everything to whoever holds it — which is why the tools prove a role before storing it and never delete a role someone holds.
Rows and verbs
The row-condition families splice a condition into every query on a table — the row-security injector — and carry the table's insert, update, delete and execute flags, combined with the physical grant, the registration and the user's grant. A condition that does not prepare is refused, not stored.
Windows, defaults, endpoints, cubes
A lock family closes an object's execution, print or export in a time window ; a defaults family sets column defaults and read-only columns at render ; an API family names the REST endpoints a user may call ; a cube family governs analytical access.
Three gates when an object opens
The application role, the lock window, then a per-database list built from the dictionary's own security expressions. The one-call answers wrap the platform's enforcement code, never a re-derivation of it.
The key vault, access rules and platform services
The parts an auditor asks about, administered as records with owners.
The key vault
TLS certificates issued, renewed and revoked centrally, with expiry visible before it becomes an incident ; SSH key pairs and password secrets held with owners and managers ; every addition and removal its own audited act. Scripts retrieve a secret at run time and never see key material.
IP and CIDR access rules
A rule names which of four paths it restricts — standard login, REST API, administration, workbench — and the addresses admitted ; a company points at one rule. A rule that would lock everyone out, the administrator included, is refused unless the lockout is meant. In force at the next login.
Mail and Redis, checked in layers
The SMTP resolution, the real SMTP conversation, the templates the platform sends and a week of traffic — because the two-factor code and the login-risk alert travel by mail and each layer fails silently on its own. Redis : the stored row, a pool-independent ping, the live counters.
Scheduled tasks
Authored, deployed and monitored from Studio : run history, next fire time and last execution log in one place. Tasks are metadata records ; a change propagates to the cluster without a node restart.
AI providers, ceilings and the tool permission model
The administration half of the AI surface : what is registered, what it may cost, and who may hand a tool to whom.
Providers and models
Every provider registered with its credentials in the key vault, its enabled models and per-model pricing. Defaults cascade from platform to company to department to user, per function — chat, embeddings, reranking, speech.
Ceilings, caps and quotas
The AI ceiling on each database grant ; monthly spend caps per company ; request quotas per user ; token limits per request ; model allow-lists. Enforced before a call reaches a provider ; reported as a query against the activity log.
The tool permission model
The code registers tools ; a sync publishes them with their category and risk class — plan first, journalled backup, rollback by log id ; an administrator grants a user a tool, a pattern or a whole category, and the grant records why. A granted tool pulls in what it cannot work without, never at a higher risk. Revoke, migrate, list who holds what.
The audit, and its one write
Every MCP call with the commands it ran, the logins and the raw attempts, the object executions — listed, read and aggregated. Purging the audit is the one write in the family and is classed apart.
In the product
Studio, as the administrator sees it
Screens from the running platform. Captures follow the administrator access ; each slot names what it will show.
1 / 8
Why the cockpit is part of the platform
Most enterprise platforms split administration across the vendor's console, the identity provider's console, the database team's tooling and a scheduler. Each has its own access model, its own audit and its own lag, and the operator paying for them rarely sees one picture of the estate.
Studio administers the estate under the same role model, the same audit and the same runtime as the applications it runs. A server, a database, a pool, a user, a grant, a secret and a scheduled task are records ; changing one is a recorded act that propagates to the cluster without a restart. The same catalogue is served to administrators as an MCP world of 96 tools, so the operations that a person performs from the cockpit can be delegated to a supervised agent under the same gates — and refused, gated or recorded in the same audit.
Studio questions
What operators and auditors ask about administration.
What does it take to add a node to the cluster?
A JVM with the platform artefact and a connection string to the configuration database. The node registers, discovers the metadata repository, the engines, the pools, the microservice mesh, the AI providers and the tenants, and joins the cluster. There is no per-node configuration file, no container manifest and no orchestrator.
Can an auditor read the security posture without being able to change it?
Yes. The security answers — what a user may do on a database, who reaches a database, who can open an object and why, the row-security fragment a table's queries receive, the menu as one user sees it, and the lint — are computed by the platform's own enforcement code and granted apart from user and role administration. Nothing in that family writes.
How is a secret handled?
It is a record in the key vault with an owner and managers. Destructive and administrative actions are restricted to them ; adding or removing a secret is its own audited act ; scripts retrieve it at run time and never see the material in code. Certificates carry their expiry, visible before it becomes an incident.
Can administration be delegated to an AI agent?
Through the administration MCP world, to administrators only, under the same five gates and the same audit as every other agent call. Administration tools are never loadable into a development or application session. Purging the audit is classed apart and granted separately.
What is checked before a system serves?
A boot pre-flight refuses weak RSA and signing keys ; upgrades list what they will change before they are authorised ; database drivers are verified by checksum on every load ; a six-step health chain proves a database reachable before a grant depends on it.