Apache-2.0 · Self-hosted

Self-hosted database and stateful-service orchestration on infrastructure you run.

Karakoram provisions and operates databases, message brokers, search, identity, secrets and workflow engines on a provider you control: a Go control plane with a REST API, the karactl CLI, a web UI and an MCP server for AI agents. No Kubernetes, no hosted coordinator.

Read the docs Install View on GitHub

Runs on Zerops Dokploy Nomad What does it cost?

What it is, and what it is not

Karakoram is

A control plane you run on your own infrastructure provider, with your own credentials: Zerops, Dokploy or Nomad.
A coordinator for databases, message brokers, search, identity, secrets and workflow engines, with engine-specific topologies, access controls and recovery procedures.
Yours to operate. You own the infrastructure, credentials, data and recovery procedures. The provider supplies runtimes, volumes and routing; it is not the operator of your databases and services.

Karakoram is not

A managed or hosted service. Nobody runs it for you.
A Kubernetes operator. It talks to each provider's own API directly: the Zerops REST API, Dokploy or Nomad.
A guarantee of physical-host anti-affinity or independent failure domains. Healthy voters do not prove that.
Highly available itself: the control plane has one replica and each member's volume lives on a single host.

Read the limitations before production use

What it operates

Twelve engines behind one control plane. Each card shows its release status and links to the documentation that describes supported capabilities and provider availability.

Engines

MongoDB
Percona Server for MongoDB with Percona Backup for MongoDB: replica sets of 1, 3, 5 or 7 members, sharded clusters with config servers and mongos routers, PBM logical and physical backups, point-in-time recovery, in-place restore and clone.
See also Sharded clusters
PostgreSQL
Percona PostgreSQL 17 by default, with 16 and 18 majors: a single member or three- and five-member Patroni/etcd HA with a ProxySQL client service, PostGIS, pgvector and TimescaleDB extension profiles, native roles, databases and grants, bindings that give a consumer its own role and databases, pgBackRest full, differential and incremental backups with point-in-time recovery, offline restore and clone, and an experimental Citus distributed topology of one coordinator plus up to eight worker groups.
See also Extension profiles · Consumer bindings · Distributed (Citus)
Supabase
Modular self-hosted Supabase on the PostgreSQL engine: an Envoy gateway, Auth and PostgREST by default, with Realtime, Storage, Studio, Edge Functions, Supavisor and analytics as separately sized components, versions locked to the Karakoram release.
See also Components
RabbitMQ
RabbitMQ 4.3 clusters of 1, 3, 5 or 7 brokers with persistent per-node storage, quorum queues by default, quorum-gated rolling changes, virtual host, user, permission and policy administration, AMQPS, optional public management UI and definitions backups (no messages or PITR).
Elasticsearch
Combined-node or dedicated-master Elasticsearch clusters with optional same-version Kibana, Logstash and APM Server, native users, roles and API keys, CA-verified HTTPS, S3 snapshots with restore and clone, and shard-drain-aware scale-down.
MySQLExperimental
Percona Server for MySQL 8.4 by default, with 8.0: a single member or three- and five-member single-primary Group Replication behind ProxySQL, native users, databases and grants, XtraBackup full and incremental backups with GTID-based point-in-time recovery.
See also Backups and PITR
Percona XtraDB ClusterExperimental
A separate driver for Galera clusters of three or five Percona XtraDB Cluster 8.4 or 8.0 members with encrypted IST and SST, one ProxySQL-routed writer despite Galera’s multi-writer capability, the same MySQL access interface, and XtraBackup backups with PITR kept under their own provenance.
See also Configuration and topology
Neo4j CommunityExperimental
Neo4j Community 2026.10 on a Temurin 21 JRE: exactly one member with a persistent volume, required TLS, allowlisted settings with heap and page-cache overrides, and offline dumps of the system and graph databases as backups. Every backup is an outage, so schedules need explicit consent; there is no PITR.
See also Offline backups
WeaviateExperimental
Official Weaviate 1.40 binaries with community features only: a single member or clusters of 3 to 9 data members with three fixed Raft voters, API keys, RBAC and dynamic database users, client TLS by default, native S3 full backups (no incremental or PITR) and scale-down that drains replicas before removing non-voters.
See also Access and TLS
KeycloakExperimental
Official Keycloak 26.8 on OpenJDK 21: one native runtime whose realms, identities and sessions live in a bound PostgreSQL database with a dedicated non-superuser role, JDBC over verify-full TLS, sealed bootstrap credentials and a private HTTP port for your TLS-terminating ingress.
See also PostgreSQL bindings
OpenBaoExperimental
OpenBao 2.7 with integrated Raft: 1, 3 or 5 members, mandatory TLS with a cluster CA, a Shamir seal by default or transit and AWS KMS auto-unseal, S3 Raft-snapshot backups (no PITR), and native tokens and policies for application access.
See also Operations and unseal
TemporalExperimental
Temporal 1.32 or 1.31 with the release-locked web UI, persisted in a bound PostgreSQL cluster: a combined server or split stateless roles with independent replicas, a private TLS gRPC frontend with client certificates, and recovery from the source PostgreSQL backup plus a cluster-state manifest. Runs on Dokploy and Nomad; not yet on Zerops, which lacks the private IPv4 route it needs.
See also Operations and recovery

Across engines

Scaling, replacement and rolling upgrades
CPU and RAM bounds, persistent disk growth on Zerops, member-aware scaling and replacement, rolling upgrades and restarts that change one node at a time and wait for quorum, explicit FCV promotion for MongoDB, backup-gated major upgrades for PostgreSQL.
Backups, restore and clone
S3-compatible storage, UTC schedules with count retention, in-place restore and clone: PBM backups with PITR for MongoDB, pgBackRest backups with PITR for PostgreSQL and Supabase, XtraBackup with PITR for MySQL and PXC, native snapshots for Elasticsearch and Weaviate, Raft snapshots for OpenBao, offline dumps for Neo4j, definitions exports for RabbitMQ.
Fleet operations and recoveryVerified offline
Rolling agent upgrades kept separate from database upgrades, maintenance windows that defer disruptive work, member relocation through native replacement, S3 snapshots of the control plane’s own state with rebuild runbooks, webhook, Slack and email notification channels, and backup drills that restore a backup into a scratch cluster and record what was checked.
See also Backup drills · Notifications · Maintenance windows
Suspend, resume and delete
Volumes and backups are separate assets: keep volumes to suspend a cluster and resume it later, keep backups to recover from them, or delete everything the cluster owns.
Users, TLS and access
Engine-native accounts and roles, independently rotatable system accounts, generated or supplied TLS certificates, opt-in public TCP access with CIDR allowlists.
Monitoring, auth and RBAC
Per-member monitoring, authenticated Prometheus output, events and logs, local accounts, OIDC, RBAC and owner-scoped API tokens.
See also Access control
Namespaces
Operate clusters across several provider targets (Zerops projects, Dokploy environments, Nomad namespaces) from one control plane: per-namespace credentials, outbound authenticated relays and permission-gated cross-namespace restore and clone.

REST APIGenerated, strict HTTP contract; every authenticated operation carries explicit authorization metadata.karactl CLIGenerated client for the same API, with saved connection contexts.Web UIEmbedded React SPA served by the control plane.MCP serverThe same API as tools for AI agents, read-only by default, over Streamable HTTP or a stdio bridge.

Providers

One control plane, three places to run it

A provider supplies runtimes, persistent volumes and routing through its own API; Karakoram never needs Kubernetes. Zerops is the reference provider. See the provider comparison for status and acceptance limits.

Reference provider
Zerops
Import one YAML into an existing project. Runtimes, Local Storage volumes, HTTPS subdomains and public ports come from the Zerops REST API with a project-scoped token.
Dokploy
A Dokploy-managed Docker Swarm you operate: one application per member, node-local named volumes spread within a replica set or cluster while enough eligible nodes exist, Swarm ingress for public ports and Traefik domains for HTTPS.
Nomad
A HashiCorp Nomad cluster you operate: one exec job per member on an Ubuntu rootfs, dynamic host volumes, Nomad Variables for state and your own load balancer in front.

Compare the providers Operating costs

How it runs

Everything lives on your own provider

The figure shows a sharded MongoDB cluster. PostgreSQL and MySQL members, RabbitMQ brokers, Elasticsearch, Weaviate and OpenBao nodes follow the same pattern: one Ubuntu 24.04 runtime and one persistent volume per node, a node agent next to the engine process, and backups written to object storage you register. The provider supplies the runtimes, volumes and routing; the layout is the same on Zerops, Dokploy and Nomad.

Control plane: One karakoram runtime with a karakoramdata volume for its SQLite state. Browsers andkaractl reach it over HTTPS; it provisions runtimes and volumes through the provider's own API with the credentials you give its namespace: a project-scoped token on Zerops, an admin API key on Dokploy, an ACL token on Nomad.
Members and nodes: One Ubuntu 24.04 runtime per mongod (including config servers), PostgreSQL or MySQL member, RabbitMQ broker, Elasticsearch, Weaviate or OpenBao node and Neo4j server, each with its own persistent volume. A node agent supervises the engine process, plus the PBM agent for MongoDB and Patroni with etcd for PostgreSQL HA, and talks to the control plane over TLS with pinned trust roots.
Stateless services: A mongos router per sharded cluster, a ProxySQL client service per PostgreSQL or MySQL cluster, Supabase's gateway and application services, optional Kibana, Logstash and APM Server per Elasticsearch cluster, and Keycloak and Temporal roles that keep their state in a bound PostgreSQL cluster, without a persistent data volume.
Backups: PBM agents write MongoDB backups and the PITR oplog, pgBackRest writes PostgreSQL base backups and WAL, XtraBackup writes MySQL and PXC backups and binary logs, Elasticsearch and Weaviate nodes write snapshots, OpenBao writes Raft snapshots, and RabbitMQ definitions exports and Neo4j dumps are uploaded to S3-compatible object storage outside the members.

Architecture and trust boundaries

AI agents

Let an agent operate it. Read-only until you say otherwise.

The control plane embeds an MCP server at /mcp: every REST operation is a tool, executed through the same authentication, RBAC and audit path as karactl. Claude Code, Claude Desktop, Cursor, VS Code, Codex or any other spec-compliant client connects with a restricted token or OAuth.

karactl mcp config

# Management MCP: a read-only token for one namespace, printed as a
# `claude mcp add` command (or --client cursor, vscode, codex, json)
karactl mcp config --client claude-code -n production

# Cluster data MCP: a token for the data inside one cluster
karactl mcp config --cluster production/appdb --client cursor

Each command creates a dedicated API token, read-only unless you pass --write, and prints the client configuration once. The secret never exceeds its owner's permissions and expires after 90 days by default.

Read-only by default: KARAKORAM_MCP=readonly is the installation default. readwrite is an explicit operator opt-in in the service environment; off removes the endpoint.
Restricted tokens: Tokens limited to read actions, namespaces or one cluster, intersected with the owner's RBAC on every call. Opt-in OAuth 2.1 with PKCE for connectors such as Claude Desktop, audience-bound to /mcp.
Confirmation for destructive actions: The server writes the summary, binds the approval to the exact arguments for five minutes and audits the answer. There is no model-settable confirm flag; a client without elicitation gets an error, not a deletion.
Per-cluster data MCP experimental: One endpoint per cluster for the data inside it: MongoDB and PostgreSQL/Supabase through reviewed upstream servers, Elasticsearch and RabbitMQ natively, with rotated read/write database identities and four independent write switches.
llms.txt: This site publishes /llms.txt, /llms-full.txt and a Markdown twin of every documentation page, so agents can read the manual as easily as the API.

MCP quick start MCP server reference Cluster data MCP

Install

Deploy on Zerops with one import, or bring your own Dokploy or Nomad

On Zerops, the reference provider, the import below creates the control plane service and its volume in an existing project; you need a project-scoped Full access integration token. Dokploy and Nomad have their own guides.

deploy/zerops/import.yaml

#yamlPreprocessor=on
# SPDX-License-Identifier: Apache-2.0
# Copyright 2026 The Karakoram Authors
# Set buildFromGit to your fork's public URL when deploying a fork, and set
# zeropsSetup to karakoram-source: the default setup deploys the upstream release.
# To deploy a local checkout, use import-local.yaml and install.sh.
services:
  - hostname: karakoramdata
    type: local-storage:single@1
    verticalAutoscaling:
      minDisk: 5
      maxDisk: 5
  - hostname: karakoram
    type: ubuntu@24.04
    minContainers: 1
    maxContainers: 1
    enableSubdomainAccess: true
    buildFromGit: https://github.com/KarakoramDev/Karakoram
    zeropsSetup: karakoram
    envSecrets:
      KARAKORAM_MASTER_KEY: <@generateRandomString(<48>)>
      KARAKORAM_ADMIN_PASSWORD: <@generateRandomString(<24>)>
      # Replace before import, or set in the service GUI and restart after import.
      # Zerops reserves ZEROPS_* for system variables.
      KARAKORAM_ZEROPS_TOKEN: ""
    verticalAutoscaling:
      cpuMode: SHARED
      minCpu: 1
      maxCpu: 1
      minRam: 0.5
      maxRam: 1
      minDisk: 1
      maxDisk: 2

Import the services. In your project's dashboard choose Import services and paste the YAML, or run zcli project service-import import.yaml -P "$PROJECT_ID".
Set the token. On the karakoram service, set the secret KARAKORAM_ZEROPS_TOKEN to your project-scoped Full access integration token. Never commit it. Keep the generated KARAKORAM_MASTER_KEY andKARAKORAM_ADMIN_PASSWORD.
Wait for build and deploy. The Git build and deploy processes must finish; the import response alone is not enough. If the token was empty at import, set it and restart or redeploy.
Sign in. Open the service's HTTPS subdomain, sign in as admin with the generated KARAKORAM_ADMIN_PASSWORD, change the password, then sign in again.

Zerops provider guide Zerops quick start Full installation guideCovers prerequisites, secret handling, installing from a local checkout with zcli, custom domains and CLI login.

DokployBuild the control plane image from deploy/dokploy/Dockerfile on your Swarm; members become Dokploy applications.NomadRegister the supplied job, volume and ACL policy from deploy/nomad/; members become exec jobs on your clients.What does it cost?Karakoram is free software. You pay for the infrastructure you use: runtimes or hosts, persistent storage and separately provisioned S3-compatible object storage. The operating costs page walks through estimates per provider.

Built on Percona, RabbitMQ, Elastic, Supabase and other open-source engines, inspired by OpenEverest

Percona

Thank you to Percona for Percona Server for MongoDB, Percona Backup for MongoDB, Percona Distribution for PostgreSQL, Percona Server for MySQL, Percona XtraDB Cluster and Percona XtraBackup. Karakoram installs the MongoDB and PostgreSQL packages from Percona's official repositories at repo.percona.com and the MySQL family from Percona's official checksum-locked tarballs. The engines, replication, backups and point-in-time recovery come from their open-source work, together with Patroni, etcd, pgBackRest, ProxySQL and, for PostgreSQL profiles and the distributed topology, PostGIS, pgvector, TimescaleDB (Apache-only build) and Citus (AGPL-3.0, downloaded separately, never bundled); Karakoram coordinates those capabilities rather than reinventing them.

RabbitMQ and Elastic

Thank you to the RabbitMQ team for the broker, quorum queues and the Management API, and to Elastic for Elasticsearch, Kibana, Logstash and APM Server. Karakoram installs both on your own runtimes at deploy time, from RabbitMQ's package repositories and Elastic's official distributions, and redistributes no binaries. Elastic's default distributions carry their own license terms, described in the Elasticsearch guide.

Supabase

Thank you to Supabase for Auth, PostgREST, Realtime, Storage, Studio, Edge Runtime, Supavisor and the rest of the open-source stack that the Supabase engine assembles on top of the PostgreSQL engine, and to Envoy for the gateway. Component versions are locked to each Karakoram release and installed on your own runtimes from checksum-pinned artifacts; see components and availability.

Weaviate and Neo4j

Thank you to Weaviate for the vector database, used with community features only under its mixed-license binary boundary, and to Neo4j for Neo4j Community (GPLv3) and the graph tooling around it. Both are downloaded as official, checksum-locked artifacts onto your own runtimes; Karakoram redistributes no binaries. See native artifacts for provenance and license notices.

Keycloak, OpenBao and Temporal

Thank you to Keycloak for the identity server, to OpenBao (MPL-2.0) for the secrets manager with integrated Raft, and to Temporal for the workflow server and its web UI. Keycloak and Temporal keep their state in a PostgreSQL cluster that Karakoram binds to them; OpenBao owns its own Raft volumes. Each runs from release-locked artifacts on runtimes you provide.

OpenEverest

OpenEverest is the inspiration for this project. Originally Percona Everest, it is an Apache-2.0 CNCF Sandbox project whose model of self-hosted, provider-based database orchestration shaped Karakoram: Provider and Instance concepts, version bundles, topology schemas, backup storages, PITR and restore flows, and RBAC. Karakoram brings that idea to platforms such as Zerops, Dokploy and Nomad rather than Kubernetes. It is an independent implementation; no OpenEverest code or UI is copied.

The name

Everest is the highest peak. Karakoram is the range that holds K2 and other giants.

The name is a nod to OpenEverest and to growing beyond a single peak. Karakoram orchestrates databases and stateful services on Zerops, Dokploy and Nomad; see the engine guides for provider availability. More engines and providers are a direction, not a claim that they exist.

Contributions are welcome

Open an issue first for anything beyond a small fix, keep each pull request to one logical change, and sign off every commit under the Developer Certificate of Origin (git commit -s). A human submits every contribution.

Supported by

Thank you to Zerops for providing free-of-charge infrastructure for developing and testing Karakoram.