Highly available databases on servers you control
ElastiCluster is a self-hosted database cluster manager in development. Run one container, add your Linux servers, and create PostgreSQL, MongoDB, Valkey, MariaDB Galera and S3 clusters that fail over on their own, back themselves up and change only through plans you review.
Servers and agents work in development builds today; PostgreSQL high availability is the first preview. What works today
-
1. Normal operation
Applications write through the rw endpoint to the primary, db-1. The synchronous standby, db-2, confirms each commit.
-
2. The primary stops responding
db-1 goes silent. Its leader lock in etcd expires, and Patroni on the remaining members notices.
-
3. The standby is promoted
Patroni promotes db-2. As the synchronous standby it already holds every acknowledged write.
-
4. The endpoint follows
HAProxy health checks send rw to db-2 and writes resume. db-3 replicates from the new primary.
-
5. The old primary rejoins
When db-1 is back, it rejoins as a replica. The control plane was never needed for any of this.
Six engines, one way of working
One console for every cluster and server
Health, alerts, approvals, running operations and the upcoming schedule on one page. Every number links to the detail behind it, and every action opens a plan.
Every change is a plan you can read first
Restarts, upgrades, configuration changes, new members, restores: nothing touches a cluster until it has been planned, checked against the environment’s policy and, where that policy says so, approved by a person. It works the same from the console, the CLI, the API and an AI assistant.
Step 1 of 3
Read the plan before anything runs
A rolling restart of orders-db becomes four ordered actions with an estimated duration, a risk level and the disruption each step causes. The policy line says whether it can run now or needs someone else’s approval.
- Diff, actions and risk in one sheet
- Run now or in the next maintenance window
- The same plan for the console, CLI, API and AI assistants
Step 2 of 3
Approvals stay with people
Risky plans wait in the approvals inbox with their reason, consequences and requirements. Four-eyes rules keep the requester, and the owner of an AI token, from approving their own change.
- Highest risk first, with expiry and requirements
- Stale approvals ask for a re-plan instead of running
- Every decision is in the audit log
Step 3 of 3
Watch it run, step by step
An applied plan becomes an operation with live logs per step. If a step fails, the operation pauses and offers retry, skip or abort, and a restarted control plane resumes where it left off.
- Live step logs and progress
- Pauses on failure instead of guessing
- Resumes after a control-plane restart
In development now Plans and approvals are being built now. How plans and approvals work
From bare servers to a running cluster
No Kubernetes, no Ansible inventory, no hand-written Patroni configuration. ElastiCluster puts each piece where it belongs and keeps it there.
-
Start the control plane
One container holds the console, the REST API and its own SQLite database, with no separate database or queue to run. The MCP server and built-in monitoring join it in v0.3.
Working in development builds -
Add your servers
Add a Linux server over SSH from the console, or paste a one-line install command with a join token. The agent dials out, checks the host and waits for an admin to approve it.
Working in development builds -
Create a cluster
Start from a template, pick servers, review the plan and apply it. For PostgreSQL that sets up Patroni, etcd, PgBouncer and HAProxy endpoints, with TLS on.
Planned for v0.1
Day-2 operations, built in
All features and their status- High availability Automatic failover with Patroni and stable endpoints for PostgreSQL first; replica-set elections, Sentinel and Galera follow with their engines. Planned for v0.1
- Backups and recovery Encrypted backups on by default, point-in-time recovery, restores to a new cluster and scheduled restore drills. Planned for v0.2
- Plans and approvals Every change previewed with its risk and disruption, approved by the right people, run as a resumable operation. In development now
- Monitoring and alerts Metrics, logs, health conditions and about 100 alert rules with runbooks, without a separate monitoring stack. Planned for v0.3
- DBA tools A SQL editor that starts read-only, query insights, and sessions and locks; maintenance jobs and guided major upgrades follow in v0.7. Planned for v0.3
- AI and MCP Claude Code, Cursor and other assistants work through the same plans, within limits you set per environment. Planned for v0.3
- Security Roles, two-factor sign-in, re-authentication for sensitive actions, an internal CA and a tamper-evident audit log. Working in development builds
- Server management SSH or one-line installs, admin approval, preflight checks and agents that update themselves without restarting databases. Working in development builds
Let AI assistants help without handing them the keys
A built-in MCP server lets Claude Code, Cursor, Codex and other assistants inspect clusters, diagnose problems and propose changes. They go through the same plans and policies as people.
- Limits per environment: full control in development, propose-only in production by default.
- Approvals are always human, and a token’s owner can never approve its requests.
- Kill switches stop every AI write at once; every call is in the audit log.
Your databases never depend on ElastiCluster
Out of the data path
The control plane plans and observes; each engine’s own high-availability tooling does the work. Failover, endpoints and log archiving keep running while the control plane is down.
No lock-in
Remove the agent and the databases keep running as plain containers. Backups use each engine’s standard tools and formats, with documented manual restores.
Native tools keep working
patronictl, mongosh,
valkey-cli and docker ps still tell you
the truth. Nothing hides behind a proprietary layer.
Built for teams that run their own servers
Small teams on a VPS or bare metal
Three servers at Hetzner, OVH or in your own rack, a highly available PostgreSQL with tested backups, and no full-time DBA. What a managed database gives you, on hardware you choose.
For small teamsPlatform teams building an internal DBaaS
Self-service databases for developers, with projects, environments, policies, approvals, single sign-on and an audit trail. The internal database platform, without building one.
For platform teamsAlready all-in on Kubernetes, or happy with a managed cloud database? See when ElastiCluster is not the right fit.
Where the project stands
Two of thirteen milestones are done and the third is being built. Nothing is released yet, and this site labels every feature with its status.
- Working in development builds
- Setup wizard, two-factor sign-in, roles, audit log; adding, checking and approving servers.
- In development now
- Plans, approvals, operations, projects and environments.
- Planned for v0.1
- The first preview: highly available PostgreSQL.
Questions
Can I use it in production today?
No. ElastiCluster is in development and has no release yet. Development builds already set up the control plane, sign in with two-factor codes, and add, check and approve servers with their agents. Plans and approvals are being built now. The first preview, v0.1, brings PostgreSQL high availability, and creating production clusters stays blocked until backups arrive in v0.2. The roadmap lists what each release adds.
What happens to my databases if the control plane goes down?
They keep running. High availability comes from each engine’s own mechanism (Patroni with etcd, replica-set elections, Sentinel, Galera), so failover, endpoints and log archiving work without the control plane. Scheduled backups and drills wait until it is back, interrupted operations resume where they stopped, and an external heartbeat check can alert you that it is gone.
Do I need Kubernetes?
No. ElastiCluster runs databases as containers on ordinary Linux servers, with one small agent per server; the agent can install Docker for you. If your whole platform already runs on Kubernetes, a Kubernetes operator such as CloudNativePG is likely the better fit. See alternatives.
Can an AI assistant break production?
Assistants use the same plans and policies as people. By default an assistant may only propose changes in production; a person approves them, and the owner of an assistant’s token can never approve that token’s requests. Read-only queries run under database roles that cannot write, instance kill switches stop all AI writes at once, and every call is audited. See AI and MCP.
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.