Security for the system that runs your databases
-
Setup without default passwords
The first start asks for a one-time setup token from the server, and you create the owner account yourself, so a freshly exposed install cannot be taken over with known credentials.
-
Two-factor sign-in
Passwords hashed with argon2id, a six-digit authenticator code, recovery codes and lockout after repeated failures.
-
Sudo mode
Approving a server, revealing a secret or issuing a token asks for your password and a new code again, valid for ten minutes.
-
Roles and scoped tokens
Five roles from viewer to owner, and personal access tokens limited by scope, environment, IP address and expiry.
-
Encrypted secrets
Every secret has its own key, wrapped by a versioned master key that can be rotated; secrets are redacted everywhere they could leak.
-
Internal certificate authority
Certificates for the console and the agents, and a separate authority for each cluster arriving with clusters in v0.1, so one cluster’s certificate can never authenticate to another.
-
Tamper-evident audit log
Each entry is hashed with the previous one and signed anchors are exported, so a verify command detects edits and truncation. Export to JSON lines, syslog, a webhook or S3.
-
Protection against SSRF
Every outbound call is checked against private and cloud-metadata addresses, with DNS answers pinned so a rebinding trick cannot slip through.
Roles
Roles are granted per project to people; per-environment grants are being built now, and teams and service accounts are planned for v0.8. Instance-wide settings such as users, the engine catalog and shared servers belong to instance admins, which is a separate flag rather than a role. A token can never do more than its owner’s current role, so demoting someone immediately limits their tokens too.
| Role | Adds |
|---|---|
| Viewer | Sees clusters, metrics, logs, backups and the audit log. |
| Developer | Also manages databases and users with preset privileges and uses the SQL editor: read-only, and write mode outside production. |
| Operator | Also runs day-2 operations up to high risk, cancels sessions, runs maintenance jobs and approves plans up to medium risk. |
| Admin | Also creates and deletes clusters, adds and approves servers, manages repositories, credentials and join tokens, and approves high and critical plans. |
| Owner | Also manages members, teams, environments and their policies, notification channels and webhooks. |
Servers that trust carefully
Agents dial out to the control plane over mutual TLS, so servers need no inbound management port. A server added with a join token waits until an admin approves it, and tokens can never approve servers. The agent image and its updates are checked against signatures before anything runs.
Each server keeps a local policy that only its owner can change on the machine itself: which directories may hold
data, which registries and signing keys are allowed, and what the control plane may never do. A compromised
control plane still cannot make an agent mount /, rewrite its own policy or run an image from an
arbitrary registry.
TLS everywhere
Every connection uses TLS 1.2 or newer, preferring 1.3. Today that covers the console, the API and the agents; replication, client endpoints and backups follow as clusters arrive from v0.1. The console can use the internal authority, your own certificate or an ACME certificate. Cluster certificates will rotate through plans, and a cluster’s authority can be rolled over without downtime using a transition bundle.
Being built and planned
- In development now Invitations, password and two-factor resets that never bypass two-factor, emergency break-glass access, token rotation with a grace period, and signing in to the CLI from the browser.
- Planned for v0.8 Single sign-on with OpenID Connect (Keycloak, Authentik, Zitadel, Entra ID, Okta, Google), passkeys, teams synced from groups, service accounts and session management.
- Planned for v1.0 An external penetration test before general availability.
- Planned for v1.1 OAuth for MCP clients and SCIM user provisioning.
Supply chain
Releases will pin images by digest, sign them and come with software bills of materials. The engine catalog that decides which versions may run is signed and versioned so it cannot be rolled back silently; it is being built now. The agent image is verified today; verifying every image and offline proofs for air-gapped installs are planned for v0.8.
No telemetry by default
ElastiCluster does not phone home. The only outbound checks planned are optional checks for updates and engine catalog changes, and they can be turned off.
Related
- AI and MCP A built-in MCP server, planned for v0.3, lets Claude Code, Cursor, Codex and other assistants work through the same plans as people, with limits per environment and humans approving risky changes.
- Server management Add Linux servers over SSH or with a one-line install. A small agent dials out to the control plane, checks the host before anything runs and updates itself without restarting databases.
- Platform teams Give developers self-service databases on your own infrastructure with projects, environments, policies, approvals, single sign-on, audit and an API: an internal DBaaS you don’t have to build.
Try the console before it ships
The interactive demo runs the whole console on simulated data. Trigger a failover, approve an AI assistant’s plan, restore a backup to a point in time. Nothing to install.