OpenEverest: a Kubernetes control plane for databases, storage and LLM workloads

The problem OpenEverest addresses, and who feels it

Provisioning a production database on Kubernetes is rarely one object. It is a StatefulSet plus a headless Service plus a PVC template plus a backup job plus credentials plus whatever the specific engine needs for replication. Each engine has its own operator with its own CRDs, its own version matrix and its own conventions for exposing a connection string. A platform team that supports PostgreSQL, MySQL and MongoDB ends up maintaining three mental models and three upgrade paths.

OpenEverest is aimed at that team. The README describes it as an open source cloud-native database platform that helps developers deploy code faster, scale deployments rapidly and reduce database administration overhead. The practical reading is narrower and more useful: it is a control plane that installs and drives the operators for you, so a developer asks for a database instead of assembling one. The repository topics list databases, kubernetes, llm and storage, and the description extends the same model to storage and LLM provisioning, not only relational engines.

The target user is someone with cluster access who is comfortable with kubectl and Helm but does not want to own the operator lifecycle. It is not a managed service and it does not remove the need for a Kubernetes cluster. If you have no cluster, this is not the layer you are missing.

How the control plane is put together

The repository layout separates concerns in a way that is worth reading before you install anything. There is a Go module at the root, a cli-tests directory, an api directory, a provider-runtime directory and a ui directory. The Makefile builds four distinct dev images: an Everst server image, an operator image, a controller image and a catalog image. That tells you the architecture is not a single binary. There is a server that serves the UI and the API, a controller that reconciles, an operator that owns the database resources, and a catalog that supplies the list of what can be provisioned.

The go.mod confirms the dependency direction. It imports helm.sh/helm/v3, k8s.io/client-go and k8s.io/apimachinery, which is what you would expect from something that installs charts into a cluster. It also imports github.com/percona/everest-operator and the VictoriaMetrics operator API. Authorization is handled by casbin, the HTTP layer is labstack/echo, and the CLI is spf13/cobra. The presence of charmbracelet/bubbletea and lipgloss indicates the interactive installer wizard is a terminal UI rather than a prompt loop.

The data flow is therefore: you install the server and the operator into a namespace, you declare which namespaces OpenEverest may manage, and from then on a request through the UI or API becomes a custom resource that the operator reconciles into actual database pods. The catalog image is what makes the list of supported engines dynamic rather than hard-coded into the server.

Installing OpenEverest with Helm and reaching the UI

Helm is the method the README recommends, and the steps are short. Add the chart repository and update the local index first.

helm repo add openeverest https://openeverest.github.io/helm-charts/
helm repo update

Then install the chart into its own namespace. The release name in the README is everest-core and the namespace is everest-system, created by the flag.

helm install everest-core openeverest/openeverest \
--namespace everest-system \
--create-namespace

The README states that OpenEverest is not exposed via an external IP by default, so the UI is reached through a port forward on 8080.

kubectl port-forward svc/everest 8080:8080 -n everest-system

Open http://127.0.0.1:8080 in a browser. Admin credentials come from a secret rather than from a printed password. The README gives this command, which decodes the users file and pulls the password hash with yq.

kubectl get secret everest-accounts -n everest-system -o jsonpath='{.data.users\.yaml}' | base64 --decode | yq '.admin.passwordHash'

The default username is admin. The README notes that you can set a different default admin password during installation with the server.initialAdminPassword parameter. Note that the command returns a hash, not a plaintext password, so treat it as a value to verify against rather than something to type into a login form.

The CLI path, the wizard and headless installs

If you would rather not run Helm by hand, everestctl wraps it. The README states that starting from version 1.4.0 the CLI uses the Helm chart to install OpenEverest, and that you can pass chart parameters with --helm.set for individual values or --helm.values for a values file. That is the detail that matters for anyone with an existing values convention.

The binary is downloaded from the releases page per platform. The Linux and WSL form is a curl to everestctl-linux-amd64 followed by install to /usr/local/bin/everestctl; macOS builds are published for both darwin-arm64 and darwin-amd64. After that, running the wizard asks which namespaces OpenEverest should manage.

everestctl install

If you skip namespaces during the wizard, the README says you can add them later.

everestctl namespaces add <NAMESPACE>

For automation, the headless form takes the namespace list and the operators to enable as flags, with --skip-wizard suppressing the terminal UI.

everestctl install --namespaces <namespace-name1>,<namespace-name2> --operator.mongodb=true --operator.postgresql=true --operator.mysql=true --skip-wizard

The three operator flags in that example are the only ones the README shows, so do not assume a flag exists for an engine just because the catalog image is generic. The CLI prerequisites are a working cluster, a kubectl get nodes that returns, and a kubeconfig at the default path, or an exported KUBECONFIG pointing at it.

Branch confusion is the real operational hazard

The most important thing in this repository is not a feature. It is the branch note at the top of the README. The main branch carries v2, which the project labels a Developer Preview, explicitly not feature-complete and not for production. v1 is described as the current released version and lives on the v1.x branch.

On 18 August 2026 the two lines swapped branches: v2 moved from release-2.0 to main, and v1 moved to v1.x. The README states that both lines are still developed and that only the branch names changed. It also warns that anyone who cloned or forked before that date has v1 code sitting on a branch called main, and points to a Which branch to target section in CONTRIBUTING.md.

This is a genuine failure mode rather than a documentation nit. A team that clones the default branch, reads go.mod, and sees module github.com/openeverest/openeverest/v2 has pulled a preview. A team that pinned a fork months ago is on v1 code while believing it is on main. The two recent releases reinforce the split: v2.0.0-dev.2 is marked Developer Preview, while v1.16.2 and v1.16.1 are plain version numbers. The README does not document a rollback path between the two lines, so the branch decision is effectively a one-way commitment until you test the move yourself.

Where OpenEverest is the wrong tool

If you run a single PostgreSQL instance for one application and you are happy writing a StatefulSet, OpenEverest adds a server, a controller, an operator and a catalog to your cluster in exchange for convenience you will not use. The surface area is real: four images in the Makefile, a Casbin policy layer, a JWT stack and a web UI. That is a lot of moving parts to keep patched for one database.

It is also the wrong layer if your databases do not live on Kubernetes. The README's prerequisites are a Kubernetes cluster such as Amazon EKS or Google GKE, and every install path assumes kubectl and a kubeconfig. There is no documented path for managing an external database host.

The third case is a team that needs a frozen, supported API today. Because main is v2 and v2 is a Developer Preview, anything built against the main branch is built against an interface the project says is not feature-complete. Pinning to v1.x is the conservative choice, but the README does not state how long the v1 line will receive releases beyond linking to a lifecycle section in a blog post. That link is where the answer lives, and it is worth reading before you plan a migration.

How it compares to running the operators yourself

The obvious alternative is to install the database operators directly and skip the platform layer. Percona Everest is the closest comparison and shares lineage: go.mod depends on github.com/percona/everest-operator, and the repository has carried the name Percona Everest in its history. The difference is in who owns the operator lifecycle. Installing operators yourself means you choose versions, you upgrade them, and you own the CRDs. OpenEverest puts a server and a catalog in front so that the set of provisionable engines is a managed artifact rather than a set of Helm releases you maintain.

KubeBlocks takes a different route to the same problem. It defines its own abstraction over multiple engines and reconciles that abstraction itself, rather than wrapping the upstream operators. The trade-off is depth versus breadth: a wrapper inherits whatever the upstream operator does, including its limitations, while a reimplementation controls the behavior but has to re-earn parity engine by engine.

The honest summary is that OpenEverest is not competing on engine features. It is competing on the operator lifecycle and on giving developers a self-service surface inside namespaces the platform team has already approved. If your team already has that surface through an internal portal, the value proposition shrinks considerably.

Licence, upgrade cost and what to verify

The repository is Apache-2.0, which permits commercial use and modification and includes a patent grant. That is the permissive end of the spectrum and it means you can vendor the code or ship it inside a product without a copyleft obligation on your own work. It does not answer the separate question of what the database engines you deploy are licensed under, and those are independent of this project. This is a description of the licence file, not legal advice; if you are redistributing, have counsel read the NOTICE and dependency licences.

Upgrade cost is dominated by the branch situation rather than by the chart. The README gives no upgrade procedure and does not document rollback, so the practical verification list is short and specific. Confirm which branch you cloned with git branch --show-current, because the README warns that pre-swap clones hold v1 code on main. Confirm which line your cluster is running before you add namespaces with everestctl namespaces add. Check the v1 lifecycle link in the README to see the release horizon for the line you pick, since that is the only statement the project makes about how long v1 continues.

Finally, note that the version you get from Helm and the version you get from everestctl are not independent: the README states that everestctl uses the Helm chart, so a chart-level change reaches both paths.

Editorial conclusion

Adopt OpenEverest if you already run Kubernetes and want database provisioning to be a namespaced, declarative operation rather than a set of hand-written manifests. Skip it if you need a stable API today, since the main branch is a v2 Developer Preview and v1 lives on a separate branch. Before committing, check which branch you are actually targeting, confirm that your storage class supports the volume expansion the operators rely on, and read the v1 lifecycle note linked from the README to see how long the line you pick will receive releases.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openeverest/openeverest on GitHub
3. Project website
4. README
5. Releases