For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt, and this page is available as Markdown at /docs/about.md.
Ivory

    About Ivory

    What Ivory Is

    Ivory is a self-hosted web UI for operating high-availability database clusters: deploy a cluster, watch its health and replication lag, run a switchover or failover, open a query console, control containers over SSH and read VM metrics and logs — from a browser or a phone, without dropping into the CLI for every task.

    It is designed for DBAs, SREs and backend developers who run such clusters and want one place to operate, troubleshoot and deploy them. It runs as a local tool on your machine or as a shared service on a VM for team use, ships as a single Docker container and stores everything itself: no agent on your hosts, no orchestrator, no cloud account.

    The Keeper

    Ivory is built around the concept of a Keeper — a generic management layer responsible for cluster manipulations. A Keeper can be a standalone agent running beside the database, or a management system embedded directly in the database engine. Patroni is the Keeper implementation for PostgreSQL, and the one Ivory was originally built around. See Overview → What is a Keeper? for how it shapes the cluster view.

    Vision: Beyond Postgres

    Ivory started as a Postgres/Patroni tool. It is moving towards a pluggable architecture, where support for other databases and HA tools is added as a plugin instead of being baked into the core.

    Version
    v1Hard-wired to Patroni and Postgres, with Postgres-centric node management and no mobile support.
    v2Pluggable Keeper and database engines — each database is managed through a simple plugin instead of core behaviour. Node management is VM-centric, with nodes modeled as Hardware + Software behind a generic Platform abstraction (on-prem Docker over SSH today, Kubernetes/OpenShift planned). The UI is mobile friendly, so you can check on and operate your clusters from your phone.

    Why These Databases

    KeeperWhy
    PatroniThe Keeper Ivory was originally built around
    PostgresNot everyone needs HA — sometimes you just want to manage a plain Postgres
    ETCDPatroni relies on etcd as a DCS, so managing it directly made sense too
    RedisA widely used cache/store that often sits right next to the databases Ivory already manages
    ClickHouseA popular analytics database and a natural next step for Ivory's plugin set
    ZooKeeperClickHouse needs the real ZooKeeper protocol, not etcd, to coordinate replication — deployable as its own ensemble and usable as the external DCS other keepers point at
    MongoDBA widely used document store with its own native replica-set HA, a natural fit next to Ivory's other native (non-orchestrated) keepers

    These particular databases weren't picked from a grand roadmap — they're mainly what the maintainer runs day to day, and Ivory exists to simplify that routine first. Broader support grows from there.